cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: [cforms] Repeater Binding Revisited.
Date Tue, 30 Mar 2004 17:10:03 GMT

Joerg Heinicke wrote:
> On 30.03.2004 09:13, Marc Portier wrote:

<snip />

>> thx for chiming in with my name change proposal upfront :-)
> Yeah, for such long mails I do pipelining like Cocoon: before having 
> finished the parsing I already transform the first text events :)


>>> Maybe it's just to late for thinking, but what's the difference 
>>> between 1 (especially with "straightforward extension") and 2?
>> none!
>> In fact I hope to be wrapping all these up in one imlementation 
>> algorithm:
> Yes, I thought that this was your intention of starting the thread. But 
> when adding explicitely case 1 and case 2 there must be a difference, 
> must it not?

sure, there is an obvious on in usage perspective, so I was planning to 
have docos and samples approach things from this angle

each of these cases has a direct relation to what one normally would 
expect the form to look like (allowing add/delete/reorder ....)

however towards implementation there mainly just input that I hope to 

>>>> [case 3]
>>>> - 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
>>>> 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
>> in fact, this approach makes a question pop up to the hibernate and 
>> ojb experts out there:
>> will this moving to buffer collection just work or am I to consider 
>> some constraints while doing so?
> Not that I know. At least for OJB and its object level transactions 
> implementation OTM the collections are just collections and important 
> are the object identities - which is at the end the same as for cforms 
> binding.

good news.

<snip />

>> but it kinda requires me adding the above to the docos
>> which makes me think: I'm planning on only patching cforms (not woody) 
>> for this... we still don't have cforms docs in the wiki, right?
> Yes. Upayavira will add a s/woody/cocoon forms/g (don't know exact 
> syntax ;-), and it's probably a bit more clever) replacement to the 
> transformation script (JSPWiki => Moin Moin).

aha, well in that case it's ok if I already write up a CFOrms specific 
page and wait for the rest to be moved over

>>>> - repeater/@row-path-insert --> repeater/@new-item-path which would 
>>>> be syncing up with the last two changes and arguments
>>> What do we need @row-path-insert/@new-item-path for if we have 
>>> on-insert?
>> well, that is part of the confusion of on-insert
>> on-insert isn't really used to insert stuff, it just registers a 
>> factory to create nodes when that would be needed
>> this means that it doesn't make sense to add path information on that 
>> element, since it will not actively use that. (it is the repeater 
>> deciding and doing that)
> I only wondered about when @row-path-insert is in use. Won't just the 
> mentioned factory method be called?


the way iot works is that the repeater
1. registers the factory method and
2. then for each to be created item:
   2a. concatenates its jxpath locator
   2b. use it to set the new values

as a consequence the jxpath machinery will see that there are elements 
missing and call upon the factory to have them created

>> in any case, we added the new-item-path already some time ago (called 
>> row-path-insert) for those use cases were the new rows in a repeater 
>> needed to be added into a separate section
> Yes, I remember when Vadim complains about the restriction of using 
> predicates in @row-path while just the comment in the samples file was 
> confusing. Is @row-path-insert only for XML binding?

the predicate hastle comes from the concatenation and the fact that 
jxpath just can't handle the double uncertainty of where it should now 
create the new element AFAIU

by now I hope it is clear that this also works for Bean Binding, it's 
just less common I guess to be storing the new items in a separate 

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message