Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40694BE5.5080907@gmx.de>
Date: Tue, 30 Mar 2004 12:28:53 +0200
From: Joerg Heinicke <joerg.heinicke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [cforms] Repeater Binding Revisited.
References: <4068A237.6030006@outerthought.org>
 <34702.10.0.0.5.1080634508.squirrel@ags01.agsoftware.dnsalias.com>
In-Reply-To: 
 <34702.10.0.0.5.1080634508.squirrel@ags01.agsoftware.dnsalias.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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