[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xml-cocoon-dev
Subject:    Re: [RT] Revisiting Woody's form definition
From:       Sylvain Wallez <sylvain.wallez () anyware-tech ! com>
Date:       2003-07-31 15:54:49
[Download RAW message or body]

Hunsberger, Peter wrote:

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

That's exactly what I did for an XMLForm-based prototype : a few 
"UIType" attributes on XMLForm's widgets drive the layout :
- UIType="calendar" on a <xf:textbox> changes the input to a input+popup 
calendar
- UIType="table" on a <xf:repeat> changes the group's layout to a table 
(each set of children becomes a table row) while the default behaviour 
is to layout each set of children as an html <fieldset>

This allows the template (going back to Woody terms) to completely 
abstract the rendering details of the layout, and concentrate only on 
the description of this layout.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -  http://www.orixo.com


[prev in list] [next in list] [prev in thread] [next in thread]