[cgiapp] Re: Patches available for ::Plugin::Routes (was: Re: New plugin idea based/inspired on CA Dispatch)

[Mark Stosberg]

> 1. The plugin should be able to handle routes like
> '/runmode/:term/:term/:term' ? My first thought was that it should
> populate a array for the param 'term'. same applies for parameters
> passed by GET and POST with the same name (I cannot imagine a good
> reason for this, but completely possible)  Any ideas?

Dispatch.pm doesn't do this either, and no one has complained about the
omission of the feature so far.  I agree that creating an arrayref of
values is how I would parse this case, but for simplicity I would
continue to omit the feature until someone makes a strong use-case for
"needing" it.

> 2. Another thought I had is that, registering runmodes on the fly will
> cause those runmodes to not being available if there's no matching
> route, which may happen is the routes table is missing or incomplete
> or there's a error on the route itself and it doesnt match the url.
> It's true that if no route matches and no runmode is declared by the
> plugin, the application will fallback to it's default runmode and you
> can debug there to see what happened.
> Having the plugin registering runmodes on the fly it's nice, but I
> wouldn't push too hard inviting users to not registering their
> runmodes in the setup.

This is an excellent point, Julian. I wasn't paying close attention and
didn't realize the run mode registration was dynamic. It should be
static. Dynamic registration created complications with AutoRunmode. 
To work around it, we modified the 'Forward' plugin to detect that
AutoRunmode was in use, and then also did just-in-time registration
there! Not elegant. 

Here's a quick test which can be added to the test suite which will
confirm the need to use one-time static run mode registration: 

1. Create a test module with two run modes declared via 'routes':
'first' and 'second'. Do not declare 'run_modes' . 

2. Have 'first' match and call "$self->forward('second')". Ideally this
should succeed, but I think it will currently fail. 

The fix is to immediately the routes table when we call "routes" in
setup, and register the run modes there, not each time we are in the
pre-run callback.

This was, we get static run mode registration in 'setup', while still
avoiding the need to also call 'runmodes' in most cases. 

Is that a patch you would be willing make? I could do it, but have some
other CPAN module maintenance I could be doing. Your help would be
appreciated. 

    Mark

-- 
http://mark.stosberg.com/blog