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.
WDYT?
good ideas, they surely help clearing out
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
