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