in reply to Encapsulating web client side code in Perl modules?

Caveats? Sure, here's one: Bye-bye browser back button and with it the principle of least astonishment. It can be worked around in a dirty hackish kind of way, but it's something to be aware of and always worked around if you care about it. The easiest workaround manipulates the browser history on each update, bringing the back button back into more or less normal operation, but then the astonishment (somewhat) remains because the browser history grows and grows and pushes things the user might want to get back to right off the stack.

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

  • Comment on Re: Encapsulating web client side code in Perl modules?

Replies are listed 'Best First'.
Re^2: Encapsulating web client side code in Perl modules?
by varian (Chaplain) on May 08, 2007 at 07:39 UTC
    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.