cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Help with <fb:multi-value/> binding - CFORMS
Date Thu, 15 Apr 2004 16:32:43 GMT
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 ;)

> 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, 
  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 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 multi-value widget should implement this interface and we could 
through away the mult-value bindning.


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

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.

WDYT?

/Daniel

Mime
View raw message