Re: [cgiapp] C::A::P::Routes
Hi Michael From Michael Peters mpeters at plusthree.com On 03/04/2010 10:04 AM, Brad Van Sickle wrote: 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. There are pros and cons to both ways (using mod_rewrite or Dispatch) and I frequently use them both, even in the same project. That's all very well for someone with your expertise, but for the average programmer the mantra has to be: o Do it simply (at first) o Do it right o Perhaps one day add complexity This reminds me of a msg on the DBI users list (which these days I can't unsubscribe from [posts are blocked but I still receive posts, and the help and (human?) owner addresses don't respond]): o Someone asked are a recommendation about storing files in a db o I replied that my policy is: data goes in databases, and files go in filesystems o Tim Bunce himself (author of DBI) politely pointed out that Oracle grabs a large block of your hard disk and installs it's own file system in it, so, it's efficient to store files in the db if it's Oracle. o Sure, but that's an Oracle-based optimisation, and the decision depends on actually knowing that that happens. Now that we know it, we can choose that alternative. But for beginners, my advice is always: Keep it simple... -- Ron Savage r...@savage.net.au http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] C::A::P::Routes
I am using CAP::Routes and it works very well for me.
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://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] C::A::P::Routes
On Thu, Mar 4, 2010 at 3:33 AM, Mike Tonks fluffym...@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://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
--
Puneet Kishor http://www.punkish.org
Carbon Model http://carbonmodel.org
Charter Member, Open Source Geospatial Foundation http://www.osgeo.org
Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor
Nelson Institute, UW-Madison http://www.nelson.wisc.edu
---
Assertions are politics; backing up assertions with evidence is science
===
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] C::A::P::Routes
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?
P Kishor wrote:
On Thu, Mar 4, 2010 at 3:33 AM, Mike Tonks fluffym...@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://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] C::A::P::Routes
On Thu, Mar 4, 2010 at 9:25 AM, Brad Van Sickle bvansick...@gmail.com wrote:
Tangential discussion on this... but what is the value in using
dispatching modules like CAP::Routes and CGI::Application::Dispatch?
The big advantage for me when I decided to use CAP::Routes for a project
was because a route is a declaration of what the url looks like and it
will unpack
variables out of the url for me, instead of messing with PATH_INFO myself.
For example
$self-routes([
'/contacts/:action/?contact_id' = 'contact_create_update_delete'
]);
is describes the url better than:
$self-runmodes({ 'contact_cud' = \contact_create_update_delete});
Especially when you are performing ajax queries and the like you want to know
what the url looks like and what runmode will be called.
Clayton
P.S. I've had great success in using CAP::Dispatch and CAP::Routes together
my instance script loaded a bunch of CGI::App based modules and used
CAP::Dispatch
to assign root urls for each module (/contacts, /staff, /etc) then I
used CAP::Routes to define the
different url/variable/runmode combinations within each Application.
--
Clayton Scott
clayton.sc...@gmail.com
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] C::A::P::Routes
On Thu, Mar 4, 2010 at 8:25 AM, Brad Van Sickle bvansick...@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=fooid=32action=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 fluffym...@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://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web
Re: [cgiapp] C::A::P::Routes
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=RunmodePARAM1=$1PARAM2=$2 [P,L]
Which takes the URI Runmode/20/Data and turns it into
instance.pl?rm=RunmodePARAM1=20PARAM2=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 bvansick...@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=fooid=32action=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 fluffym...@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'
Re: [cgiapp] C::A::P::Routes
Brad,
On Thu, Mar 4, 2010 at 9:04 AM, Brad Van Sickle bvansick...@gmail.com wrote:
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=RunmodePARAM1=$1PARAM2=$2 [P,L]
Which takes the URI Runmode/20/Data and turns it into
instance.pl?rm=RunmodePARAM1=20PARAM2=Data
Do us all a favor... please write up a short tute on this (and on
mod_proxy) and put it up on the wiki and highlight it in bold colors.
You are absolutely correct, the above will work, and work well.
I think CAD helps when you have multiple modules, and you want to call
runmodes in them. In my case, I have only a single module with half a
dozen runmodes, so I will go your way.
By the way, one does need to have a rule for every runmode, so it
doesn't matter whether one uses Apache or CAD to do it... you will
need a rule for every rm anyway.
By the way, here is an interesting post by Sukrieh (Dancer's creator)
on Dancer's load response under hundreds of runmodes...
http://www.sukria.net/fr/archives/2010/03/03/about-performances/
I will never run into such a problem (can't imagine more than a dozen
runmodes, max, in my app).
Anyway, thanks for your insight, Brad.
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 bvansick...@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=fooid=32action=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 fluffym...@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('');
Re: [cgiapp] C::A::P::Routes
On Thu, Mar 4, 2010 at 9:26 AM, Clayton Scott clayton.sc...@gmail.com wrote: On Thu, Mar 4, 2010 at 10:04 AM, Brad Van Sickle bvansick...@gmail.com wrote: 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=RunmodePARAM1=$1PARAM2=$2 [P,L] Which takes the URI Runmode/20/Data and turns it into instance.pl?rm=RunmodePARAM1=20PARAM2=Data I have done and still do the same thing... 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. CAP::Routes/CAP::Dispatch give you the full ability to do what you want with regards to regular expressions, but can't handle the MOD_PROXY stuff for you. In that case it makes sense to keep all of your url definitions in one place: the apache config. 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. I liked using CAP::Routes/CAP::Dispatch because the URLdefinitions were in the code that handled them so it was only 1 step to deploy any changes: push the code. I prefer that to push the code, update the rewrite rules, restart apache Very good point, esp. when the routes are more than simple or few. Of course, that still doesn't escape having RewriteRule somewhere, either in httpd.conf or in .htaccess (shared web servers will only allow .htaccess). The peril of using Apache is that you have to configure Apache. Clayton -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --- Assertions are politics; backing up assertions with evidence is science === # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] C::A::P::Routes
On 03/04/2010 10:04 AM, Brad Van Sickle wrote: 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. There are pros and cons to both ways (using mod_rewrite or Dispatch) and I frequently use them both, even in the same project. The main reasons I like (and wrote) Dispatch is because I wanted pretty URLs with more meaning (REST-ish). This makes things slightly more sane. But by doing it all in the proxy with mod_rewrite means that you need to change your httpd.conf every time you change your application. If these rules are in a proxy then it's definitely a violation of concerns when your proxy server needs to be intimately familiar with your applications URL structure. It also makes it harder to move the application around to a different server setup or different proxy software. And using Dispatch makes certain things way easier than mod_rewrite. Off the top of my head: + Dispatching based on HTTP request type (GET vs POST) + Dispatching based on + Easier to understand and write. Compare '/app/:rm/:year/:month/:day' vs RewriteRule /app/([^/]+)/([0-9]+)/([0-9]+)/([0-9]+) http://server/app.pl?rm=$1year=$2month=$3day=$4 [P,L] Now try to imagine how much crazier that regular expression needs to be if you wanted to do something like this: '/app/:rm/:year?/:month?/:day?' + Easy to pass different parameters to your application's new() method. Imagine for example a situation where you have a single application (same code) but you need to customize that application depending on the URL that was accessed. Maybe it's a beta version, or a different client, etc. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] C::A::P::Routes
A while back I attempted working with CAPRoutes, but failed. Today I
decided to revisit it, and failed again. In fact, I am failing at
getting the simplest possible application running with it, and I am
wondering -- either I am completely clueless about how this is
supposed to work, or this module is just not what it claims to be. I
will go with the former assumption, and ask for the list's help here.
My app script is a simple
use App;
my $w = App-new(
TMPL_PATH = /Sites/app/_tmpl,
PARAMS= {
..
},
);
$w-run();
in my App.pm package, I have
sub setup {
my $self = shift;
$self-routes_root('/app');
$self-routes([
'foo/:page?' = 'foo',
'/:page?' = 'foo',
''= 'foo',
'bar/:page' = 'bar',
'baz/:page' = 'baz',
]);
$self-start_mode('foo');
$self-tmpl_path( '/Sites/app/_tmpl' );
}
Ok. Here is all that goes wrong --
1. Why do I need to provide $self-tmpl_path( '/Sites/app/_tmpl' ); in
my App.pm even though I have TMPL_PATH = /Sites/app/_tmpl, in my
app.cgi? (this is not a CAPRoutes specific question). If I comment out
$self-tmpl_path, the script errors out. If that is what is needed,
then why even give me the option of declaring TMPL_PATH in my app.cgi?
2. I have CAPRoutes 1.02. If I do a simple 'my $debug =
$self-routes_dbg;' in a run mode in my App.pm, the script dies with
the error that Undefined subroutine
CGI::Application::Plugin::Routes::Dumper called at
/usr/local/lib/perl5/site_perl/5.10.1/CGI/Application/Plugin/Routes.pm
line 49. Line 48, 49 happen to be
require Data::Dumper;
return Dumper($self-{'Application::Plugin::Routes::__r_params'});
If I replace 'require Data::Dumper' with 'use Data::Dumper' the error
goes away, but nothing is dumped out. The
$self-{'Application::Plugin::Routes::__r_params'} var is completely
empty.
3. Finally, CAPRoutes doesn't seem to match any routes at all. No
matter what my path_info, it always defaults to the start mode 'foo'.
So, please, please let me be the clueless one here and set me right,
otherwise, it will be baffling how a module that doesn't work at all
got onto CPAN.
Many thanks,
--
Puneet Kishor
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
Re: [cgiapp] C::A::P::Routes
Hi On Wed, 2010-03-03 at 15:56 -0600, P Kishor wrote: A while back I attempted working with CAPRoutes, but failed. Today I decided to revisit it, and failed again. In fact, I am failing at I've never used it. CGI::Application::Dispatch is superb, so that's what I'm sticking with. Not only that, but with the availability of CGI::Application::Dispatch::PSGI, we can move effortlessly to Plack. I already have. Then, when you want to embrace more and more of Plack, you might try Plack::App::URLMap, etc. -- Ron Savage r...@savage.net.au http://savage.net.au/index.html # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] C::A::P::Routes
On Wed, Mar 3, 2010 at 4:33 PM, Ron Savage r...@savage.net.au wrote: Hi On Wed, 2010-03-03 at 15:56 -0600, P Kishor wrote: A while back I attempted working with CAPRoutes, but failed. Today I decided to revisit it, and failed again. In fact, I am failing at I've never used it. CGI::Application::Dispatch is superb, so that's what I'm sticking with. I do use CAD in another application, and yes, that works rather well. For a number of reasons, I want to explore CAPRoute. In fact, one thing I don't like about CAD is that it breaks the (to me) established formula of extending a CA application's functionality via a plugin. I don't want all that routing table stuff in my instance script. I want it in my App.pm, along with all the run modes. In any case, this post is an attempt to make CAPRoutes work for me, not to discount it in favor of CAD. Thanks, Not only that, but with the availability of CGI::Application::Dispatch::PSGI, we can move effortlessly to Plack. I already have. Then, when you want to embrace more and more of Plack, you might try Plack::App::URLMap, etc. -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --- Assertions are politics; backing up assertions with evidence is science === # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] C::A::P::Routes
On 03/03/2010 05:58 PM, P Kishor wrote: I do use CAD in another application, and yes, that works rather well. For a number of reasons, I want to explore CAPRoute. In fact, one thing I don't like about CAD is that it breaks the (to me) established formula of extending a CA application's functionality via a plugin. In fact, there are lots of C::A related modules that aren't plugins: CGI::Application::FastCGI CGI::Application::PSGI CGI::Application::Server And you'll note that they're all concerned about what happens before your application module begins to do it's thing. Dispatch has to happen outside of your application module because it in fact picks which application module to run based on the URI. I don't want all that routing table stuff in my instance script. I want it in my App.pm, along with all the run modes. This will only work in very simple situations where you only have a single application module. I try to not have more than a dozen run modes in any application file, and all but the simplest of applications will have more than that. -- Michael Peters Plus Three, LP # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
