Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • One of the core features of web frameworks is dispatching - i.e. connecting the http address with a subroutine. This can be done in a few main ways:
    1. DSL with anonymous subs - this what you described above and it is the most common in recent web frameworks. The problem I can see with that code is - how it plays with the standard OO techniques like inheritance and some more advanced ones like Moose Roles. Even if this can be made to play along I am sure there will be lot's of corner cases making it difficult for complex applications and on the other end of scale it also will not be obvious for newbies.
    2. Code attributes a la Catalyst: sub index : Local. This looks nice if the attributes are restricted to the most simple type, but quickly deteriorates when you put more information (and logic) into them. It also requires compile time intervention - which means an array of corner cases even if you use the nicely packaged MooseX::MethodAttributes.
    3. External list of methods to be allowed to be called from outside (CGI::Appplication run_modes). This suffers from the problem of maintaining the list of methods far from the actual methods code.
    4. Calling just one method for example 'get' or 'post' in Tatsumaki and using the class names for the dispatching. This means just one action per class.
    5. Lastly - I am thinking about a 'hybrid approach' - i.e. instead of calling just one method called 'get' - maybe calling all methods with a '_get' postfix? I am sure some people will decry that as 'ugly' - but it should work with all OO techniques is very 'low tech' - so maybe it is worth experimenting with?
    • There's also the "put it all in a central dispatch file" (a la Django's URLconf [djangobook.com], or even MojoX::Routes [cpan.org])

      The disadvantage is that you can't just drop a controller class into a file to be automatically picked up by the app, you have to modify the dispatch file too.

      But this turns to an advantage when you wish to selectively enable parts of you app (again, Django's admin feature comes to mind).