[cgiapp] C::A::P::Routes
Brad Van Sickle
bvansickle3 at gmail.com
Thu Mar 4 10:04:10 EST 2010
All of that can be done with mod rewrite. A (sanitized) example of a
rewrite/proxy rule I have working in an existing application
RewriteRule Runmode/([0-9]+)/([a-zA-Z0-9]+)
http://server/perl/instance.pl?rm=Runmode&PARAM1=$1&PARAM2=$2 [P,L]
Which takes the URI "Runmode/20/Data" and turns it into
"instance.pl?rm=Runmode&PARAM1=20&PARAM2=Data"
By making use of optional parameters and regular expressions I find it
to be very powerful and extremely easy. The fact that I can use
MOD_PROXY in conjuction with this for load balancing, is also awesome.
The only downside is that I have to create one of these rules in
httpd.conf or in .htaccess for each "pretty" URL, but I don't see a way
of getting around.
Maybe CGI::Application::Dispatch or CAP::Routes is a better/more
powerful way to do this... but I don't see how. Which is why I'm asking.
P Kishor wrote:
> On Thu, Mar 4, 2010 at 8:25 AM, Brad Van Sickle <bvansickle3 at gmail.com> wrote:
>
>> Tangential discussion on this... but what is the value in using
>> dispatching modules like CAP::Routes and CGI::Application::Dispatch?
>>
>> I've looked at them in the past, and I've heard it mentioned many times
>> that they are wonderfully useful.. but I've never fully understood why.
>>
>> Currently I'm using mod_rewrite to implement pretty URL's and mapping
>> them to individual instance scripts. As I understand it, dispatch
>> modules do basically the same thing, except they move the config out of
>> .htacces/httpd.conf and will allow me to get rid of the instance scripts
>> (which I personally don't consider a HUGE benefit)
>>
>> I think I'm missing something here. Can someone educate me?
>>
>
> actually, perhaps you can educate me... I too use mod_rewrite, which
> basically takes
>
> /server/foo/id/32?action=edit
>
> and converts it to
>
> /server/index.cgi?page=foo&id=32&action=edit
>
> and so on.
>
> Now, we need to call the 'edit' runmode with the various params as
> above. This is where CAD and CAPRoutes and the ilk come in. Without
> those, how do you accomplish that?
>
> The painful aspect, to me, is that a lot of work is required to get clean URIs.
>
> Step 1. Create the route table
> Step 2. Create the RewriteRules
>
> This is where my recent experience with Dancer was rather lovely.
> Clean URIs from the get go. And then I realized why -- I wasn't using
> Apache at all. I was simply firing up dance.pl which was acting as the
> webserver and also interpreting the URIs for me. Added side-effect --
> since dance.pl was permanently running, it was noticeably faster than
> Apache restarting Perl and DBI and stuff. But, more than anything, it
> was clean URIs from get-go.
>
>
>
>
>> P Kishor wrote:
>>
>>> On Thu, Mar 4, 2010 at 3:33 AM, Mike Tonks <fluffymike at googlemail.com> wrote:
>>>
>>>
>>>> I am using CAP::Routes and it works very well for me.
>>>>
>>>>
>>>>
>>> Thanks for the report. This is good to know, because this proves I
>>> must be doing something wrong, even though I can't figure out what. I
>>> am not using ScriptAlias, but am using .htaccess with RewriteConds and
>>> RewriteRule.
>>>
>>> By the way, could you please check if $self->route_dbg works for you?
>>>
>>> My one thought is -- perhaps I am not doing anything wrong, but that
>>> it is my combination of various plugins. I recall (from a while back),
>>> I think I had identified some clash between CAPRoutes and
>>> CAPAuthentication, but it could be some other plug in well that seems
>>> to redefine the runmodes.
>>>
>>>
>>>
>>>
>>>
>>>> First off, I am using ScriptAlias to map the url and hide the script
>>>> name it the url:
>>>>
>>>> So I have a few lines in my /etc/apache2/sites-available/app virtual host file:
>>>>
>>>> ScriptAlias /contacts /var/www/app/cgi-bin/contacts.cgi
>>>> ScriptAlias /jobs /var/www/app/cgi-bin/jobs.cgi
>>>> ScriptAlias /titles /var/www/app/cgi-bin/titles.cgi
>>>>
>>>>
>>>> Then in contacts.cgi:
>>>>
>>>> #!/usr/bin/perl -w
>>>>
>>>> use strict;
>>>>
>>>> use App::Contacts;
>>>>
>>>> my $app = App::Contacts->new();
>>>>
>>>> $app->run();
>>>>
>>>> and finally the run modes in Contacts.pm
>>>>
>>>>
>>>> sub setup
>>>> {
>>>> my $self = shift;
>>>>
>>>> $self->start_mode('view');
>>>>
>>>> $self->routes_root('');
>>>>
>>>> $self->routes([
>>>> '' => 'view' ,
>>>> '/guest' => 'guest',
>>>> '/staff/edit/:id' => 'edit_staff',
>>>> '/staff/process/:id' => 'edit_staff_process',
>>>> '/:id/address/new' => 'edit_address',
>>>> '/:id/address/:id2' => 'edit_address',
>>>> '/:id/address/process/:id2' => 'edit_address_process',
>>>> '/:id/email/process/:id2' => 'edit_email_process',
>>>> '/:id/email/new' => 'edit_email',
>>>> '/:id/email/:id2' => 'edit_email',
>>>> '/:id' => 'view' ,
>>>> ]);
>>>>
>>>> etc.
>>>>
>>>> Then my urls are e.g.
>>>>
>>>> http://mysite/contacts - default page
>>>> http://mysite/contacts/1234 - view a specific contact record
>>>> http://mysite/contacts/1234/address/new - add address to a contact record
>>>>
>>>> Note that I haven't got the /contacts/ bit in my routes_root - it
>>>> doesn't seem to need it.
>>>>
>>>> I've been using this for 6 months plus now and as I say it works really well.
>>>>
>>>> Hope this helps.
>>>>
>>>> mike
>>>>
>>>> ##### CGI::Application community mailing list ################
>>>> ## ##
>>>> ## To unsubscribe, or change your message delivery options, ##
>>>> ## visit: http://lists.openlib.org/mailman/listinfo/cgiapp ##
>>>> ## ##
>>>> ## Web archive: http://lists.openlib.org/pipermail/cgiapp/ ##
>>>> ## Wiki: http://cgiapp.erlbaum.net/ ##
>>>> ## ##
>>>> ################################################################
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> ##### CGI::Application community mailing list ################
>> ## ##
>> ## To unsubscribe, or change your message delivery options, ##
>> ## visit: http://lists.openlib.org/mailman/listinfo/cgiapp ##
>> ## ##
>> ## Web archive: http://lists.openlib.org/pipermail/cgiapp/ ##
>> ## Wiki: http://cgiapp.erlbaum.net/ ##
>> ## ##
>> ################################################################
>>
>>
>>
>
>
>
>
More information about the cgiapp
mailing list