[cgiapp] Re: New plugin idea based/inspired on CA Dispatch.

[Mark Stosberg]

On Mon, 22 Sep 2008 11:36:24 -0400
Mark Stosberg <mark at summersault.com> wrote:

> > I already started writing a CA plugin and I'd love to hear what you all think
> > (if the idea/plugin can be useful or just a waste of time).  I have my own
> > thoughts but I can be missing something and I'd like to have other opinions.
> > Based and inspired in CA Dispatch, also borrowing some code, the plugin
> > should work as a *light* implementation from CA Dispatch for simple CA based
> > apps.
> > 
> > In my daily work, I usually write simple CA apps, always with a couple of
> > runmodes (usually, around 8) and a single application module (no need to have
> > more, since the apps usually are fairly simple). Also, I usually need to
> > implement clean url's.
> > 
> > In this context, what I did so far is to adapt the url parsing routine from
> > CA Dispatch (receiving from the CA app a dispatch table in the same way CA
> > Dispatch does) and *adding* the parsed params/values into CGI.pm params, in a
> > way they can be retrieved in the CA based app with the usual
> > $app->query->param('parsed_param_name'); method.
> > 
> > Since this is my first plugin AND I never been in touch with CA other than
> > doing my simple CA apps, I dont know if this idea is good, ok, heresy or just
> > stupid.
> 
> Porta,
> 
> I think is a great idea. I really like it. I could also see it being used along
> with ::Dispatch: -- The global dispatcher might handle passing the flow into
> the right module, and then this plugin would pick up from there.
> 
> While a global dispatcher is nice, sometimes it's more helpful to keep the the
> related dispatch table and run modes closer together. 
> 
> In my workflow, I found a global Dispatch.pm to be a point of conflict, in the
> source control sense: Two unrelated projects may both modify a global
> Dispatch.pm. When I go to launch one project, the other project becomes a
> dependency. (I solved that by recording changes to Dispatch.pm separately from
> other work).
> 
> I have some specific suggestions on your implementation:
> 
> - rename "routes_table" to just "routes". I don't think the word "table" adds much.
> 
> - Consider having "routes_table()" automatically add every run mode dispatched to
>   the "run_modes" hash, if a subroutine with that name exists in the current
>   scope. (I suppose you can use the "can()" method to test for that? ).
> 
>   That will eliminate the need to make a separate call to "run_modes()" in most
>   cases, unless you have a run mode that points to a code-ref that you need to
>   call.

One more suggestion: 

Break out all the code in the 'for' loop that processes a single route into
it's own subroutine.  That would allow someone to 'use' this plugin and build
on it to parse the 'route' out of a subroutine attribute, like Catalyst does.

And perhaps one more suggestion:
Perhaps there should be an option to set a path for which all the routes are
relative to. For example:

 $c->routes_root('/app/volunteer/profile');

And then in the routing table, or in a potential signature, you can be relative to that:

$c->route(
    # maps to /app/volunteer/profile/edit/:id
    'edit/:id'      => 'edit'
);

# Or
 sub edit ('/edit/:id') {
 }


Now, when I saw Matt Trout, a Catalyst maintainer at YAPC, he was having second
thoughts about using subroutine attributes in Catalyst, although he didn't go
into detail. And I have run into problems with them in the past.

So, I'm not recommending that style as being "preferred", but I think it's an
option some people might enjoy having.

    Mark