cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [RT] XMLForm
Date Mon, 26 May 2003 07:15:53 GMT
On Sun, 25 May 2003, Stefano Mazzocchi wrote:

> 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 second that from practical experiance.

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

+1

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

We had our experiance here and, as soon as time permits, I'll come up with an
'how-to' on jxform/flow based application development. There are some caveats
you'll have to take care of for bigger than the Calculator sample application
(ie. the pitfalls you run into because of the global space for functions in flow
scripts).

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

The one shipped with jxform has seemed to us much more optimal (and we didn't
had the need to copy it into our project at all for most forms we have). There
are cases (ie. multiple forms in a page, vertical layout of forms instead of
horizontal) where on would like to have more options available for
styling/layouting the forms.

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

+1

As I said above, I'll contribute (sooner or later) some how-to pages for
jxform/flow.

Giacomo

Mime
View raw message