cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: [RT] Revisiting Woody's form definition
Date Thu, 31 Jul 2003 14:50:24 GMT
Marc Portier <mpo@outerthought.org> writes:
 
> Andreas Hochsteger wrote:
> > Hi!
> > 
> > A short question comes to my mind, while reading your RT:
> > Is it possible to use data types which are composed of several HTML
> > input fields?
> > We are currently using three input fields for dates (day, 
> month, year) 
> > at our current form solution.
> > 
> 
> No, not currently...
> 
> I had a proposing shot at this some weeks ago, see some remarks 
> hidden in this posting:
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105712568410208&w=2
> 
> in short: I think the existing aggregate-widget could be adapted 
> to support this
 
This is an extremely important issue in a generalized form building
system.  It's more than just splitting and combining a field, you really
want to completely decouple the rendering from the form model as much as
you can.  If course that's one of the things that XSLT is all about
which takes one full circle into templating languages: at some point
isn't it just easier to find a way to plug in custom XSLT transforms for
rendering?  Maybe not full scale XSLT, but perhaps rather something
along the lines of what Schematron does (element rule matching) only for
rendering.  If the element has a rendering rule (a full scale XSLT
template inside of some XML object) you apply it to create the output
representation, otherwise you get the default rendering.  Similarly, if
the element has a collection(?) rule (what's the opposite of rendering?)
you run it as a XSLT template.  Not sure if that would work for you
guys, but it's likely where we're headed...


Mime
View raw message