-----Original Message----- From: Marc Portier [mailto:[EMAIL PROTECTED] Sent: Dienstag, 1. Juli 2003 09:47 To: [EMAIL PROTECTED] 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 widget
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:label>Phone:</wd:label>
<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 +32-9-3388220</wd:failmessage>
</wd:split>
<wd:combine expression='Concat("+", cntr, "-", area, "-", number)'/>
<wd:children>
<wd:field id="cntr">
<wd:datatype base="string"/>
</wd:field>
<wd:field id="zone">
<wd:datatype base="string"/>
</wd:field>
<wd:field id="number">
<wd:datatype base="string"/>
</wd:field>
</wd:children>
</wd:aggregatefield>
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" >..</>
</bnd:aggregate>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 boxes...
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.day, birthdate.month, birthdate.year coming from some
<wd:aggregatefield id="birthdate" required="true">
<wd:label>Date:</wd:label>
<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>
</wd:split>
<wd:combine
expression='Concat( date, "/", month, "/", year)'/>
<wd:children>
<wd:field id="date">
<wd:datatype base="string"/>
</wd:field>
<wd:field id="month">
<wd:datatype base="string"/>
</wd:field>
<wd:field id="year">
<wd:datatype base="string"/>
</wd:field>
</wd:children>
</wd:aggregatefield>(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?
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
