On Sat, May 30, 2009 at 10:11 AM, Elliot Gage<[email protected]> wrote: > > Good morning. > > I’m looking into basing my new development projects on Pylons. > Two of the main sticking points for me are: > Combining Projects, so that one project can reference another. For > example: I will be building a security framework that will be used by > other applications I will be building. How might I find a best > practice for this?
Pylons has some support for nested applications but it's not as extensive as it could be. You can replace any controller class with a WSGI application instance, and Pylons will chain to the application. You could use this to embed Pylons in Pylons, by calling the inner make_app (in middleware.py) with full_stack=False, but I suspect you'd have to fuss with the middleware 'if' statements because I'm not sure the default is appropriate. You probably want the outermost level to handle the session, for instance, but let the inner app do its own separate routing for its sub-URL. I have a Pylons application with a common security framework and multiple independent "modules" which can be seen by certain users. I put them all in one big application because I wasn't sure how much I could trust the nesting. I may try nesting again now that Pylons has matured more. What Pylons doesn't have is a way to bundle a controller, some templates, and a model in a way that can be plugged into applications. The closest would be a nested Pylons app. > The second issue is hosting. I self host my projects, currently on > Windoze machines. It appears that running pylons requires some > wrangling even on linux boxes. I’m interested in opinions of overall > ease of setup and reasonable performance once hosted. Everything requires wrangling. Pylons is typical. Some people are luckier than others, and Linux users generally have less hassles than than Windows users (because of things Windows doesn't include, or does in a nonstandard way). A lot of people are running happily with mod_proxy or mod_wsgi, and some have had luck with FastCGI. mod_proxy is the easiest and most foolproof to set up because it's HTTP-to-HTTP, and you can use a localhost browser to troubleshoot the application directly, bypassing Apache. mod_wsgi users like the fact that Apache manages all the subprocesses. Performance is as good as can be expected with an interpreted language. It scales at least to the thousands-of-hits-a-day of normal e-commerce sites. Extremely high-traffic sites may need multiple servers or a Squid proxy, and if you anticipate that you'd want to do scalable coding (no session state on the server, set Beaker's cookie mode, consider a separate database server, memcached, etc). Search the wiki at pylonshq.com for "deployment" and you should find several articles about deployment techniques and performance. Some may be out of date; the best ones are those which have been updated in the past 6-12 months. -- Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
