> Last night I played around with dispatching API ideas. Below is some mock POD
> for one idea. The summary is:
>
> $self->dispatch([
> qr{
> /(?#rm) (\w+)
> /(?#user) (\w+)
> /(?#tags+) ([\w\+]+)
> }x;
> ]);
...
> I've intentionally used the "best practice" of using the "x" modifier to
> create
> something that looks more like a hash than line noise.
>
> I created an implementation of named backreferences to solve this in the
> process, which was fun.
>
> RJBS had a different idea, based on a system he uses at work and for Rubric.
>
> His concept is to avoid regex's and provide easy access to process the
> PATH_INFO
> instead. He might have a run mode that looks like this, if I understand
> correctly.
>
> sub bookmarks : Runmode {
> my $self = shift;
> my $user = $self->unshift_path_info;
> my $tags = $self->unshift_path_info;
> # ...
> }
At work, I use something similar to Ricardo's system. One advantage
with this system is that you can defer path_info parsing decisions until
you get to the final application or run mode.
I use one central CGI::Application::Dispatch module to dispatch to a
couple dozen applications; some of these applications want to get the
run mode from the path_info, some don't.
However, the problem with defered path_info parsing is that it's hard to
get an overview of what each application is doing. Deep down in the
guts of a run mode you pull out another part of the path_info, but which
part still remains to be parsed? Since it's dynamic, it's hard to tell.
So maybe it would be good to combine the two approaches? Instead of
deciding the parsing at dispatch time, the app calls parse_path_info
from cgiapp_prerun. Generally you'd do this in your base class, but you
could override it for specific applications. Something like:
sub cgiapp_prerun {
my $self = shift;
my %params = $self->parse_path_info(
qr{
/(?#rm) (\w+)
/(?#user) (\w+)
/(?#tags+) ([\w\+]+)
}x;
);
$self->prerun_mode(delete $params{'rm'});
$self->param(%params);
]);
Maybe this could be fancier, with hooks 'n such, but I'm not sure that
it needs to be.
Hmmm... interestingly, it looks like this approach would also work
independently of CGI::Application::Dispatch. For instance, the
following old-style URL would work just fine:
http://example.com/cgi-bin/recipes.cgi/list/markjugg/vegan+recipes
Also, as an alternative to mod_rewrite, you can use ScriptAlias:
ScriptAlias /recipes /cgi-bin/recipes.cgi
...meaning that the URL can now be shortened to:
http://example.com/recipes/list/markjugg/vegan+recipes
And, thus, you can avoid all that tedious mucking about in hyperspace
....erm... that is, mod_rewrite.
(You still need access to httpd.conf, though.)
Michael
---
Michael Graham <[EMAIL PROTECTED]>
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
