Flow script + XMLForm = killer combination

Posted on Tue 22 April 2003

XMLForm is a solution provided by Cocoon to handle forms. It's composed of two parts : an Action, which is supposed mimic Struts, and a Transformer, which handles population of form data from the data model using an XForms-like syntax.

I always found the XMLForm action to be too heavy (requires a lot of Java coding) and poorly designed compared to other Cocoon components. The Transformer, however, does its job well, even if its code is... ehrm... messy.

Enter the flow script and the integration of XMLForm and flow written by Andrew Christopher Oliver. All I can say is that it kicks ass !!!

I needed to set up quickly a demo of an interactive editor for highly structured XML document specified by an XMLSchema. Spent a few days (and nights) working on a layout stylesheet and some client-side JavaScript, and the demo was then a breeze to set up ! Multipage wizards with lots and lots of inputs organized in groups, tables, with expandable collections, detailed validation messages, etc, etc. The customer instantly decided to go with us on this project. Cool !

What's needed now is automatic validation using an XMLSchema (I'm planning to use the partial validation features of MSV). The XMLFormTransformer also needs to handle nested repeat tags and I'm thinking about refactoring rewriting it so that it is more maintainable.

Or should I take the Woody train just started by Bruno ? At first sight, it looks yummy, but I'm wondering if defining validation rules inside form layout is good or if they should be better separated in a schema. SoC, or over-SoC ?

After reading the docs, I was wrong about Woody : the "form definition file" is actually a schema (I was confused by the name and the presence of labels), and the "form template" is actually the form itself, populated with values from the (let's call it so) form schema instance.

Some questions, though :

  • my demo mentioned above (which lives on a public site - just ask me where) allows creation of new elements in a collection on the client-side. Can Woody handle that (this means a repeater can accept new items from the incoming request) ?
  • the expression language is yet-another-expression-language. Please, use one of the existing ones like XPath or Jexl !�
  • is it really different from Torsten's Precept (schema-driven validation) ?

Mmmh... interesting discussions are coming !

Update again
Steven pointed out the confusion that I once again did between the "Oliver's" : the guy that brings so much nice stuff in Cocoon's flow engine is of course Christopher. Sorry to have once again made this mistake. "Andrew" must be engraved in my brain because of its numerous rants. Be assured that I only mix the firstnames (maybe also because their last name is also a firstname), but not the people nor the work they do.

Update again and again (sep 2003)
If you find this page now, please consider the changed that occured in the previous months: don't use XMLForm, but Woody! XMLForm is buggy, limited and has security weaknesses. Woody is very strong and featured.

New bloggers

Stefano's Linotype