On Sun, Apr 12, 2009 at 9:18 PM, Iain Duncan <[email protected]> wrote: > > I've been working through the Pylons book and new docs ( fantastic > improvement btw! ) as well as Ian's webob tutorials. I'm pretty clear > now on how Pylons calls pylons controllers and wsgi apps, and understand > the difference between calling an instantiated app and the way pylons > re-instantiates a controller on each request. However I haven't seen > anything describing *why* pylons does it this way. I'd like to learn > more, so is there an explanation as to why that's a good idea anywhere?
It's just a design variation. Instantiating a controller for each request allows you to put request-local state data in 'self'. (As if 'c' and 'request' weren't enough.) It also guards against accidentally leaking state from one request to another. I believe that has been the experience with previous frameworks, that instantiating the controller for each request is a good thing. Pylons has plenty of places to store multi-request data anyway: app_globals, cache, and module globals. And the controller *class* is a module global so it also remains in memory. As for why external WSGI applications are long-lived, that's because it's a complete application that manages its own requests. It may have initalization state or database connections. It may be as big as Plone. We don't know what it is, but we know that some WSGI applications like to be long-lived. -- 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 -~----------~----~----~----~------~----~------~--~---
