cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: [RT] Comparing Woody & XMLForm : towards a unified form handling (long)
Date Wed, 23 Jul 2003 06:53:25 GMT
Bruno Dumon wrote:

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

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

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.

>  
>
>>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! ;-)
>  
>
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:

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


Mime
View raw message