Seems like this is a discussion to move to trunk :) Yea, it all depends on the size of the controller object.
My first thought on how to this is to make the standard controller object's route method dispatch off of an object we put in the "global" stacked object proxy. I suppose that a users controlers.py file then have 1) a tgurbogears controller with a single attribute pointing to the tg_app object 2) an app object, and and g.TG_app=MyApp The thing I like about this is that it is relitively simple to understand what's going on, and it's easy to figure out how to override the defaults, but the thing I don't like about it is that users have to know about all this stuff. :( I suppose we could make this all optional, and just use the controller by default, but allow users to set all this up if they want it. Any thoughts from the community at large? --Mark On 7/18/07, Rick Copeland <[EMAIL PROTECTED]> wrote: > > I haven't looked at the code much since the sprint, but it seems to me > that we might hit performance problems before the Pylons guys do, so > caching the root controller may be a good idea. Here's my thinking... > > In Pylons (with Routes), a "controller" handles a relatively small set > of URLs. Controller construction overhead is therefore quite small, > only constructing the necessary objects to handle that route. In TG2, > a pylons "controller" is actually an entire TG app. So you will > construct your entire URL tree on each request. (Well, not > technically, as there are the special cases of default() and lookup(), > but for other "non-dynamic" URLs, it's true). So caching the root TG2 > controller seems like a _very_ good idea to me. Just my $.02 > > On Jul 18, 11:21 am, "Mark Ramm" <[EMAIL PROTECTED]> wrote: > > > > * TG2 controllers will have __before__ and __after__ methods which > > > > will always be run before or after your controller method > > > > > Nice feature, but it's not directly related with this "create on > > > request" behavior, I suppose... > > > > Yea, it's not directly related, but the way it is implemented is related :) > > > > > What happens if a method_a does an internal redirect to method_b ? > > > Will __before__ and __after__ be called twice ? > > > > Not in the current implementation. > > > > > > * the ability to rewrite the expose decorator to just decorate the > > > > method with additional attributes. > > > > > Can you elaborate on this ? :) > > > > Sure, the expose decorator currently creates an attribute called > > tg_info on the exposed function/method. That tg_info object has > > information about what engine/template to use to handle which > > requests. So the decorator doesn't really wrap the function, it just > > "decorates" it with additional information. Then the render step > > just looks at the tg_info to to find out what output types are > > supported and what engines to use for them. > > > > Because the controller is recreated on each request, that tg_info > > object can live on the function itself, which makes sense because that > > function is what has the specific behavior we want. Of course, we > > could move tg_info into the pylons request local context object -- but > > that would require adding logic to redirection to clear information > > out of tg_info, so you don't get a new method exposed with the old > > template :( > > > > If there turn out to be performance issues with instantiating the > > controller for each request, I have some ideas about how we can cache > > controller objects -- but I'd like to avoid that kind of complexity > > for now. But the pylons people have been doing it this way for a long > > time, and they tend to be a bit more performance conscious thatn TG > > has been, so I think we'll be OK. > > > > --Mark > > > > > -- 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 Trunk" 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-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
