Paradigms for CGI application development?

[Daniel Walmsley]

I originally forwarded this to the wrong address. Apologies if these
concerns have already been answered (regardless, this is something of a
non-solution). Anyway, here we go...

I'm going to get flamed for this, I'm sure ;)

I've been playing with ASP.NET and Visual Studio .NET a little bit (a couple
of hours in total), and this is exactly the sort of thing they're heading
for. You create an application interface by dragging and dropping components
(calendar controls, buttons, images, data grids, etc) onto a form, and you
attach properties/events to them. Then when you deploy, they get compiled as
an .aspx page and a dll. The client is just a normal web browser (yep, I've
tested it with mozilla, and *almost* everything works - fscking Microsoft),
and the web server and .NET runtime handle session information and
everything works just as it was designed. It really is almost exactly the
same experience as writing a standard, client-side GUI application.

The other cool thing is that you can write one app, and have to turned into
WML, cHTML, HTML, or any number of other dialects on the fly, depending on
what client was detected. It irons out the differences as best it can. This
is a boon for non-geeks ;) Anyway, I'm sure open source will write/has
written a system to do just this ;)

Obviously there will be limitations when you let the runtime and coding
environment do this much thinking for you. It's like being in a self-driving
car while blindfolded - you know you should trust it, but you feel like you
should at least have your eyes open. Or something.

Oh, yeah - and the hood is welded shut. I think that's how it goes. A night
of drinking and Karaoke makes everything a teensy bit muddier.

-----Original Message-----
From: Michael Stillwell [mailto:mjs at beebo.org] 
Sent: Wednesday, 6 November 2002 12:09 AM
To: melbourne-pm at pm.org
Subject: Paradigms for CGI application development?


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)?

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