Agylen

Sylvain Wallez: Ajax in Cocoon: dead simple!: “Today, I added Ajax support to Cocoon, starting with form handling.”

If you’re not familiar with Cocoon Forms, let me tell you why this is important and not just the latest indulgence to a passing fad. We actually discussed adding this to Cocoon Forms at the latest GetTogether, long before the term Ajax was even invented.

Cocoon Forms is arguably the coolest web forms framework out there that is entirely HTML-based. In other words it is compatible with most browsers and does not require plugins, XForms support or other proprietary extensions, which can be very important.

Cocoon Forms makes it very easy to add some amount of dynamism to forms, ranging from simple cascading drop-downs (selecting an item in a drop-down list causes another list’s contents to change) to repeaters (repeating sets of input fields where you can add, remove and move items) and to more exotic use cases like unions (sort of variants).

All very cool, but whenever the structure of a form changes, a complete HTTP request-response cycle is executed and this has some unpleasant side-effects:

1. A round-trip to the server and back can be slow.
2. The entire page is refreshed and you lose input focus and scrollbar position.
3. The back button does not bring you back to the page before the form, but to the previous version of the form itself.

This is where using XMLHttpRequest comes into play. Using it, you can refresh only the portion of the form that needs changing and you can do it much faster, resolving all of the above-mentioned annoyances. The fact that XMLHttpRequest support in Cocoon Forms is completely transparent, as far as I understand, and falls back to the traditional behavior when the browser does not support it, is simply incredible.

Kudos to Sylvain for coming up with this brilliant solution which will undoubtedly strengthen Cocoon’s position as the most powerful web application development platform!

Geert Bevin has a nice write-up here of Spring Web Flow’s “out-of-the-box continuations support”:

Spring Web Flow however only provides continuations in the flow declaration (can be both in XML and in Java), thus lacking what in my opinion is the single most interesting feature of continuations.

Having used Cocoon’s continuation-based Flowscript, I tend to agree with him. The real difference between Cocoon and RIFE, on one side, and Spring Web Flow on the other, is the fact that continuations are a native feature of the flow language and you can create a continuation everywhere in the code.

Rewriting Geert’s example with Cocoon, you’d get:

while (guess != answer)
{
    // print the guess form and wait for a response
    cocoon.sendPageAndWait(template); 

    // obtain the guess
    guess = cocoon.request["guess"];
    ....
}

Not that different from the RIFE version, really. Spring’s version would look more like this.

Now, if someone would take Cocoon’s Flowscript (or Javaflow, if you don’t like Javascript) and adapt it to Spring’s Web framework, that would be interesting.

Micah: “The Apache Cocoon project, where I was honored to work recently, is a central hub of state-of-the-art XML templating engines.”