The notion that web applications have to respond to more than one context has always struck me as being less-than-optimal. Imagine a typical web form: we tend to use a Perl/CGI program to draw up the form (context 1) and when the user submits the form data some parameter gets checked to see what context we are in, and we accept the form data via the same program (context 2). The first lines of code in the program center around finding out what context it is supposed to be in. Furthermore the program has to have multiple sections of code, each dealing with actions related to a particular context.

What you describe is the fundamental nature of HTTP and web application development, which has been codified and encapsulated in modules such as CGI::Application.

In CGI::Application, you designate a particular HTML form parameter to identify the "run mode" of your application. By default this is "rm". So, for example, your run modes might be: "show_form", "submit_data". Those particular run modes are then mapped to Perl functions. (By running through a map, as opposed to just eval-ing a parameter, is that you avoid malicious web requests from running arbitrary code.)

One thing CGI::Application brings to the table is encapsulation of your web app code into a Perl module, as opposed to a "script". This permits all sorts of reuse and good practices.

To be clear, the alternative to putting all your various run mode functions into a single file (i.e., Perl module) is having one file per function. This is the approach used by so-called "server page" systems, such as Mason, EmbPerl, JSP, ASP, PHP, etc.

Some people prefer these types of systems. I do not. In my opinion, a web application is a collection of functions which are closely related. For example, you would not use your "show_form" function separately from the "submit_form" function because the two are operating on a particular form with specific fields and a specific desired behavior. I'd rather have those functions all together in one file for easier management.

Also, on a more philosophic point, the underlying assumption in server page systems is that the number of functions is equal to the number of "pages" in an application. This is not true. In fact, the number of functions is equal to the number of CONNECTIONS between pages. IOW, you might have one edit form which is used to both edit, and create a record. A server page system would require that you have a big if-then-else block to differentiate an edit from a create function.

Also, you have functions without any page at all. Consider a delete function which returns the user to the search form with a message. In server page systems that ends up being a file with Perl code and a redirect, as opposed to just outputting the search form function. Ugly.

With regards to AJAX, the run mode structure is particularly useful. A single page might now have half a dozen run modes for updating various bits. In CGI::Application each of these map to a simple Perl function, making implementation a snap.

Warmest regards,

-Jesse-