Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

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

by BMaximus (Chaplain)
on Jun 01, 2001 at 03:34 UTC ( #84792=perlmeditation: print w/replies, xml ) Need Help??

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

Replies are listed 'Best First'.
Re: CGI/Mod Perl Application Design philosophy - which way do we go?
by lachoy (Parson) on Jun 01, 2001 at 07:36 UTC

    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'; }
      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?
Re: CGI/Mod Perl Application Design philosophy - which way do we go?
by jepri (Parson) on Jun 01, 2001 at 06:09 UTC
    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.

Re: CGI/Mod Perl Application Design philosophy - which way do we go?
by perrin (Chancellor) on Aug 15, 2001 at 21:40 UTC
Re: CGI/Mod Perl Application Design philosophy - which way do we go?
by princepawn (Parson) on Aug 16, 2001 at 05:32 UTC
    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.
Re: CGI/Mod Perl Application Design philosophy - which way do we go?
by princepawn (Parson) on Jun 01, 2001 at 03:38 UTC
    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.

Re: CGI/Mod Perl Application Design philosophy - which way do we go?
by princepawn (Parson) on Jun 01, 2001 at 03:42 UTC
    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?
      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?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://84792]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (8)
As of 2021-03-02 19:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My favorite kind of desktop background is:











    Results (62 votes). Check out past polls.

    Notices?