cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: Help with <fb:multi-value/> binding - CFORMS
Date Fri, 16 Apr 2004 06:22:03 GMT

Daniel Fagerstrom wrote:

> Marc Portier wrote:
> <snip/>
>> For the interested reader, some more info:
>> [1 - on the reported error]
>> The error 'factory is not set' from jxpath indicates that no 
>> node-factory (jxpath terminology) is available (to the jxpath context) 
>> to create new 'nodes' in the backend (i.e. a bigger array in the bean, 
>> or additional objects to add to the list).
>> I assume the multi-value binding was only tested versus XML backends 
>> since those have by default a node-generation factory installed (and 
>> thus the problem never occurs)
> Yes, I only tested the XML binding part. I wrote a note about that in 
> ths CVS-log, a note in the javadoc or the wiki-doc that I newer wrote 
> had been easier to find I guess ;)

well, objectively they're equally easy to find of course, it really is a 
matter of what comes first to mind (yes, often the wiki :-))

>> Towards javaBean backends this reveals that the the multi-value lacks 
>> the feature of declaring such a factory (to compare: this is what the 
>> <on-insert> inside the repeater binding is for)
>> IMHO multi-value binding code looks like an early clone of the 
>> simple-repeater binding.  This issue kinda re-affirms my feeling that 
>> there is no reason to maintain this multi-value-binding in the future.
> Yes, it is based on the simple-repeater binding code. First I tried to 
> reuse the simple-repeater binding whithout doing copy and modify, but 
> the data model for the multi-value widget and the repeater widget are 
> quite different so it would have required a refactoring of both widgets, 

yep, I realize that, the other approach is to solve everything in some 
wrapper on the side of the binding, but it seems a tad more logical to 
have some RepeatableWidget or IteratableWidget interface that could be 
implemented by both.  That would make it easier for some common binding 
to attach to both.

The feeling I still have is that these repeatable widget-values (i.e. 
the rows to the repeater-widget) would need some notion of their 
'identity' which for a multivalue-field seems to be not-existent (it 
behaves like a bag, not a list), and in other use cases would boil down 
to their 'index' (meaning the identity is their position in the 
surrounding RepeatableWidget)

>  and that propagates to a lot of other code in the form framework, 
> something that I didn't have time to do when I wrote the binding code :/ 
> I agree completely with another of your posts that we have to refactor 
> the form code so that it becomes comprehensible and that now is the time 
> to do it.
> IMO we need better interfaces for the widgets than the current ones: 
> Widget and ContainerWidget. If we take a look at the repeater widget it 
>  implements ContainerWidget but it does not contain real implementations 
> of the (to few) methods of ContainerWidget, instead it uses a number of 

I started a page on the wiki [WoodyRefactoring] to capture the floating 
impl-ideas-on-this-refactoring, feel free to jot down your hints when 
you come down to it...

> own methods for accessing its contents. The multi-value field does not 
> implement container, but instead uses an Object[] as input and output. 
> What we need are interfaces for container widgets that contains enough 
> methods so that the "repeater" binding can be written in terms of the 
> interface instead of in terms of the repeater class. Then the 

yep I agree, but I think it is another aspect then the Container thing
container == have child-widgets
iteratable == have mutliple values

(I think I now finally parse Peter's hint some weeks ago saying that 
being multi-valueable is just an aspect that could be attached to 
different widgets)

> multi-value widget should implement this interface and we could through 
> away the mult-value bindning.

good idea.

>> [2 - on the confusing naming of the bindings]
>> Of course this leads me to some other observation: the names of the 
>> bindings are way too look-alike to the names of the widgets!
>> Because of this the misconception has grown that the binding file is a 
>> duplicate of your definition file that needs to allocate the matching 
>> binding-component to the matching widget. THIS IS NOT THE CASE. (see 
>> e.g. the last binding-sample '03aggregate': there an aggregate widget 
>> gets bind using both the aggregate-binding and the value-binding: that 
>> just works, and it's not a hack, nor an after-thought.)
> I believe that the "misconception" depends on the weak interfaces for 
> the widgets that in turn makes the binding classes more widget specific 
> than they ideally should be.

more +1

> Need to review the widget and binding classes in more detail to give any 
>  more detailed suggestion on what the stricter interfaces should look 
> like, though.

good ideas, they surely help clearing out

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

View raw message