+--------+ +-----------+ |repeater| <----> |contextbean| +.-------+ +-.---------+ | +---+ | +----+ ----|row| <----> -----|item| +-.-+ +-.--+ | +------+ | +--------+ --|widget|<----> ---|property| +------+ +--------+
In the case of nested childs I meet the situation where we often wrote:
<fb:value id="key1" path="key1"/> <fb:value id="key2" path="key2"/> ...
So the question is:
Can we "save" typing by defining a default value for @path. That way we can also write:
<fb:value id="key1"/> <fb:value id="key2"/>
And in this way the machine will fill the @path for me.
Hmm, I absolutely don't like this. As Marc wrote this are two different things. On the one hand there is the form model, on the other hand the backend model. The above would end in some auto magic, that is not very obvious IMO.
[case 4] (aka current RepeaterBinding) DESCRIPTION: - items have an explicit identity and can be sparsly bound - form-model can add/remove but should not allow reordering of the rows - the original sequence of the items is to be maintained at all times (on-insert really is more of an on-append: no new ones can be inserted in between the old ones)
STRATEGY on 'save': - foreach row in repeater - if identity match found in items - bind to that
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/binding/RepeaterJXPathBinding.java?annotate=1.3#163
- add it to the set of updatedItems
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/binding/RepeaterJXPathBinding.java?annotate=1.3#167
- else - add it to some list of rowsToInsert
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/binding/RepeaterJXPathBinding.java?annotate=1.3#173
- run through items - if NOT found in updatedItems - add to list of toDeleteItems (ndx will do)
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/binding/RepeaterJXPathBinding.java?annotate=1.3#192
- register the on-insert as factory - foreach row in rowsToInsert - create and bind it
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/binding/RepeaterJXPathBinding.java?annotate=1.3#220
- foreach ndx in toDeleteItems in reverse order - use on-delete to remove/mark
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/binding/RepeaterJXPathBinding.java?annotate=1.3#196
Don't know the current RepeaterBinding do that! It distribute the result on 3 diferent sets? It would be useful in some cases.
See the links including the line numbers above.
While writing up this proposal I end up questioning a number of (historically chosen) names that could change:
- repeater/@parent-path --> repeater/@path for consistency with the order bindings
repeater/@base-path
- repeater/@row-path --> repeater/@item-path since it is pointing to items, not rows
Here I will propose just repeater/@path. The same name as in <fb:value>. It would be fine. While starting using Cforms I often found myself asking by the right name. I cannot stop thinking in the repeater as a List.
This goes in the wrong direction and is more confusing than before IMO. The repeater itself must be bound to @path, not the rows.
Joerg
