I see. It'll be grate to have _lookup based routes extension for future tg versions.
Вівторок, 10 липня 2012 р. 13:42:26 UTC+3 користувач Alessandro Molina написав: > > Actually the future TG versions are getting rid of routes by default > as it was a huge performance bottleneck. > So it will make a lot of sense to create a tgext which provides routes > based controller _lookup and so on. > I can give a try at it as soon as I'll have some spare time, but it is > not something will happen soon. > > I think your solution should work but probably overriding > _get_dispatchable to return what you need would be a solution that has > to mimic less TG things like setting up i18n, calling _before, _after > and so on as the _call would remain the same. > > Both anyway rely a lot on internals of TG that might change in the future > > On Tue, Jul 10, 2012 at 11:01 AM, Artur Gavkaliuk <[email protected]> > wrote: > > Hello > > I've found solution and would like to hear your opinion. > > It's very basic but could be easily improved. > > I've just added next method to my BaseController: > > class BaseController(TGController): > > ........ > > def _perform_call(self, func, args): > > if (func != self.routes_placeholder): > > if hasattr(self, '_before'): > > self._before(*args, **args) > > r = self._call(func, args, remainder=None) > > if hasattr(self, '_after'): > > self._after(*args, **args) > > return r > > else: > > return TGController._perform_call(self, func, args) > > > > Could it be added to original TG code? > > > > Понеділок, 9 липня 2012 р. 14:42:43 UTC+3 користувач Artur Gavkaliuk > > написав: > >> > >> Thank you for quick answer. > >> I'm wondering if there is a way to set exact method of controller which > >> should handle request inside _lookup. > >> And, are _lookup methods called hierarchically (particularly, will root > >> _lookup be called if the one from mounted controller failed)? > >> > >> Понеділок, 9 липня 2012 р. 14:28:23 UTC+3 користувач Alessandro Molina > >> написав: > >>> > >>> I'm not a routes user, so my answer might be somehow wrong, it is > >>> mostly based on the knowledge that I have of the TurboGears routing > >>> system. > >>> > >>> The routes integration was not used by TurboGears itself, was there > >>> due to Pylons and was hijacked to always route to the RootController > >>> which was then in charge of the real routing. This is the reason why > >>> you can only route to Pylons controller using routes and not to > >>> TurboGears one, losing so the TurboGears features like validation, > >>> expose and so on. If you add routes that route to a TurboGears > >>> controller the controller itself will try to route them again, > >>> obviously doing the wrong thing > >>> > >>> Somehow you might be able to use routes with validation and expose by > >>> creating a Pylons controller that inherits from > >>> tg.controllers.decoratedcontroller.DecoratedController but keep in > >>> mind that this might break any time in the future. > >>> > >>> The TurboGears way to manage regular expression based routing is to > >>> handle them inside the _lookup method and return the actual controller > >>> instance that has to handle them with the remaining part of the url > >>> for which the dispatch has to continue from the returned controller. > >>> > >>> On Mon, Jul 9, 2012 at 1:13 PM, Artur Gavkaliuk <[email protected]> > > >>> wrote: > >>> > Hello > >>> > This question was raised several times but I didn't see clear and > >>> > up-to-date > >>> > answer. > >>> > So, is there any convenient way to map TGController subclass with > >>> > custom > >>> > url? > >>> > Pylons WSGIController is mapped easily but I would like to have > @expose > >>> > decorator working. > >>> > I'm following 'classic' example from app_config: > >>> > # Add a Samples route > >>> > map.connect('/samples/', controller='samples', > >>> > action=index) > >>> > > >>> > # Setup a default route for the root of object > >>> > dispatch > >>> > map.connect('*url', controller='root', > >>> > action='routes_placeholder') > >>> > > >>> > -- > >>> > You received this message because you are subscribed to the Google > >>> > Groups > >>> > "TurboGears" group. > >>> > To view this discussion on the web visit > >>> > https://groups.google.com/d/msg/turbogears/-/8yXhtPQj6zUJ. > >>> > 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. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "TurboGears" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/turbogears/-/5RFVdh94nf8J. > > > > 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. > -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To view this discussion on the web visit https://groups.google.com/d/msg/turbogears/-/w9g3dFaG92cJ. 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.
