Paradigms for CGI application development?

[David Dick]

Michael Stillwell wrote:

> Good CGI discussion this week!
>
> I've been thinking recently about some of the more crapful aspects of 
> CGI application development.  In particular, what techniques to people 
> use to get around the fact that CGI applications don't get the 
> (surprisingly helpful) implicit preconditions and automatic stack and 
> scope maintenance bits and pieces that regular applications get for 
> free (simply by ordering and nesting statements)?

The way i've always thought of it is that CGI/mod_perl development is 
_always_ going to be significantly slower than GUI apps to develop, 
because you have to build everything in CGI from scratch, namely the 
truely horrific possiblities of stateless connections (attaching 
last_updated & last_updated_by fields to _every_ screen of updatable 
data  at least).  However, the longer development cycle is far 
outweighed by the fact that a bugfix/feature add to an application 
rolled out to 100's+ users can be re-rolled out in a matter of 
milli-seconds with a CGI app.  (It also means that you are developing 
with the maintenance cycle in mind, so it's more important than usual to 
comment and code cleanly. :)

Another thing is that lots of the stuff you mention can be significantly 
reduced by getting a good application framework.  I can't say I can 
recommend one (anyone?), cos I tend to carry around one that i wrote 
myself, but once you get comfortable with a good framework, a lot of 
these hassles should go away.

>
>
> For example, in a regular application, to get the user to confirm the 
> transfer of some amount of money from one account to another is a 
> matter of a few lines of code like:
>
>   if (confirm(sprintf("Really transfer %d dollars from %s to %s?", $n, 
> $a1, $a2))) {
>     # DO TRANSFER
>     message("Transfer successful");
>   }
>
>   else {
>     # ABORT TRANSFER
>     message("Transfer aborted");
>   }
>
> To get the equivalent effect in a CGI application (where the "confirm" 
> screen appears on a separate page) you need to do an amazing number of 
> things yourself:
>
> 1. Because Perl doesn't make it very convenient to jump (or transfer 
> control) to the *middle* of a function (actually, I'm not sure that 
> this is even possible), you need to break your functions in two 
> whenever you seek user input.  So in the example above, the code 
> following the call to confirm()  must appear in a separate function.  
> Another shitty consequence of this is that you must supply the "return 
> address" to confirm() yourself:
>
>   sub transfer_part1 {
>     # ...
>     confirm("Really transfer?", "transfer_part2");
>   }
>
>   sub transfer_part2 {
>     my ($result) = @_;
>
>     if ($result) {
>       # DO TRANSFER
>     }
>
>     else {
>       # ABORT TRANSFER
>     }
>   }
>
> 2. You need to save and restore state information, so that when you 
> return from the confirm "call" (in transfer_part2()) you know what $n, 
> $a1 and $a2 were, as well as what the account number was, etc.  (And, 
> you can't use any sort of conventional stack for this because you have 
> almost no control over the route the user takes through your program.  
> For example, you can't even guarantee that confirm() will return 
> before something happens elsewhere in your program, because the user 
> backed up a few pages and hit submit.)
>
> 3. You need to confirm, in transfer_part2() that the user really is 
> who they say they are.
>
> How do people get around these problems?  Why is the code for web app 
> UIs very different to that of desktop app UIs?  I suppose some of 
> these problems could be solved if the web server kept the running 
> program in memory across requests (instead of starting a new instance 
> each time), but I don't know of any system that does this.  Are there 
> any?  (And I haven't thought about it much, but I suspect this 
> approach would also be horribly complicated too, albeit in different 
> ways.)
>
>
>
>
>
> --M.
>
> * * *
> http://beebo.org
>
>