Hi Sylvain,Exactly right.
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).
The good thing about Jexl is that it is nearly identical to Javascript, making the form template's expression language well-integrated with the Flowscript layer that calls it. The good thing about JXPath is that it makes the form template's expression language well-integrated with that of the XSLT stylesheets that follow it in a pipeline.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:
<snip/>
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<snip/>
-------------------------
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.
The Woody expression language doesn't seem to be documented, nor is its source code present in CVS. So I can't say there's a problem with it. It may be fine, but we need people to try it and find out. For that to happen it needs documentation.
I agree. But there are several features that XMLForm has that I would like to add to Woody first, before it can replace XMLForm, namely:
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.
<snip/>
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! ;-)
1) Support for automatic back/next navigation in multi-page forms using continuations.
2) The ability to programmatically add validation errors to Woody widgets from a Flowscript. This is needed because it may be easier to enforce some constraints by writing JS code, and because you may need to access a back-end system in order to perform the validation.
Regards,
Chris
