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

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

Replies are listed 'Best First'.
Re: Re: CGI/Mod Perl Application Design philosophy - which way do we go?
by simon.proctor (Vicar) on Jun 03, 2001 at 00:58 UTC
    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?
[reply]
[d/l]
[select]

In Section Meditations