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

[Mark Stosberg]

> 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.

    Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   mark at summersault.com     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .