You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ugo Cei <u....@cbim.it> on 2003/11/01 10:43:29 UTC
Re: [Woody] form2 XML binding example does not set id for new rows
Marc Portier wrote:
> nope, current binding doesn't do this.
That's clear now. From the sample, I was under the impression that the
binding would set the "id" attribute equal to the index of the row in
the repeater. My wrong.
> you can: make the id visible so the user can provide it though
I've tried to do this but it ends up with a document containing an empty
list of nodes for those bound to the repeater. I've yet to investigate
whether it's an error of mine or a bug.
In my case, actually, an ID is not needed at all. I just need to
preserve the order of the nodes. Following the sample verbatim, it would
just work, but the new nodes would have a spurious attribute that is not
needed. Can I get away without specifying an ID attibute at all?
> making sense? or overlooking some essentials?
We might support some key generation strategies, if we wanted, but I'm
not sure it's worth the effort. What we could do easily, however, is to
give the option of specifying an attribute of the bound object to be
filled with the index of the row in the collection, since it's already
there, somewhere.
> hm, maybe sylvain's event-handling additions could be used to set values
> for these?
We'll let Sylvain express himself ;-).
> -marc=
Thanks a lot,
Ugo
Re: [Woody] form2 XML binding example does not set id for new rows
Posted by Ugo Cei <u....@cbim.it>.
Marc Portier wrote:
> don't fully understand what you are saying here, but if you have
> investigated more and have more detail to present the issue I'll do a
> best effort to get into it
> (next week I'll have limited online time though, so be patient)
No, I haven't investigated it fully. I will probably investigate it
later, but since what I'm doing is a proof of concept to see whether
Woody can handle a use case involving a _very_ large (more than 100
fields) form backed by an XML document, I'm going to make it work
somehow and, if the POC proves useful, fix it later.
> Good news: I was under the impression Sylvain (aka him again ;-)) added
> a SimpleRepeaterJXPathBinding for this very reason?
Will have a look ASAP.
Thanks again,
Ugo
Re: [Woody] form2 XML binding example does not set id for new rows
Posted by Marc Portier <mp...@outerthought.org>.
Ugo Cei wrote:
> Marc Portier wrote:
>
>> nope, current binding doesn't do this.
>
>
> That's clear now. From the sample, I was under the impression that the
> binding would set the "id" attribute equal to the index of the row in
> the repeater. My wrong.
>
>> you can: make the id visible so the user can provide it though
>
>
> I've tried to do this but it ends up with a document containing an empty
> list of nodes for those bound to the repeater. I've yet to investigate
> whether it's an error of mine or a bug.
>
don't fully understand what you are saying here, but if you have
investigated more and have more detail to present the issue I'll do a
best effort to get into it
(next week I'll have limited online time though, so be patient)
> In my case, actually, an ID is not needed at all. I just need to
> preserve the order of the nodes. Following the sample verbatim, it would
> just work, but the new nodes would have a spurious attribute that is not
> needed. Can I get away without specifying an ID attibute at all?
>
aha, stupid me: I should of guessed something along these lines!
Good news: I was under the impression Sylvain (aka him again ;-)) added
a SimpleRepeaterJXPathBinding for this very reason?
Hm, I didn't find any docos on it in the wiki (hint hint) but the class
is there all-right, and the javadoc on the *Builder class describes its
use. (see
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/woody/binding/SimpleRepeaterJXPathBindingBuilder.html
)
>> making sense? or overlooking some essentials?
>
>
> We might support some key generation strategies, if we wanted, but I'm
> not sure it's worth the effort. What we could do easily, however, is to
some shared scepcis here about the 'worth the effort'...
looking at how O/R-mapping tools do this already it also feels like
duplicating the effort?
> give the option of specifying an attribute of the bound object to be
> filled with the index of the row in the collection, since it's already
> there, somewhere.
>
>> hm, maybe sylvain's event-handling additions could be used to set
>> values for these?
>
>
> We'll let Sylvain express himself ;-).
>
>> -marc=
>
>
> Thanks a lot,
>
> Ugo
>
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org