Yes. That's what I meant. Thank you for making it much clearer. Like you mention the benefit is unclear. This makes it unnecessary to toy with routes or router, which I believe is in the spirit of web2py and benefits beginners with one less location to edit, thing to learn (routes rules vs. simply overriding a magic function). On the other hand, this is use case is arguably uncommon and advanced, a clean solution exists, and __catchall() can be seem as very magical and just adding more to the inner plumbings of web2py.
Because I'm unsure of the value of the idea I posted the suggestion. However, after considering better routes/router arguments and the fact that they do not impose a real penalty on performance this is likely unnecessary. Miguel On Thu, Jul 7, 2011 at 6:28 PM, Anthony <abasta...@gmail.com> wrote: > Are you suggesting the possibility of defining a function like: > > def __catchall(): > # do stuff > return dict(...) > > in a controller, and any time a request comes in for a function that > doesn't exist in the controller, web2py looks for a function called > __catchall, and if it exists, passes the request to that function (and > converts the function part of the url to the first argument, so the > __catchall function knows what to do with the request)? > > What is the benefit of that over using routes and simply specifying a > default function (which would then not have to appear in URLs)? > > Anthony > > > On Thursday, July 7, 2011 3:52:08 AM UTC-4, miguel wrote: > >> Yesterday I posted about implementing dynamic actions (functions) in a >> controller. >> This is interesting because one can achieve clean urls, instead of passing >> the names of the dynamic pages in args or vars. In a system with a cms this >> has the benefit of user defined pages being indistinguishable from extant >> "hard-coded" actions (if any). >> >> However, given the static nature of controllers (they are compiled with >> web2py) this cannot be achieved with closures or metaprogramming. The >> solution is to use routes to hide a dispatching action. It maybe possible to >> add to the controller namespace at runtime (but it is beyond my knowledge to >> explore this). >> >> This made me think that controllers might allow for the implementation >> (override?) a single dynamic action that would serve as a catchall for calls >> to non defined actions. I wonder if there as been any debate on this sort of >> built-in default action? This would supply a way to dealt with all calls >> that have no defined action per controller (including errors) without having >> to use routes. A small idea that perhaps does not bring enough benefits to >> be argued for. What do you think? >> >> Miguel >> >
