Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3FD114F2.8020500@outerthought.org>
Date: Sat, 06 Dec 2003 00:29:54 +0100
From: Marc Portier <mpo@outerthought.org>
Organization: Outerthought
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031013 Thunderbird/0.3
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [cforms] New Repeater Binding Semantics (was Re: CocoonForms
 simple-repeater binding sample?)
References: <20031205163605.33795.qmail@web41904.mail.yahoo.com>
In-Reply-To: <20031205163605.33795.qmail@web41904.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Timothy Larson wrote:
> --- Marc Portier <mpo@outerthought.org> wrote:
> 
>>Timothy Larson wrote:
>>
>>>--- Marc Portier <mpo@outerthought.org> wrote:
>>
>>I see a need for a combination of the 'simple' strategy _and_ the use of 
>>unique identifiers:
> 
> 
> Not sure if I caught this correctly...
> are you suggesting to have these three strategies?:
> 
>   * update in place per changed item (currently in "repeater")
>   * delete and re-add per changed item (new)
>   * delete all items and re-add all item (currently in "simple-repeater")
> 

yep, think you have a point here, when there are no id's then the 3rd 
one is obviously the only valid one, be it about sparse child-elements 
or not (we can't find them back anyway, right?)


so a bit more explicit we would have

1/ @strategy="delta" where

if ORIGINAL=[ITEM(id=a,K,1), ITEM(id=b,L,2), ITEM(id=c,M,3)]

and returned after validation the WIDGET-TREE=[ITEM(id=b,10), 
ITEM(id=c,11 ), ITEM(id=*,12)]

then the save operation would need to leave the backend in this state
FINAL = [ITEM(id=a,k,1){"MARKED FOR OR DELETED"}, ITEM(id=b,L,10), 
ITEM(id=c,M,11), ITEM(id=*,as templated by on-insert-row,12)]

NOTE:
- this would have yielded the same row for any order of the rows coming 
back from the repeater:  This strategy just finds and matches the 
delta's on the children themselves, it is not considering the order of 
the rows in the repeater to be of any value


2/ @strategy="rebuild" with unique-id and path known to survive sparse-ness
(Q: do we need an additional attribute explicitely stating that the 
parse-ness is to be taken care off? or should we always try when the 
unique-id is known?)

then taking a similar case
ORIGINAL = [ITEM(id=a,K,1), ITEM(id=b,L,2), ITEM(id=c,M,3)]
WIDGET-TREE = [ITEM(id=c,11 ), ITEM(id=b,10), ITEM(id=*,12)]

this would yield
FINAL = [ ITEM(id=c,M,11), ITEM(id=b,L,10), ITEM(id=*,as templated by 
on-insert-row,12)]

NOTE:
- Items B and C got swapped!
- A got deleted: so there is (compared to the first strategy) an 
implicit <on-delete-row><delete-node/><on-delete-row>
- sparse-ness was survived


3/ @strategy="rebuild" without unique-id and path defined: no match possible

then again taking
ORIGINAL = [ITEM(id=a,K,1), ITEM(id=b,L,2), ITEM(id=c,M,3)]
WIDGET-TREE = [ITEM(id=c,11 ), ITEM(id=b,10), ITEM(id=*,12)]

we would now get
FINAL = [ ITEM(id=c,as templated by on-insert-row,11), ITEM(id=b,as 
templated by on-insert-row,10), ITEM(id=*,as templated by on-insert-row,12)]

meaning it did not preserver the unbound data

(mental note to self: recent row-path-insert needs to get a place in 
side this new multiple strategy stuff...)


> 
>>>>- confusion between simple and classic repeater binding... I understand 
>>>>that we have two strategies that both have their special uses cases, but 
>>>>I would like to have a more syntactic similarities between both to lower 
>>>>the usage confusion (and switching effort) ... in fact maybe we should 
>>>>even go for a single <wb: element-name for both and switch between both 
>>>>by using some @strategy, @flavour or @type
>>
>>in every case, since my comment here was about user-confusion:
>>I would like the fact that we make this chosing of binding strategy 
>>reflected in a very explicit attribute (rather then the more implicit 
>>changing behaviour you have now?)
> 
> 
> +1 to using a single wb: element name with @strategy.
> 
> 
>>as a consequence we should probably keep the implementation classes 
>>separate as well (although since more and more declaration stuff gets 
>>shared between both some strategy pattern might make sense)
> 
> 
> Because they share a lot of code, I don't see why we should keep the
> implementing classes separate.  Could you explain?
> 

just a concern about not cluthering too much inside one class, so we 
could put the common things in a shared base-class but still separate 
out the distinct algorithms into disctinct classes?


> <snip name discussion/>
> 
> The names are intriquing , but lets decide if we even need split
> classes if we use @strategy.
> 

yeah, I like the idea of the @strategy be _interpreted_ by the 
Binding-building process and thus yield directly classes shaped for that 
particular strategy.

I prefer it to the alternative of having the @strategy ripple up into 
being a member of the run-time Binding class, since then we would need 
to run-time check this strategy member to decide what to do (a bit odd, 
since we know that already at the time we construct the Tree of 
Bindings, and it cannot change during the lifetime of a Bidning.

> 
>>>>- in any case we should remove the XML only limitation from the simple 
>>>>repeater, since it's somewhat fighting with the principle of least 
>>>>surprise, no?
> 
> ...
> 
>>yep, Jeremy in the mentioned thead above
>>but even without it, it just makes sense to maintain this (implicit?) 
>>contract of the JXPathBinding family: it is expected to both work for 
>>XML and Beans
>>(subclasses should never lower contracts from their parents)
> 
> 
> I agree in priciple, but do not have the will right now to fix it myself.
> 

I have, no pro, I would of have earlier, but then I started to remove 
the lid and found more crawling worms :-)

Thx for joining in to the discussion, it helped straighten my thouhts out.

> <snip new explaination of @row-path-insert/>
> 
>>I'm ready to commit this, supposedly the cvs-diff will make this very clear?
> 
> 
> The new explaination and the diff make it very clear, thanks.  Looks good.
> 

yep, thx to Jan for starting to use the predicates!

> 
>>>But it cannot handle this:
>>>  <wt:repeater-widget>
>>>    <wt:widget-label id="sample-field"/>
>>>    <wt:widget id="sample-field"/>    
>>>  </wt:repeater-widget>
>>
>>wow, you make me very curious here!!!
>>are you doing what I think you are doing? mucho exciting stuff man!
> 
> 
> Yes, I am trying to allow the editing of any XML file, with the intention
> of round-tripping form definitions, templates, etc. in the CocoonForms-based
> forms and reports development GUI.
> 

then you are surely more into the stuff Sylvain was doing: strict 
binding to XML stuff...

> 
>>hm, a repeater of binding-context-nodes could do this?
>>but maybe I'm missing something?
> 
> 
> Would you explain what you mean?  Your second explainations seem to be very
> clear.  My current code gets the underlying Node and adds children to it
> directly.  If you have a way that is more generic JXPath, I'm all ears.
> 

nope, I was thinkin' about something else obviously, sorry there

But euh, the wt:repeate-widget can contain pretty much everything in the 
content model, right?

pfew, this comes close to trying to building a generic DOM-constructor 
editor, no?

so what does your form-definition and form-template for editing these 
files look like, maybe that gives me some inspiration here?


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