Return-Path: 
 <dev-return-58422-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 31597 invoked from network); 30 Mar 2004 18:06:53 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 30 Mar 2004 18:06:53 -0000
Received: (qmail 60839 invoked by uid 500); 30 Mar 2004 18:06:41 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 60792 invoked by uid 500); 30 Mar 2004 18:06:40 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 60739 invoked from network); 30 Mar 2004 18:06:40 -0000
Received: from unknown (HELO smtp1.xs4all.be) (195.144.64.135)
  by daedalus.apache.org with SMTP; 30 Mar 2004 18:06:40 -0000
Received: from outerthought.org (195-144-088-083.dyn.adsl.xs4all.be
 [195.144.88.83])
	(authenticated bits=0)
	by smtp1.xs4all.be (8.12.10/8.12.10) with ESMTP id i2UI6fPQ012107
	for <dev@cocoon.apache.org>; Tue, 30 Mar 2004 20:06:42 +0200
Message-ID: <4069B72F.7080400@outerthought.org>
Date: Tue, 30 Mar 2004 20:06:39 +0200
From: Marc Portier <mpo@outerthought.org>
Organization: Outerthought
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
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
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N



Antonio Gallardo wrote:

> Hi Marc!
> 
> 
> Because seems like you will start soon. I will not miss the oportunity to
> get into. So here we go! ;-D

starting soon?
http://www.nederlands.nl/nedermap/gedichten/gedicht/32123.html?zoekresultaat=ja
(there is no way to translate, sorry, well, maybe if you get enough 
booze in me at the next get together and only after we had all the dull 
yank and aussie jokes...)


<snip/>

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

hm, I'm -0 on the same arguments Joerg just gave (automagical stuff)


<snip content="explanation on case 1 and 2 that probably wasn't clear"/>

> 
> 
> OK. As posted before (2) = extension of (1). If this is true, then we can
> avoid the introduction if the new: "@clear-items-on-save". The detection
> can be the same as ((1) && (<fb:on-insert/> || <fb:on-delete/>)
> 
> Because the <fb:on-insert> and <fb:on-delete> can be optional.
> 

not sure:
the @clear-items-on-save is a clear indication that you delibarately 
want to ignore possibly sparse bound items, there is nothing in case1 
that would make it do that by clearing the on-insert/on-delete

when we concluded that (2) == (1) it was only about the fact that the 
strategy algorithm would be the same AND surely implied 'only after 
clear of items'

> Suppose a form that allow a user just to insert/edit items and other form
> for of the same data that allow user only delete items. ie: a very simple
> ticket system when the receptionist assign new tickets and the service
> personal delete them. Of course I know tickets system that store each
> ticket forever (knowledge DB), but it is OT here.
> 

in your example I take it you are talking about two distinct use cases 
with persistent storage (and thus binding) in between

supposing your tickets don't have explicit identity (odd? if they have 
you should conmsider case3 or 4) I assume the only thing to consider is 
sparse binding support... if you need it, you'll need case1 for sure, 
else it doesn't really matter

so yeah: your developer would not use @clear-items-on-save
but I don't think it is prove that nobody else needs it :-)

in any case I wanted to explicitely include the counterpart of what is 
now the simple-repeater

I think the similarities between case 1 and 2 are just stating that 
there is a basis for combining the code in one binding-element


> 
>>                           -o0o-
>>
>>[case 3]
>>DESCRIPTION:
>>- items have an explicit identity and can be sparsly bound
>>- form-model can add/remove/reorder the rows
>>- the sequence editing of the rows need to be reflected onto the items
>>
>>PROPOSED SYNTAX:
>><fb:repeater id="rep-id" parent-path="."
>>              row-path="item" >
>>   <!--required elements for this case -->
>>   <fb:identity>...</fb:identity>
>>   <fb:on-bind>...</fb:on-bind>
>>   <fb:on-insert>..</fb:on-insert>
>>   <fb:on-delete>..</fb:on-delete>
>></fb:repeater>
>>
>>EXPECTATION DETECTION: <fb:identity> is present
>>
>>STRATEGY on 'save':
>>- backup all items to a list OriginalItems
>>- foreach row in the repeater
>>   - if row-identity-match in OriginalItems
>>     - move item back into the context and bind
>>   - else
>>     - use on-insert and on-bind to create and bind
>>- for the items still left in the OriginalItems
>>   - use the on-delete
> 
> 
> I would define <fb:on-bind> and <fb:on-delete> as optionals. Currently I
> meet situations when there is a predefined list to be filled and I don't
> need to add or delete row at all. Example: A user fill a form while it

