> Why will TG2 instantiate controllers on each request ? What are the > pros and cons of the actual model of TG 1 (one instance of each > controller in the entire lifetime of the application process) ?
Well, the real reason is because that's what Pylons does, so if we build on Pylons that's what we'll do. :) It's also easy to run multiple instances of the same pylons/tg2 app in one process which would be harder to do if controllers were global in memory objects. But the other advantages are: * TG2 controllers will have __before__ and __after__ methods which will always be run before or after your controller method * the ability to rewrite the expose decorator to just decorate the method with additional attributes. Pylons has a global state object they call g which can store global state information, and a request local state object called c, so you still have access to state information, it's just a bit more controlled. The potential downside is the extra time on each request spent instantiating the controller, but that hasn't been a problem, and is very unlikely to become the performance bottleneck. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
