cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: [RT] forms
Date Fri, 20 Jul 2001 14:49:52 GMT
On 20.Jul.2001 -- 10:38 AM, Torsten Curdt wrote:
> > I think there is also some kind of intermediate format necessary which
> > represents the evaluated form.
> Hm... damn! I do really propose not to use extensions! So this gonna be
> tricky one then - back to the conformance problem :(
> Christian - these are the problems I was thinking of...

I didn't get that one. What is meant by "evaluated form"?

The problem consists of several problem areas:

  1) specification of a form on a XSP or XML file
     This should be as close as possible to XForms.

  1a) filling selections with data from a database
     This could be done either by e.g. ESQL or a transformer. Caching
     issues arise and should be dealt with. This is probably not a
     (core) feature of a forms package.

  1b) filling instance data
     1b1) from invalid request
          This could be done by request taglib (or similar for XMLized
	  parameters), but aided by form package that this happens
	  automatically. If we're about to do it with a taglib, this
	  would be easy. It must be determined, if the user has seen
	  this form so that default values are replaced.

     1b2) generating defaults
          This seems very application dependant and should be done by
	  a dedicated package / taglib.

  2) transformation to output media
     This stage should be feeded 100% correct XForms data.

     2a) -> HTML4.0 / XHTML / MS-HTML / NS-HTML / ...
         A sample stylesheet should be provided that could serve as a
	 basis for site specific rendering. Need to decide on
	 presentations from choices listed in XForms WD.

     2b) -> XML (XForms compliant devices)
         No transformation necessary

     2c) -> other media / formats
         Contributed samples?

  3) Data returned from client
     XForms require XML representation. We could do that and contruct
     a request attribute of type DOMObject that contains all the
     data. Upside: validation could be delegated to xerces Downside:
     all other c2 components know nothing about this format. 
     Of course we could have both.
  4) Form validation
     Form validation supplied with c2 is not remotely compliant with
     XForms. Still it could be used until a better solution is there.

  5) Subpages
     Something in sitemap.xmap needs to know about subpages and chose
     the right pipeline / parameters. Needs to be aware that clients
     might be XForms compliant and support subpages themselves.

  6) Accessing submitted data
     Request taglib does it already. Either return plain parameters or
     the constructed DOMObject from attributes.


C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

To unsubscribe, e-mail:
For additional commands, email:

View raw message