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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
