cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
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 :)
> 

LOL

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

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

yes.

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 
collection

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

Mime
View raw message