cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] XMLForm
Date Mon, 26 May 2003 08:53:21 GMT
Christopher Oliver wrote:

> I received a private communication from Ivelin suggesting to replace 
> the XMLForm block with the JXForms implementation in the scratchpad, 
> incorporating features he added in his code for the 2.1 
> release.

Sounds good !

> I think this is a good idea as it will eliminate the fork, however I 
> think a discussion about the design and future development of this 
> form framework (and others) is needed. 

Yep. We need to go back to some specs !

> XMLForm works well with the current Flowscript implementation in part 
> because they both use JXPath. At least, Sylvain thinks so:

Huh ? I don't see where in this post I mention JXPath ??? Anyway...

Off-topic : what is ? Looks like it's an anonymizer, but why 
anonymizing access to my blog ? Anyway (again)...

> The use of JXPath allows XMLForm to automatically populate the 
> Flowscript objects with values from the request, and to make those 
> same objects available for validation using Schematron.

I think automatic form population through JXPath is one of the strong 
limitations for XMLForm, since it doesn't allow a clean definition of 
the data format.

Although this wasn't a problem for the demo above-mentioned in my blog, 
this is especially important, and even mandatory, when the form either 
contains non-primitive datatypes such as a date, or when the application 
needs to be i18n-ized. Woody seems to handle this better, but lacks 
XPath-like traversal (I may be wrong, as my Woody knowledge is limited).

Considering this, I think we need to have a combination of both : first 
parse form data to "native" (non-string) values using well-defined 
formats, then populate the form using these native values using an 
XPath-like syntax.

Something we must have also is the ability to handle instanciable 
groups. By this, I mean the ability to define a template that can be 
used client-side to define new elements in a collection without having 
to have to hop to the server. This allows great table-like forms where 
you can add/delete/move items. I have hacked the XMLFormTransformer to 
allow this for the prototype mentioned in my blog.

This prototype is however too customer-specific to show it as is, so I 
need to find another use case to showcase this. Any input welcome ;-)

> This makes it significantly more user-friendly for a Flowscript author 
> than using raw sendPageAndWait() and writing your own validation loop, 
> for example:
> XMLForm:
>  function myForm(form) {
>      form.setModel(...);
>      form.sendView("my/views/form/page1.xml");
>  } 

This flow integration is really, really powerful : the flow script just 
has to care about page flow, and no more about looping on the current 
form if validation failed.

<snip what="plain flowscript"/>

> Unfortunately, however, the stylesheets that are shipped with XMLForm 
> are not generic, but instead, apparently, must be reused in a 
> cut-and-paste fashion, and modified for each application.

Actually, there are two parts in the stylesheets : the layout 
(wizard2xmlform) and the widgets (xmlform2html). The layout is very 
specific, but the widgets seem to be generic enough to be reused as is.

> In addition, it seems quite awkward to incorporate an XMLForm form 
> into a larger application. For example, in the petstore sample, Leo 
> had to merge the XMLForm stylesheets as special cases in the main 
> application stylesheet. I attempted to improve this in JXForms, but I 
> think it needs the attention of someone with more expertise than I have.
> Finally, the documentation of XMLForm is, in my opinion, completely 
> inadequate and must be significantly improved if we expect widespread 
> use. Each syntactic element should be documented and examples of its 
> use provided. Documentation of the functionality provided by each 
> stylesheet is also needed.

What to say but +1 ;-)

> Please, add you comments. 

Something that must be questioned also is the relationship to XForms 
(the W3C one), which is targeted at client-side only forms, while we 
have to handle forms server-side. Sure, sticking as much as possible to 
the upcoming standard is good, but does the XForms syntax provide enough 
information to design and handle forms server-side ?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message