touche. that is indeed a case I've missed in my explicit listing

it's something like case 1 but WITH an explicit identity

in any case it should be covered by the algorithm in this case 3:
there would just be no rows/items to use on-insert/on-delete on

> fill the form the number of row of the repeater is defined. Then we use
> other form for users that evaluate the filled form. In this case we
> already know how many items are in the repeater (because the system
> automatically build the evaluation form) and we don't allow to delete or
> add new items. The evaluating user just can fill/edit the predefined
> widgets in the form. No add or delete allowed. It is tipical in goverment,
> when one people fill forms and other review the forms.
> 

and sparse binding should be supported for people that don't get to 
see/edit all properties of the item

> 
>>                           -o0o-
>>
>>[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)
>>
>>PROPOSED SYNTAX:
>>not clear yet, I tend towards:
>>
>><fb:repeater id="rep-id" parent-path="."
>>              row-path="item"
>>              row-path-insert="newItem">
>>   <!--required elements for this case -->
>>   <fb:identity>...</fb:identity>
>>   <fb:on-bind>...</fb:on-bind>
>>   <fb:on-insert>..</fb:on-insert>
>>   <fb:on-delete>..</fb:on-delete>
>></fb:repeater>
>>
>>
>>EXPECTATION DETECTION:
>>fb:identity plus
>>the presense of a @row-path-insert seems to indicate that the new ones
>>need to go into a different space then the exisiting ones, and thus
>>denying the approach expressed in case3
>>(i.e. even if it would read the same as row-path! so there would be a
>>difference between explicitely stating it as the same, and defaultly
>>assuming it is the same)
>>
>>
>>STRATEGY on 'save':
>>- foreach row in repeater
>>   - if identity match found in items
>>     - bind to that
>>     - add it to the set of updatedItems
>>   - else
>>     - add it to some list of rowsToInsert
>>- run through items
>>   - if NOT found in updatedItems
>>     - add to list of toDeleteItems (ndx will do)
>>- register the on-insert as factory
>>- foreach row in rowsToInsert
>>   - create and bind it
>>- foreach ndx in toDeleteItems in reverse order
>>   - use on-delete to remove/mark
> 
> 
> Don't know the current RepeaterBinding do that! It distribute the result
> on 3 diferent sets? It would be useful in some cases.
> 

like Joerg pointed out, this is indeed what it is doing

> 
>>                           -o0o-
>>
>>For completion:
>>implementation of the above assumes the refactoring of the current
>>identity approach towards the earlier mentioned IdentityBinding interface.
>>
>>see: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107955523607012&w=2
>>
>>(Joerg, if you're ok, I'll start doing it when this discussion (if any)
>>converges)
>>
>>
>>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
> 

I'm with Joerg here, if we change it it should be to @path to align with 
the current value and context bindings

hm, if we go for base-path here then the drive for consistency would 
force us to change @path to @base-path on all context/composed bindings

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

well, no. this @row-path today is pointing to the items (relative to the 
context narrowed by the parent-path), the counterpart on the 
repeater-side are the (implicit) rows

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

yes, a list of rows

> 
>>- on-insert is actually more of a on-create ('insert' seems to exclude
>>'append', while create is more nutral to exactly where the newly created
>>is added, it is also more in sync with the actual factory registration
>>IMHO )
> 
> 
> +1 or on-add (it is shorter) :-P
> 
> 
>>- repeater/@row-path-insert --> repeater/@new-item-path which would be
>>syncing up with the last two changes and arguments
> 
> 
> repeater/@new-add-path.... repeater/@add-path.... abort, retry, fail?....
> Please found a name for me. Here is 2:15 a.m. I need to sleep a little
> bit. :-D
> 

new-item-path reads as the path (relative to parent-path) where new 
items will be added

> Best Regards,
> 
> Antonio Gallardo
> 

hope this clarifies some
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org