In OpenInteract we use the idea that a URL is nothing but a remote procedure call. For instance: /User/list/ lists all users, and /User/list/?last_name=wall finds all users whose last name has 'wall' in it. This idea isn't anything new: Jon Udell talks extensively about it in Practical Internet Groupware and other projects use it as well.

What does this mean practically? You need: (a) a map of URL name to Perl action (b) a multiplexer that catches every request, reads the map and executes the matching action. This might sound more complicated than it is -- it's basically another version of your pseudo-case statement above, but once you start separating the pieces (putting the URL -> action map in a separate place from your script), then you can really start flying. And the general pattern is simple enough to work in CGI or mod_perl.

Chris
M-x auto-bs-mode

In my experience, this really comes down to the scale and lifetime of the application.

For a simple form collection app or some form of system that performs a simple administration task, I have used the action sequence. I generally have something along the lines of:

my $action = $query->param('ACTION');

unless(defined($action))
{
 $action = 'default';
}
[download]

and then my if else based tree. For example, I have written small apps that manage lookup tables for databases where the data they contain is less than 20 rows in size. Adding a confirmation screen then becomes:

if($action eq 'delete')
{
 $confirmed = $query->param('CONFIRMED')
 if($confirmed eq 'yes')
 {
  # do stuff
 }
 else
 {
  # do other stuff
 }
}
[download]

I find that this enables me to also port my code. Sadly, my new job involves some ASP programming (sigh) and have ported this technique to the small apps I have written there.

However, if your application will not allow a simple if-else tree followed with a simple confirmed -yes-no stage then pathinfo is my recommendation.So I will be keeping an eye out for the groupware book to see if I can pinch any ideas for my next large program.

But to continue the discussion, my last big app involved datadumping a hash into the form (after encrypting and mime encoding it) which proved a simple way of passing state information rather than parsing out a huge munge of hidden fields.

Could this be extended to tie the hash to disk instead and use a key on the form as the lookup to that tied file?

Using CGI::Application and some well designed supporting modules, you can completely abandon the http://server/index.pl?action=... method and have multiple scripts

I tend to find that any time I cram everything into one script things go wrong because I'm trying to do to much at once.

I still do use the action=? thing, but I tend to think of my scripts as objects and the action=? calls as methods. I still haven't perfected this but it does have advantages.

____________________
Jeremy
I didn't believe in evil until I dated it.

On the other hand, it would be enlightening if you came up with something that drew a line in terms of scalability vis-a-vis the various web application development environments --- I have about 10 listed in my home node and no objective tests as to which approach is better and why.

In my CGI/Mod Perl applications I use an action variable to direct my program to do what needs to be done. i.e.

What if you have multiple forms posting to the same cgi script? Using the referrer as a dimension seems like a bad idea.

Does it not also increase debugging time? For my scripts, I can type in the params I want to test with right into my browsers url bar. Using referrer requires you to always go through the proper steps.

Also, what happens when your site layout changes?