cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] XMLForm
Date Sun, 25 May 2003 21:33:51 GMT
on 5/25/03 2:30 PM 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 xmlform.org code for the 2.1 release.

Sounds like a very nice thing.

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

True. At the same time, in the past, I've seen lot's of disagreement on
how a form package should work, so my gut feeling is that we should just
polish the current most-welcomed form-handling package (which seems to
be jxform, from where I stand) and let the evolution of the package take
place.

This doesn't stop other attempts to be continued in parallel (Woody, for
example) but we should try to focus on something and get it going.
Fragmenting efforts and componentizations creates one-man shows (and all
form-handling packages today are such or perceived as such).

More than anything, we have to end this or balkanization will emerge
(the fork is already a sign of this)

> XMLForm works well with the current Flowscript implementation in part 
> because they both use JXPath. At least, Sylvain thinks so:
> http://mdsme.de/cgi-bin/nph-spinnerproxy.cgi/010110A/http/www.anyware-tech.com/blogs/sylvain/archives/000041.html
> 
> 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. 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");
>   }
> 
> Using plain flowscript:
> 
>   function myForm() {
>          var model = ...;
>          while (true) {
>                  sendPageAndWait("my/views/form/page1.xml", model);
>                  /* for each parameter: */
>                  var paramValue = cocoon.request.get(paramName);
>                  if  (/* paramValue is valid */) {
>                         model[paramName] = paramValue;
>                         break;
>                  }
>          }
>   }

Yes, this sounds like the simplest and more reusable approach to glue
flow and form-handling packages.

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

yeah, this is clearly unoptimal.

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

Expertise in what? xslt?

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

well, that could be said for many part of cocoon. ;-)

> Please, add you comments.

I'd be happy to see we concentrate on one form-handling package and
polish that.

-- 
Stefano.



Mime
View raw message