cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [woody] binding the forms to data
Date Wed, 02 Jul 2003 06:01:07 GMT
Nathaniel Alfred wrote:
>>-----Original Message-----
>>From: Marc Portier []
>>Sent: Dienstag, 1. Juli 2003 09:47
>>Subject: Re: [woody] binding the forms to data
> ...
>>>A general load/save binding specification in XML can get pretty
>>>nasty for real-world examples with one-to-many and many-to-one 
>>>mappings between external form and model attributes.
>>yep, thought crossed my mond, although defining some 
>>straightforward 'actions' in the binding should do the trick
>><bnd:repeater ..>
>>  <bnd:action event="insert-row">
>>    <bnd:insert-node>...template to insert...</insert-node>
>>    <bnd:set-attribute name="status" value="updated" />
>>other issues you see?
> I was rather thinking of dates stored as one attribute in the
> model and displayed as three widgets day/month/year.  There I
> can't think right now of a syntax for describing this sort of 
> decomposition and aggregation in general without reverting to
> special datatypes.

this binding idea I'm chewing on surely points me into the 
direction of some more serious datatyping sooner or later

I also think the initial foundations for that are already inside 
woody which is not so odd: the html-form submits will only render 
strings, so IMHO the point in having widget.setValue() take an 
object actually would be to have a dataconversion available to 
convert the String into the datatype you like...

just nobody started adding any datatypes yet
(me too just focussing on this mapping first)

mmm, in fact, if this binding takes place it might stress the 
need for refactoring the current dataconversion from woody in 
such a way that it could be reused from this binding side as well
(and thus from arbitrary controll logic that decides to do set 
the form-values programatically)

> Maybe you have?

hm, sounds like opposite of the new aggregate-widget? (recent 
addition, don't think there is documentation for that yet)

or even just the same thing but used from a different angle?

this aggregate-widget allows to group multiple fields into one 

example of its current behaviour:
(think phone-number: backend works and validation rules expressed 
on level of split country-code, area-code and local number, yet 
the end user is editing all of this in one box)

   <wd:aggregatefield id="phone" required="true">
     <wd:split pattern="\+([0-9]{1,3})-([0-9]{1,4})-([0-9]{5,7})">
       <wd:map group="1" field="cntr"/>
       <wd:map group="2" field="area"/>
       <wd:map group="3" field="number"/>
       <wd:failmessage>Phone nr format should be like 
     <wd:combine expression='Concat("+", cntr, "-", area, "-", 
       <wd:field id="cntr">
         <wd:datatype base="string"/>
       <wd:field id="zone">
         <wd:datatype base="string"/>
       <wd:field id="number">
         <wd:datatype base="string"/>

and binding to this would probably be something along the lines of:

<bnd:aggregate id="phone" path=".../PhoneNr" >		
     <bnd:field id="number" path="local-nr" >..</>
     <bnd:field id="area"   path="area-nr" >..</>
     <bnd:field id="cntr"   path="country-nr" >..</>

at first glance the new date-example (oppositely splitting one 
information-element into multiple editable fields) makes it 
almost sound like a styling issue: representation decission to 
let user edit date or in 1 box or in 3 separate date-month-year 

but that approach hides the fact that some specific widget needs 
to know about dealing with the multiple submitted 
request-parameters... so it really calls for some defining on the 
level of the woody-form-definition

eg., birthdate.month, birthdate.year
coming from some

   <wd:aggregatefield id="birthdate" required="true">
     <wd:split pattern="([0-9]{2})/([0-9]{2})/([0-9]{4})">
       <wd:map group="1" field="date"/>
       <wd:map group="2" field="month"/>
       <wd:map group="3" field="year"/>
       <wd:failmessage>Dates in DD/MM/YYYY please</wd:failmessage>
         expression='Concat( date, "/", month, "/", year)'/>
       <wd:field id="date">
         <wd:datatype base="string"/>
       <wd:field id="month">
         <wd:datatype base="string"/>
       <wd:field id="year">
         <wd:datatype base="string"/>

(NOTE: above doesn't work today in this scenario - just want to 
be clear)

and then the binding could just hook in with some binding on the 
level of the aggregagate field rather then on the sub-levels

<bnd:aggregate id="birthdate" xpath="person/details/birthdate" />

all, of the above highly hypothetical, would need to think about 
this some more...
mind again: there are some obvious collisions to what aggregate 
is currently doing that would need to be sorted out:
- aggregate-field now doesn't have the goal to render more then 
one wi:field in its publication line towards the html --> so you 
don't have the opportunity (yet) to make the 'styling decission' 
for one or multiple <input fields>
- and consequently it is not expecting any sub-parts submitted 
back from the browser AFAIK

other views?

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message