cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [cforms] Repeater Binding Revisited.
Date Tue, 30 Mar 2004 10:14:24 GMT
On 30.03.2004 09:13, Marc Portier wrote:

>> I found the (at that time) wb:repeater syntax really confusing when 
>> using it the first time. There were 5 attributes and there usage was 
>> not obvious to me: @id, @parent-path, @row-path, @unique-id, 
>> @unique-row-path. That was why I liked Antonio's move of the last two 
>> attrs into elements so much.
>>
>> What's still confusing IMO is the name parent-path - the path of which 
>> parent? For consistency this should also be named @path as for all 
>> other binding elements, the name @row-path avoids any further 
>> confusion I think.
> 
> 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?

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

>>> (Joerg, if you're ok, I'll start doing it when this discussion (if 
>>> any) converges)
>>
>> Of course, you only remove another lame excuse for starting with my 
>> diploma thesis :)
> 
> oh, joerg, sorry man, I didn't know it was that important to you ;-)

Thanks for your sympathy :)

>>> - repeater/@row-path --> repeater/@item-path since it is pointing to 
>>> items, not rows
>>
>> Indeed, so it's reasonable.
>>
> 
> 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).

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

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

Joerg

Mime
View raw message