Joerg Heinicke dijo: > On 30.03.2004 10:15, Antonio Gallardo wrote: > >>>+--------+ +-----------+ >>>|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 us. > > 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.
I am not sure if here my DB oriented mind is strongly playing with me. But I really see the connection between both models. Maybe I am wrong, but I strongly believe it will be obvios in the future when people will get more in touch with JXPath. It is just an optional way to "save" typing". We can define it as: The default value of @path is @id is @path is not defined. >>>[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. I tought about the behavior for the user. Not about the internal implementation. Interesting for user is what get back and not how it compute the return value. >>>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. After 4 hours dreaming.... Here is the proposal: 1- repeater/@parent-path -> deprecated, use <fb:context> instead. ================================================================= The fact is while you wrote repeaters you will see you writing parent-path="." over and over with no change. Then you start thinking why it is so important? I already wrote it more than 100 times in diferent forms of a variety of complexity. 2-repeater/@row-path --> repeater/@path ======================================= We know the binding is a map between 2 models: The Widget Object Model (WOM) and the Businnes Object Model (BOM). But in fact, both models are often very similar. <fb:value id="field1" path="field1"> <fb:repeater id="list" row-path="list"> Is not clear the analogy? SAMPLE: ======= Given a bean defined as: Bean b { int field1; int field2; List list; // This is a repeater it contains other Beans of type BO. } Based on the JXPath theory, the Bean is easily mapped to XML as: <b> <field1/> <field2/> <list> <BO> <BO> ... </list> </b> Then the current binding is: <fb:context path="/"> <!-- This is the path for the bean --> <!-- Here we are at the Bean context --> <fb:value id="field1" path="field1"> <fb:value id="field2" path="field2"> <fb:repeater id="repeaterId" parent-path="." row-path="collection"> <!-- Here we are at the repeater context --> .... </fb:repeater> </fb:context> In fact the path of the repeater's rows is not in @parent-path context. In most cases the @parent-path context is the Bean context. Here the question is: Why define a @parent-path for <fb:repeaters> and not for <fb:values>? It is not enough given the already given <fb:context>? (See the first line of defined binding). Note: we already have a context "/" (<fb:context> and if we add the @parent-path to the current XPath context we got again: "/". It is not the same? If we need to change the current context path, then use the specific instruction to do that: <fb:context>. In that way @parent-path of repeaters can be deprecated. And given the fact that we are at already at Bean context while declaring the repeater => it is why is enough a "." value. ------------------------------------------------------------------------- The @row-path define the path where each item of the repeater resides. This is the same as for <fb:value> And here is where I see the analogy to the @path attribute in <fb:value> and not in the above case. Note, in the case of <fb:value> we don't have a @parent-path. If we have one then we will to write: <fb:value id="value1" parent-path="." item-path="value1"/> Hope it explain my POV. Best Regards, Antonio Gallardo
