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
