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
