Howzabout a pitfall: It's asynchronous, so if the sequence of client side events matters you might be surprised every now and then. Suppose you're using (for example) a scriptaculous Sortable to permit the user to rearrange things, and you don't want to force him to poke a button to tell the server that he's done sorting so you're firing off an XMLHTTP request on every drop (via Sortable.update and Sortable.serialize). Wow, slick. BUT, it's asynchronous, so the sequence in which the user does things is not necessarily the sequence in which the server responses to those things are received by the client. You can't count on things arriving at your server-side application in the order the user did them unless you jump through some hoops on the client side to (FIFO) queue your XMLHTTP requests. Then, if the server goes away, you probably need something on the client side to restore the client to the last known good state. Hello, Astonishment :(

You might give a look at HTML::Prototype and/or HTML::Prototype::Effects (scriptaculous "embedded" in Perl).

Thanks Gloryhack for the pointers and for listing these caveats. Indeed one needs to be careful where and when to apply XMLHTTP requests.
I am not too concerned about loosing backbutton functionality. This side-effect will be limited when one still uses regular page linking for a switch between menu choices and between forms. In fact the XMLHTTP requests can be used beneficial to prevent accidental re-posting of form data when the user hits a backbutton.

The prototype links indeed appear to come close to what I was looking for and I will investigate them further. In particular I am curious to see how they would interact with Perl code back and forth.

I am also grateful for the feedback from the other monks. As usual there's more than one way to accomplish things and the choices and tradeoffs mentioned provide insight.

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

Hmmm ... that must be the royal we. I sure don't do that. I tend to break my applications into different *namespaces*. This not only gives cleaner code (and less to mentally chew on) but allows me to play apache tricks (no access control on display and/or results but access control on updates).

As for Ajax, you can have the same big ball of mud as you do with *normal* cgi - its just cleared the picture for you. The picture was cleared for me when the access control became a biz requirement and became crystal clear when I started using CGI::Application.

And, Javascript isn't bad, particularly if you are using the Dojo toolkit.

And, Javascript isn't bad, particularly if you are using the Dojo toolkit.

Really any good (Prototype, MooTools, JQuery, etc) JS toolkit will make it pretty easy to work with.

-- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier

Of course the "context" issue has nothing to do with Perl or Java of AJAX or ..., it is just the way the web works and personally I rather have the context dealt with server side where I can control it rather than on the client's machine where Gods know what may have happened to it.

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-

Actually this strikes me as the wrong way to do it. Anytime you try to encapsulate one system into another you have 1 of 2 choices:

1. Limit your usage to only a subset of the wrapped system's functionality
2. Make your interface to the wrapped system just as complete and complicated as the wrapped system itself.

GWT (Google's Java system to have users avoid writing Javascript for AJAX apps) recently ran into problems with users because they needed to do things that were easy in Javascript but that GWT didn't provide an interface for. Now Java programmers using GWT have the option of passing in strings of Javascript that GWT then injects into the pages. Try debugging that if something goes wrong.

Plus their Java code is now littered with Javascript code. It's the same principle of littering HTML throughout your Perl programs. It was bad in the 90's and it's even worse now.

Why are you so scared of Javascript? It's not the same beast it was in the 90's and can actually be quite pleasant if you're using the right framework (my favorite poison is Prototype).

Javascript is only going to get more and more important for web technologies. You are really doing yourself a disservice by trying to hide from it.

Javascript OO extension that work with a dollar sign means that you have to be extra careful when embedding JS/HTML inside a Perl script, otherwise perl will try to process the ${'something'} as a perl variable and the JS won't work properly. Are there any recommended solutions to this issue, like a Perl module for communicating with Prototype / Dojo / Mootools applications?