CGI/Mod Perl Application Design philosophy - which way do we go?

[BMaximus]

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

There is an input tag of type hidden with the name of action and a value.

# $apr is an Apache::Request object
my $action = $apr->param('action');

# program is directed to do whats needed to be done through
# action variable.
# $t is an HTML::Template object - nuff said
for ($action) {
   /FOO/ && do { &puke($t,$apr); last;};
   /BAR/ && do { &swig_alcoholic_drink($t,$apr); last;};
}

# the rest of the story of course

While I think this a great way to direct the program to do what needs to be done. As the program goes deeper and you keep using this. You start using subactions and sub subactions. It can get out of hand very quickly if you don't watch what your doing. Next thing you know your in it so deep you forget what goes where and how. There has to be a better way than this.

So for large apps how do you control your applications and keep them on a tight leash at the same time?

Thanks,
BMaximus

[lachoy]

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

[simon.proctor]

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';
}

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
 }
}

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?

[jepri]

I break my stuff apart into different scripts. That way I can pre-process a few things appropriate to the action, I don't end up with ridiculous dispatch tables and I can break one part of the site while other people are using other parts.

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.

[perrin]

This is exactly the problem that CGI::Application was created to handle.

[princepawn]

As long as you have a web application, Manfredi's CGI::MxScreen is great, I would say even a bit more feature-packed than CGI::Application. However, I am not impressed with it as a product for developing web areas... I consider Yahoo a webarea. And a simple set of screens as a web application.

[princepawn]

Some form of multiple argument dispatch may be in order. If I wanted to continue in your style, I would follow one of the means of doing so discussed in Conway's Object-Oriented Perl.

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.

[princepawn]

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

A few more things:
• How come the submit button(s) of the form isn't enough to decide what to donext? That, in conjunction with HTTP_REFERER are enough in most cases. It keeps your dispatch table down to do dimensions. One dimension is the value of the action and the other is the value of the REFERER.
• I wonder why you had to present such an unrealistic example in your initial post. Can you supply us with a real-word example of your case-based form dispatch?

[DrZaius]

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?