cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: [RT] Comparing Woody & XMLForm : towards a unified form handling (long)
Date Tue, 22 Jul 2003 16:23:55 GMT
Hi Sylvain,

thanks for starting this thread, hopefully it will clear up the current
situation around the multiple form frameworks.

On a general note, and I understand that you know this, many arguments
of the comparison between the two change when you consider that in
XMLForm you should also have a separate form model and business model.
The security, inconsistency and (for a part) data conversion problems
dissapear and the extra work to copy between the form and business
models reappears (and also the statement about validations involving
form data and application data).

I think that for the most part our form-vision corresponds, though I
have difficulties understanding your proposed changes.

On Mon, 2003-07-21 at 20:44, Sylvain Wallez wrote:
> IMO, Woody's separation of concerns between form definition and template 
> is not that good. Woody would be easier to use if the definition file 
> was only a schema defining datatypes and if fields were defined only in 
> the template.

So you're still left with two files to edit and maintain...

> Although there is a great probability that datatypes can 
> be reused for different fields and even different forms, I'm not sure 
> using the same fields within different templates really make sense. For 
> example, HTML and WML browsers have so much different screen sizes and 
> interaction constraints that a single form definition can hardly be used 
> for both.

Agreed. It is however not so much about reuse but rather separation of
skills: the form template will mostly be edited by a HTML designer.

> Reusing datatypes for different fields would also increase the overall 
> application consistency : as of today, if two fields have the same 
> datatype and constraints, these must be duplicated.

Originally it was planned to have a datatype-library, but this has not
yet been implemented.

Note also that the concept of datatypes in woody is in fact an
implementation detail of the "field" widget. Not all widgets (i.e. the
repeater) have a datatype.

>  This could also open 
> the door to other schema languages (WXS, RNG, etc).

here I can't follow: WXS/RNG validate XML. How would those operate on
Woody's form-instance datastructure? And the datatype associated with a
single field will most likely not require structural validation, which
is exactly the main purpose of WXS/RNG?
Or would you replace Woody's form-instance datastructure with plain XML?

> Population and validation
> -------------------------
> Finally, Woody uses its own expression language, with IMO is not a good 
> choice if we consider that "standard" expression languages such as Jexl 
> exist and are already used in other Cocoon blocks.

I'm of course open to suggestions on this one. The expression language
currently used is quite generic, and not tailored towards any purpose,
which is not the case for e.g. XPath. Jexl seems to be better in this
regard, though also not quite perfect. For example, using the current
expression interpreter I can compare two date fields simply using
something like "date1 < date2", while this is not possible in Jexl.

> Mapping to the application data model
> -------------------------------------
> A form is useless if its content cannot be mapped in some way to the 
> application data model.

Strictly speaking this is not required, think of a search form or a form
that simply emails the user-entered data to some address.


>  Post-validation application behaviour can be added to either 
> a subclass of AbstractXMLFormAction or in a flowscript.

Woody will eventually also get such functionality.

> Conclusion
> ----------
> XMLForm has a lot of success because it has filled a giant need in 
> Cocoon applications to handle forms. Moreover, it fits nicely with 
> flowscript, and this combination builds an easy to use solution for form 
> handling. But using it in more and more complex use cases show some 
> strong limitations that are largely related to its desire to mimic 
> XForms. And I'm not sure these limitations can be removed without 
> diverging largely from the XForms approach.
> These limitations were obviously taken into account early in Woody's 
> design, which make it stronger at handling data formatting and enforcing 
> semantic constraints. But Woody, by over-separating concerns, is more 
> heavy to use.
> Considering all the pros and cons, I think Woody, which is still in its 
> infancy, is more promising on the long term and should be promoted, once 
> featured enough, as the preferred form handling package in Cocoon.

yes! ;-)

> Proposals
> ---------
> We've seen that Woody requires to separate form definition from form 
> template. I think (Bruno, correct me if I'm wrong) this constraint comes 
> from the fact that the form _is_ the model, and thus must be filled with 
> data _before_ being processed by the form template.


But what's not clear to me yet is whether you want to see this changed.

> The ongoing work on form binding considers binding as a process 
> surrounding form population and validation : the application->form 
> binding fills an existing form, and the form->application binding 
> transfers form data to the application model once the form is correctly 
> validated.

And in a flowscript, it's as simple as this (taken from

    var document = loadDocument(documentURI);
    var binding = loadBinding(bindingURI);
    var model = form.getModel();

    binding.loadFormFromModel(form.form, document);"form2-display-pipeline");

    binding.saveFormToModel(form.form, document);
    saveDocument(document, makeTargetURI(documentURI));

[The method will keep showing the form to the user until
everything is validated]

> Now we can imagine to have a "live" application->form binding occuring 
> at form definition time which could allow simultaneous building of the 
> form definition and population of form data from the binding. This 
> feature could remove the need for a separate form definition and could 
> be implemented by a WoodyTemplateGenerator taking as input a template 
> file containing field definitions.

So it would then be the responsibility of this WoodyTemplateGenerator to
build the form instance? And where would it store that?

I think the SAX-pipeline should have publishing as its only
responsibility, the preparation work should be done by flowscripts or
Java code (actions).

>  A kind of "definition by example" 
> (like the QBE that exists in Excel and various database systems).
> This "defining-template" would only define fields and not datatypes. 
> These datatypes could be either inferred from the application model 
> trough the binding or fetched from a separate schema file (the current 
> form definition, with only datatypes definitions).

I don't get it yet.

Let me start from a different angle: suppose that we would allow the
datatypes to be defined inline in the fields in the template, then the
template would basically be the same as the current form definition but
with foreign (HTML or other) markup mixed in between. Correct?

In the current Woody, it is then based on this form model that a form
instance structure is build, and thus in fact the form template now
serves as the "schema" based on which it is created. The fact that we
could allow the datatypes to be defined in another file doesn't change
much to that.

Hmmm, I'll have to sleep a night over all this... any extra hints you
can give to how it would work, and maybe what would exactly change or
remain of the current Woody are welcome.

Bruno Dumon                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message