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 Tue, 01 Jul 2003 07:47:08 GMT

Nathaniel Alfred wrote:
>>-----Original Message-----
>>From: Marc Portier []
>>Sent: Dienstag, 1. Juli 2003 07:37
>>Subject: [woody] binding the forms to data
> ...
>>The actual binding definition file could be filled with:
>><bnd:field id="widget-name"
>>            path="xpath expression into model" />
> I don't see the added value of putting the binding definition into
> a separate file.  It should be inside the woody-definition file to
> avoid yet another maintenance nightmare of joining two XML files by
> an id. 

mmm, the set of ids in the form-model are pretty much it's 
contract to the outside world

if you need to code getWidget(id).setValue(..)
then the nightmare becomes syncing the java code with the XML 
file... there is not that much that binding can do to prevent 
that IMHO?

sliding everythin in one file might result in the opposite of 
your own 'simplicity' baseline?  (see further)

might be me being too overly SoC concerned though...

>>Using JXPath there should be a fairly easy way to have this 
>>binding work for a backend producing either javabeans or XML files.
>>what do people think?
> The possibility to define constant initial values in <wd:datatype>
> is urgently needed.  To have an easy way to set it dynamically would
> be really cool.
> <wd:field id="widget-name">
>   <wd:datatype base="string">
>     <wd:initial>constant value</wd:initial>
>     <!-- or -->
>     <wd:initial path="'constant value'"/>
>     <!-- dynamic -->
>     <wd:initial path="xpath expression into model"/>
>   </wd:datatype>
> </wd:field> 

nice feature on the static side of things...

but, I think I am more ambitious on the dynamic side of things: 
I want the changed values to propagate back to the objectmodel.
(think editing XML documents for instance)

that is more then just 'initial' binding

> 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'd say Woody should stick to the rule to have a simple solution
> for simple problems and provide hooks for solving difficult problems
> in Java.

that is probably the biggest argument for keeping this binding 
into separate files.

maybe you like it more if you look at it as
FormManager builds Forms
Bindingmanager build Bindings

the code applies the binding to the form

as such woody's form model remains as simple as you like
the present hook for the code 'setValue' just got a more 
declarative way of exploiting things

to be totally clear: binding should never be required to be able 
to use a woody form.

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

View raw message