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
>
