cocoon-dev mailing list archives

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

> Christopher Oliver wrote: 


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

Sorry, I just meant to say that you indicated that XMLForm works well 
with Flowscript.

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

Hmm, that link came from Google.

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

I don't think this is a limitation of using JXPath per se. It should be 
possible to add a parsing step into the form population process if that 
is desired. But we need to determine how to express the parsing rules 
and include that in the form specification.

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

How exactly did you hack XMLFormTransformer?


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

Good question.


View raw message