You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tim Larson <ti...@keow.org> on 2004/03/01 03:55:59 UTC
Re: [CForms binding] -TempRepeater vs. SimpleRepeater
On Sun, Feb 29, 2004 at 07:17:00AM -0600, Antonio Gallardo wrote:
> What is the diference between TempRepeaterJXPathBinding and
> SimpleRepeaterJXPathBinding?
>From memory: The TempRepeater is intended as a possible replacement
for the SimpleRepeater. It keeps the ability to handle rows that
do not have a unique id by wiping the rowset and then outputing all
of the rows at once just like the SimpleRepeater, but is different
in that it supports the wb:on-bind and wb:on-insert-row child
elements that come from the regular repeater binding.
The TempRepeater also introduces the concept of "virtual rows",
where the selected row data is wrapped in its own context to make
it easier to reference relative locations within it. This was
added to support more flexible XML binding, but may be extendable
to help with bean bindings as well.
--Tim Larson
Re: [CForms binding] - New repeater (was:Re: TempRepeater vs. SimpleRepeater)
Posted by Tim Larson <ti...@keow.org>.
On Sun, Feb 29, 2004 at 10:22:17PM -0600, Antonio Gallardo wrote:
> >> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> >> <wb:unique-row>
> >> <wb:unique-field id="myId1" path="myId1"/>
> >> <wb:unique-field id="myId2" path="myId2"/>
> >> </wb:unique-row>
> >> <wb:on-bind>
> >> <wb:value id="myId1" path="myId1"/>
> >> <wb:value id="myId2" path="myId2"/>
> >> <wb:value id="field1" path="field1"/>
> >> <wb:value id="field2" path="field2"/>
> >> </wb:on-bind>
> >> </wb:repeater>
> >>
> >> WDYT?
> >
> > Looks good. This is probably a common problem, and modifying the
> > regular wb:repeater to accept multiple unique row elements seems
> > like the right way to go.
>
> Thanks for your comment. It was helpfull. Now, I will start this new
> repeater as another repeater (Repeater2) in the "repeater family" and if
> everybody agree we will be able to switch soon to this new repeater. OK?
Consider adding this to the regular wb:repeater; if the unique*
attributes are not present then have the repeater builder look to see
if the <wb:unique-*/> elements are present. I do not think this would
upset anyone, and if we later decide we want to get rid of the unique*
attributes we can do so with minimal changes.
I hope we can eventually merge all the repeater bindings to all use
the same <wb:repeater/> element and just have the different types of
repeater binding definition objects be created based on the attributes
and elements present. Last I remember this topic was still under
discussion, however.
--Tim Larson
Re: [CForms binding] - New repeater (was:Re: TempRepeater vs.
SimpleRepeater)
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Tim:
I am glad to hear from you again. :-D
Tim Larson dijo:
> On Sun, Feb 29, 2004 at 09:35:27PM -0600, Antonio Gallardo wrote:
>> Hi Tim:
>
> Hi Antonio, nice to hear from you again.
>
>> Thanks for the description.
>
> No problem, sorry it was slow coming. My family has been sick
> and that took precedence.
I hope your family will recover soon.
>> Now I see to TempRepeater as a SimpleRpeater++. Is this correct?
>
> Yes, exactly.
>
> <snip/>
>> 1- The Best: Allow repeater to define unique-row with more than 1 field.
> <snip/>
>> Back to (1), in order to allow multiple unique-ids, we need to change
>> from
>> attributes to elements: @unique-row-id and @unique-path
>>
>> So in this way we can write:
>>
>> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
>> <wb:unique-row>
>> <wb:unique-field id="myId1" path="myId1"/>
>> <wb:unique-field id="myId2" path="myId2"/>
>> </wb:unique-row>
>> <wb:on-bind>
>> <wb:value id="myId1" path="myId1"/>
>> <wb:value id="myId2" path="myId2"/>
>> <wb:value id="field1" path="field1"/>
>> <wb:value id="field2" path="field2"/>
>> </wb:on-bind>
>> </wb:repeater>
>>
>> WDYT?
>
> Looks good. This is probably a common problem, and modifying the
> regular wb:repeater to accept multiple unique row elements seems
> like the right way to go.
Thanks for your comment. It was helpfull. Now, I will start this new
repeater as another repeater (Repeater2) in the "repeater family" and if
everybody agree we will be able to switch soon to this new repeater. OK?
Best Regards,
Antonio Gallardo.
Re: [CForms binding] - New repeater (was:Re: TempRepeater vs. SimpleRepeater)
Posted by Tim Larson <ti...@keow.org>.
On Sun, Feb 29, 2004 at 09:35:27PM -0600, Antonio Gallardo wrote:
> Hi Tim:
Hi Antonio, nice to hear from you again.
> Thanks for the description.
No problem, sorry it was slow coming. My family has been sick
and that took precedence.
> Now I see to TempRepeater as a SimpleRpeater++. Is this correct?
Yes, exactly.
<snip/>
> 1- The Best: Allow repeater to define unique-row with more than 1 field.
<snip/>
> Back to (1), in order to allow multiple unique-ids, we need to change from
> attributes to elements: @unique-row-id and @unique-path
>
> So in this way we can write:
>
> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> <wb:unique-row>
> <wb:unique-field id="myId1" path="myId1"/>
> <wb:unique-field id="myId2" path="myId2"/>
> </wb:unique-row>
> <wb:on-bind>
> <wb:value id="myId1" path="myId1"/>
> <wb:value id="myId2" path="myId2"/>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
>
> WDYT?
Looks good. This is probably a common problem, and modifying the
regular wb:repeater to accept multiple unique row elements seems
like the right way to go.
> I need to have something like this for tomorrow. If this is OK. I will
> start to work right now on this.
--Tim Larson
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Joerg Heinicke <jo...@gmx.de>.
On 12.03.2004 18:29, Marc Portier wrote:
>> You don't have access to the field and its value of the child binding by
>> default. For the repeater you now need the values, otherwise you can
>> not build the identity of a row.
>
> yep, you only have a ref to a binding (in the abstract sense) that is
> there for all of the identity fields
>
> hence my proposal: in stead of asking it for internal details it should
> just be able to reply to some isIdentical(formContext, modelContext)
> question...
>
>> But fb:identity is a composed binding that would need to collect the
>> values of its child bindings (fb:value or others, there is also no
>> access to those ATM).
>
> just like the load() and save() of this composite binding delegates to
> it's children, it would need to do so for the isIdentical()
>
> do {
> stillIdentical &&= nextChildBinding.isIdentical()
> }
> while(stillIdentical and hasmoreChildBindings)
> return stillIdentical;
>
>
> by the introduction of the 'identity' as a potential complex binding we
> have now a third mode of operation of the abstract binding interface:
> 1/ load
> 2/ save
> 3/ check for identity (or equivalence, or valuematch, or whatever name
> we find most appropriate)
>
> this change would mean that each of the bindings would need to implement
> this mode of operation in order for them to be used as an 'identity'
> inside the repeater.
>
> for most of them I think it's pretty straightforward, for those we can't
> figure out yet how it should work we could throw a runtime exception
> which would mean that this type of binding can not be used as an
> identity mapping...
>
> this in combination with the builder, checking it at runtime would be
> great...
>
> hm, this actually calls for a separate interface: IdentityBindingSupport
> that holds the isIdentical() method... that is even nicer, right? If we
> don't know how to support it, then we just don't implement the interface
>
> the builder then just waits for the identity-binding to be built and
> checks for an instanceof, downcasts, and hands over to the constructor
> of the actual repeater (or generates a building-error)
>
> making sense?
Yes, indeed. If there is nobody faster than me I will also try to get
this implemented myself. I will see if I will came across other problems.
>> Yes, I put the blame on jxpath.
>
> I'ld like to give those blokes a break, like said earlier in those cases
> I encountered I'ld have to confess (after giving it appropriate thought)
> that they just did a very logical thing... it just doesn't manifest
> itself as logical thing at first...
>
> Will the melon fall faster then the apple?
>
> (This makes me remember the toy-shop in London where they had the
> hourglas inside the tube that was waiting a bit first and then going up
> in stead of down when you turned it... all logic, but still surprising.
> Some things are just like that I'm afraid... )
:)
>>> however, thinking about it constructively I think here and now the
>>> best we can do is build some docos/catalogue offering the real
>>> XML/jxpath view on some classic bean constructs?
>>
>> Yes, though it would belong more to JXPath itself and should be
>> maintained there. Maybe it already exists.
>
> maybe, then we could just provide a link.
Ok, I will have a look for that page.
Joerg
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> Marc Portier <mpo <at> outerthought.org> writes:
>
>
>>I missed the reason to do away with the convertor, or you moved it down
>>to the identity-binding?
>
>
> The convertor was only for @unique-row-id and @unique-path and as I removed
> these I also removed that. The identity binding itself is just a composed
> binding. The value bindings do have a convertor themselves.
>
>
sure, I didn't rehash my mail after starting to see the light, ignore this
>>>2. The repeater binding has to know stuff (fieldId, xpath, convertor,
>>>etc.) from its child bindings - and this dependency is bad.
>>
>>IIRC we just duplicated that info during building in order to make sure
>>there would not be added coupling between the repeater and it's possible
>>children
>
>
and you might as well ignore this
> Maybe I understand something wrong, but I don't agree with your recall:
> The handling of @unique-row-id and @unique-path was completely in
> RepeaterJXPathBindingBuilder [1] and RepeaterJXPathBinding [2]. So the repeater
> binding did also the work of the ValueJXPathBindingBuilder and so knew all
> values for latter usage. Nothing was duplicated AFAICS.
>
IIRC, the duplication wqas in the fact that the repeater-binding had its
own memory of the unique-row-id and unique-path PLUS is had a reference
to a distinct value-binding that was initialised with the same values
but again: not relevant now that there is 'identity' for composed keys
>
>>>This is no longer true for the elements. I can
>>>get the child bindings from the composed binding, but I had to open
>>>(additional getters) the value binding to get the values no longer
>>>available to the repeater binding otherwise.
>>
>>afraid I don't understand completely yet
>
>
> You don't have access to the field and its value of the child binding by
> default. For the repeater you now need the values, otherwise you can not build
> the identity of a row.
>
yep, you only have a ref to a binding (in the abstract sense) that is
there for all of the identity fields
hence my proposal: in stead of asking it for internal details it should
just be able to reply to some isIdentical(formContext, modelContext)
question...
>
>>>All together: there is now a dependency of the repeater binding on its
>>>child bindings. We can restrict the allowed child elements of
>>>fb:identity to fb:value that reduces the problem to current minimum, but
>>>maybe something else is needed.
>>
>>oh, I'm starting to see the light again...
>>
>>damn, I have to check in the maillinglist to see if this was just a
>>personal mental note or a discussed proposal, but in any case:
>>
>>IMHO this calls for an additional method on the binding interface, next
>>to load() and save() we should be able to ask for isMatch() or even
>>better isIdentical()
>>
>>wdyt?
>
>
> But fb:identity is a composed binding that would need to collect the values of
> its child bindings (fb:value or others, there is also no access to those ATM).
>
just like the load() and save() of this composite binding delegates to
it's children, it would need to do so for the isIdentical()
do {
stillIdentical &&= nextChildBinding.isIdentical()
}
while(stillIdentical and hasmoreChildBindings)
return stillIdentical;
by the introduction of the 'identity' as a potential complex binding we
have now a third mode of operation of the abstract binding interface:
1/ load
2/ save
3/ check for identity (or equivalence, or valuematch, or whatever name
we find most appropriate)
this change would mean that each of the bindings would need to implement
this mode of operation in order for them to be used as an 'identity'
inside the repeater.
for most of them I think it's pretty straightforward, for those we can't
figure out yet how it should work we could throw a runtime exception
which would mean that this type of binding can not be used as an
identity mapping...
this in combination with the builder, checking it at runtime would be
great...
hm, this actually calls for a separate interface: IdentityBindingSupport
that holds the isIdentical() method... that is even nicer, right? If we
don't know how to support it, then we just don't implement the interface
the builder then just waits for the identity-binding to be built and
checks for an instanceof, downcasts, and hands over to the constructor
of the actual repeater (or generates a building-error)
making sense?
>
>>>>next to this observation however I'ld like to question the real-life
>>>>relevance: IMHO the advantage of jxpath under the hood of the binding
>>>>is that it allows for reusing the syntax-metafor of xpath regardless
>>>>of the backend. Being the mix of using slashes over dots, not needing
>>>>parentheses and having a single expression that equally works for
>>>>getting and setting (LHV/RHV)
>>>
>>>When it would work "regardless of the backend" ...
>>
>>yeah, but currently the regardless only realtes to the syntax being
>>portable over to the backend, not the semantics
>
>
> An important difference indeed :)
>
>
>>or in other words: the semantics are imposed onto the backend by jxpath
>>
>>what I want to say is: it DOES work, but only if the backends are equal
>>in the jxpath sense of the word
>
>
> Yes, I put the blame on jxpath.
>
I'ld like to give those blokes a break, like said earlier in those cases
I encountered I'ld have to confess (after giving it appropriate thought)
that they just did a very logical thing... it just doesn't manifest
itself as logical thing at first...
Will the melon fall faster then the apple?
(This makes me remember the toy-shop in London where they had the
hourglas inside the tube that was waiting a bit first and then going up
in stead of down when you turned it... all logic, but still surprising.
Some things are just like that I'm afraid... )
>
>>>While developing we often encoupled the backend from the frontend. The
>>>interface between both was a simple XML structure. The frontend knows
>>>what it will get, the backend what it has to deliver when the system is
>>>running. This allows independent development. Additionally we had static
>>>test XML files for the frontend, so that "real life" test is possible.
>>>The switching was just in the sitemap (XML from disk or from backend).
>>>Now I would have to maintain two binding files.
>>
>>hm, all falls with the line
>>'backend knows what it has to deliver'
>>
>>is that *knowing* really according to 'semantics as imposed by jxpath'
>>and not according to 'most naive/simplistic view of the structure'?
>
>
> It was with Cocoon 2.0 (no JXPath, no beans, no woody) and just an arbitrary
> complex XML comming either from disk (static file) or XSP (the backend), but
> this XML structure was the interface.
>
>
>>I could go on questioning if the static XML is a big gain over a static
>>hard-coded Java that builds some bean instances rather then load them
>>from the real backend...
>
>
> Indeed, new techniques sometimes need adapted developing.
>
>
>>however, thinking about it constructively I
>>think here and now the best we can do is build some docos/catalogue
>>offering the real XML/jxpath view on some classic bean constructs?
>
>
> Yes, though it would belong more to JXPath itself and should be maintained
> there. Maybe it already exists.
>
maybe, then we could just provide a link.
> Thanks for your reply,
>
no, thank YOU for your coding effort!
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Joerg Heinicke <jo...@gmx.de>.
Marc Portier <mpo <at> outerthought.org> writes:
> I missed the reason to do away with the convertor, or you moved it down
> to the identity-binding?
The convertor was only for @unique-row-id and @unique-path and as I removed
these I also removed that. The identity binding itself is just a composed
binding. The value bindings do have a convertor themselves.
> > 2. The repeater binding has to know stuff (fieldId, xpath, convertor,
> > etc.) from its child bindings - and this dependency is bad.
>
> IIRC we just duplicated that info during building in order to make sure
> there would not be added coupling between the repeater and it's possible
> children
Maybe I understand something wrong, but I don't agree with your recall:
The handling of @unique-row-id and @unique-path was completely in
RepeaterJXPathBindingBuilder [1] and RepeaterJXPathBinding [2]. So the repeater
binding did also the work of the ValueJXPathBindingBuilder and so knew all
values for latter usage. Nothing was duplicated AFAICS.
> > This is no longer true for the elements. I can
> > get the child bindings from the composed binding, but I had to open
> > (additional getters) the value binding to get the values no longer
> > available to the repeater binding otherwise.
>
> afraid I don't understand completely yet
You don't have access to the field and its value of the child binding by
default. For the repeater you now need the values, otherwise you can not build
the identity of a row.
> > All together: there is now a dependency of the repeater binding on its
> > child bindings. We can restrict the allowed child elements of
> > fb:identity to fb:value that reduces the problem to current minimum, but
> > maybe something else is needed.
>
> oh, I'm starting to see the light again...
>
> damn, I have to check in the maillinglist to see if this was just a
> personal mental note or a discussed proposal, but in any case:
>
> IMHO this calls for an additional method on the binding interface, next
> to load() and save() we should be able to ask for isMatch() or even
> better isIdentical()
>
> wdyt?
But fb:identity is a composed binding that would need to collect the values of
its child bindings (fb:value or others, there is also no access to those ATM).
> >> next to this observation however I'ld like to question the real-life
> >> relevance: IMHO the advantage of jxpath under the hood of the binding
> >> is that it allows for reusing the syntax-metafor of xpath regardless
> >> of the backend. Being the mix of using slashes over dots, not needing
> >> parentheses and having a single expression that equally works for
> >> getting and setting (LHV/RHV)
> >
> > When it would work "regardless of the backend" ...
>
> yeah, but currently the regardless only realtes to the syntax being
> portable over to the backend, not the semantics
An important difference indeed :)
> or in other words: the semantics are imposed onto the backend by jxpath
>
> what I want to say is: it DOES work, but only if the backends are equal
> in the jxpath sense of the word
Yes, I put the blame on jxpath.
> > While developing we often encoupled the backend from the frontend. The
> > interface between both was a simple XML structure. The frontend knows
> > what it will get, the backend what it has to deliver when the system is
> > running. This allows independent development. Additionally we had static
> > test XML files for the frontend, so that "real life" test is possible.
> > The switching was just in the sitemap (XML from disk or from backend).
> > Now I would have to maintain two binding files.
>
> hm, all falls with the line
> 'backend knows what it has to deliver'
>
> is that *knowing* really according to 'semantics as imposed by jxpath'
> and not according to 'most naive/simplistic view of the structure'?
It was with Cocoon 2.0 (no JXPath, no beans, no woody) and just an arbitrary
complex XML comming either from disk (static file) or XSP (the backend), but
this XML structure was the interface.
> I could go on questioning if the static XML is a big gain over a static
> hard-coded Java that builds some bean instances rather then load them
> from the real backend...
Indeed, new techniques sometimes need adapted developing.
> however, thinking about it constructively I
> think here and now the best we can do is build some docos/catalogue
> offering the real XML/jxpath view on some classic bean constructs?
Yes, though it would belong more to JXPath itself and should be maintained
there. Maybe it already exists.
Thanks for your reply,
Joerg
[1] http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/
java/org/apache/cocoon/woody/binding/RepeaterJXPathBindingBuilder.java?
annotate=1.12#114
[2] http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/woody/
java/org/apache/cocoon/woody/binding/RepeaterJXPathBinding.java?
annotate=1.20#121
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> On 11.03.2004 17:31, Marc Portier wrote:
>
>>> All together we are at:
>>>
>>> <fb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
>>> <fb:identity>
>>> <fb:value id="myId1" path="myId1"/>
>>> <fb:value id="myId2" path="myId2"/>
>>> </fb:identity>
>>> <fb:on-bind>
>>> <fb:value id="field1" path="field1"/>
>>> <fb:value id="field2" path="field2"/>
>>> </fb:on-bind>
>>> </fb:repeater>
>>>
>>
>> yep, sounds like the best we have ATM
>
>
> So, I implemented this myself. To be honest, I'm proud of this work. Not
this is utter good news
> only that I got it working, I also had the feeling I know what I'm doing
even better :-)
> :) Ok, it took a while to understand all the things in the code, but now
> it works. I tested it with the form2 binding samples.
>
> Some issues:
> 1. I removed the old attributes and convertor. I will also add this to
> the woody2cforms upgrade task. Obviously this must by solved by a
> stylesheet.
I missed the reason to do away with the convertor, or you moved it down
to the identity-binding?
> 2. The repeater binding has to know stuff (fieldId, xpath, convertor,
> etc.) from its child bindings - and this dependency is bad. With the
IIRC we just duplicated that info during building in order to make sure
there would not be added coupling between the repeater and it's possible
children
> both attributes all details where known to the repeater binding builder
> (therefore it implemented the functionality of a second builder) and so
> to the repeater binding. This is no longer true for the elements. I can
> get the child bindings from the composed binding, but I had to open
> (additional getters) the value binding to get the values no longer
> available to the repeater binding otherwise.
>
afraid I don't understand completely yet
> This issue goes on: I expect value bindings as child bindings, nothing
> else (would result in ClassCastException at the moment). I could imagine
> the use of other bindings here too: the simplest is the context binding,
> which seems to be absolutely valid, but not working, because there is no
> chance to get the values from a value binding which is a child of a
> context binding which is a child of the identity binding. The extreme
> would be a repeater binding: imagine a list of persons that have a list
> of biometrical data that constitute the identity of those persons.
>
> All together: there is now a dependency of the repeater binding on its
> child bindings. We can restrict the allowed child elements of
> fb:identity to fb:value that reduces the problem to current minimum, but
> maybe something else is needed.
>
oh, I'm starting to see the light again...
damn, I have to check in the maillinglist to see if this was just a
personal mental note or a discussed proposal, but in any case:
IMHO this calls for an additional method on the binding interface, next
to load() and save() we should be able to ask for isMatch() or even
better isIdentical()
wdyt?
>>> I read all the threads and use cases. And yes, a unification of the
>>
>>
>> pfew, you are a brave man :-)
>> I need some time to list all changes, proposals, enhancements that
>> were partially discussed but haven't got into code yet
>
>
> That would be interesting. I guess while reading I lost at least half of
> the stuff ...
>
>>> Also the unification for binding to bean or XML is a one. This ends
>>> at the latest with the repeater at the moment as the
>>> @parent-path/@row-path is different for beans and XML.
>>>
>>
>> hm, I've experienced this myself now and then, but I'm afraid this is
>> out of our league, jxpath imposes an XML way of looking at your
>> java-bean that is sometimes 'surprising':
>
>
> Yes, I know and fear this.
>
>> what most naturally looks like the standard java version of an xml
>> snippet seems (often due to technical limitations that however logic
>> need some thought to grasp) to be behaving different in the jxpath view
>>
>> next to this observation however I'ld like to question the real-life
>> relevance: IMHO the advantage of jxpath under the hood of the binding
>> is that it allows for reusing the syntax-metafor of xpath regardless
>> of the backend. Being the mix of using slashes over dots, not needing
>> parentheses and having a single expression that equally works for
>> getting and setting (LHV/RHV)
>
>
> When it would work "regardless of the backend" ...
>
yeah, but currently the regardless only realtes to the syntax being
portable over to the backend, not the semantics
or in other words: the semantics are imposed onto the backend by jxpath
what I want to say is: it DOES work, but only if the backends are equal
in the jxpath sense of the word :-)
>> I don't see it as a common use case that people during the lifetime
>> would want to switch the backend from XML to JavaBeans (or vice versa)
>> and actually expect to have all binding expressions work 'justlikethat'.
>
>
> While developing we often encoupled the backend from the frontend. The
> interface between both was a simple XML structure. The frontend knows
> what it will get, the backend what it has to deliver when the system is
> running. This allows independent development. Additionally we had static
> test XML files for the frontend, so that "real life" test is possible.
> The switching was just in the sitemap (XML from disk or from backend).
> Now I would have to maintain two binding files.
>
hm, all falls with the line
'backend knows what it has to deliver'
is that *knowing* really according to 'semantics as imposed by jxpath'
and not according to 'most naive/simplistic view of the structure'?
I could go on questioning if the static XML is a big gain over a static
hard-coded Java that builds some bean instances rather then load them
from the real backend... however, thinking about it constructively I
think here and now the best we can do is build some docos/catalogue
offering the real XML/jxpath view on some classic bean constructs?
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Joerg Heinicke <jo...@gmx.de>.
On 11.03.2004 17:31, Marc Portier wrote:
>> All together we are at:
>>
>> <fb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
>> <fb:identity>
>> <fb:value id="myId1" path="myId1"/>
>> <fb:value id="myId2" path="myId2"/>
>> </fb:identity>
>> <fb:on-bind>
>> <fb:value id="field1" path="field1"/>
>> <fb:value id="field2" path="field2"/>
>> </fb:on-bind>
>> </fb:repeater>
>>
>
> yep, sounds like the best we have ATM
So, I implemented this myself. To be honest, I'm proud of this work. Not
only that I got it working, I also had the feeling I know what I'm doing
:) Ok, it took a while to understand all the things in the code, but now
it works. I tested it with the form2 binding samples.
Some issues:
1. I removed the old attributes and convertor. I will also add this to
the woody2cforms upgrade task. Obviously this must by solved by a
stylesheet.
2. The repeater binding has to know stuff (fieldId, xpath, convertor,
etc.) from its child bindings - and this dependency is bad. With the
both attributes all details where known to the repeater binding builder
(therefore it implemented the functionality of a second builder) and so
to the repeater binding. This is no longer true for the elements. I can
get the child bindings from the composed binding, but I had to open
(additional getters) the value binding to get the values no longer
available to the repeater binding otherwise.
This issue goes on: I expect value bindings as child bindings, nothing
else (would result in ClassCastException at the moment). I could imagine
the use of other bindings here too: the simplest is the context binding,
which seems to be absolutely valid, but not working, because there is no
chance to get the values from a value binding which is a child of a
context binding which is a child of the identity binding. The extreme
would be a repeater binding: imagine a list of persons that have a list
of biometrical data that constitute the identity of those persons.
All together: there is now a dependency of the repeater binding on its
child bindings. We can restrict the allowed child elements of
fb:identity to fb:value that reduces the problem to current minimum, but
maybe something else is needed.
>> I read all the threads and use cases. And yes, a unification of the
>
> pfew, you are a brave man :-)
> I need some time to list all changes, proposals, enhancements that were
> partially discussed but haven't got into code yet
That would be interesting. I guess while reading I lost at least half of
the stuff ...
>> Also the unification for binding to bean or XML is a one. This ends at
>> the latest with the repeater at the moment as the
>> @parent-path/@row-path is different for beans and XML.
>>
>
> hm, I've experienced this myself now and then, but I'm afraid this is
> out of our league, jxpath imposes an XML way of looking at your
> java-bean that is sometimes 'surprising':
Yes, I know and fear this.
> what most naturally looks like the standard java version of an xml
> snippet seems (often due to technical limitations that however logic
> need some thought to grasp) to be behaving different in the jxpath view
>
> next to this observation however I'ld like to question the real-life
> relevance: IMHO the advantage of jxpath under the hood of the binding is
> that it allows for reusing the syntax-metafor of xpath regardless of the
> backend. Being the mix of using slashes over dots, not needing
> parentheses and having a single expression that equally works for
> getting and setting (LHV/RHV)
When it would work "regardless of the backend" ...
> I don't see it as a common use case that people during the lifetime
> would want to switch the backend from XML to JavaBeans (or vice versa)
> and actually expect to have all binding expressions work 'justlikethat'.
While developing we often encoupled the backend from the frontend. The
interface between both was a simple XML structure. The frontend knows
what it will get, the backend what it has to deliver when the system is
running. This allows independent development. Additionally we had static
test XML files for the frontend, so that "real life" test is possible.
The switching was just in the sitemap (XML from disk or from backend).
Now I would have to maintain two binding files.
Joerg
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> On 05.03.2004 17:45, Marc Portier wrote:
>
>>> Yes, I only see that wb:unique-row (grouped by type: unique or not
>>> unique) is
>>> outside of wb:on-bind (grouped by event: on-bind, on-insert,
>>> on-delete) though
>>> it is executed also at on-bind event.
>>
>>
>> yes, but do you find that surprising?
>> (in fact all of the on-bind is implicit on-insert as well)
>
>
> I see.
>
>> see my question about 'suprise' above:
>> I don't think the cost in verbosity is gained by clarity here?
>>
>> I think replacing wb:unique-row with wb:identity does a far better job
>> at adding clarity.
>
>
> All together we are at:
>
> <fb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> <fb:identity>
> <fb:value id="myId1" path="myId1"/>
> <fb:value id="myId2" path="myId2"/>
> </fb:identity>
> <fb:on-bind>
> <fb:value id="field1" path="field1"/>
> <fb:value id="field2" path="field2"/>
> </fb:on-bind>
> </fb:repeater>
>
yep, sounds like the best we have ATM
>> IMHO the behaviour of what happens on the on-bind event is more
>> related to the 'strategy' of the repeater as discussed here:
>>
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107062679414114&w=2
>>
>> my proposal would be to mix-in the @strategy and have the docos
>> introduce the clarity on what happens in 'on-bind'
>>
>> wdyt?
>
>
> I read all the threads and use cases. And yes, a unification of the
pfew, you are a brave man :-)
I need some time to list all changes, proposals, enhancements that were
partially discussed but haven't got into code yet
> different repeater bindings is desirable goal. @strategy or @type or ...
> is a good way to specify this explicitely.
yeah that is the approach that is gaining popularity in my head as well,
thx for confirming
> Also the unification for binding to bean or XML is a one. This ends at
> the latest with the repeater at the moment as the @parent-path/@row-path
> is different for beans and XML.
>
hm, I've experienced this myself now and then, but I'm afraid this is
out of our league, jxpath imposes an XML way of looking at your
java-bean that is sometimes 'surprising':
what most naturally looks like the standard java version of an xml
snippet seems (often due to technical limitations that however logic
need some thought to grasp) to be behaving different in the jxpath view
next to this observation however I'ld like to question the real-life
relevance: IMHO the advantage of jxpath under the hood of the binding is
that it allows for reusing the syntax-metafor of xpath regardless of the
backend. Being the mix of using slashes over dots, not needing
parentheses and having a single expression that equally works for
getting and setting (LHV/RHV)
I don't see it as a common use case that people during the lifetime
would want to switch the backend from XML to JavaBeans (or vice versa)
and actually expect to have all binding expressions work 'justlikethat'.
(as such I think this mismatch-experience is mainly something that will
overcome us developers, sample-makers, functional testers...)
but all IMHO, so wdot?
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.03.2004 17:45, Marc Portier wrote:
>> Yes, I only see that wb:unique-row (grouped by type: unique or not
>> unique) is
>> outside of wb:on-bind (grouped by event: on-bind, on-insert,
>> on-delete) though
>> it is executed also at on-bind event.
>
> yes, but do you find that surprising?
> (in fact all of the on-bind is implicit on-insert as well)
I see.
> see my question about 'suprise' above:
> I don't think the cost in verbosity is gained by clarity here?
>
> I think replacing wb:unique-row with wb:identity does a far better job
> at adding clarity.
All together we are at:
<fb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<fb:identity>
<fb:value id="myId1" path="myId1"/>
<fb:value id="myId2" path="myId2"/>
</fb:identity>
<fb:on-bind>
<fb:value id="field1" path="field1"/>
<fb:value id="field2" path="field2"/>
</fb:on-bind>
</fb:repeater>
> IMHO the behaviour of what happens on the on-bind event is more related
> to the 'strategy' of the repeater as discussed here:
>
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107062679414114&w=2
>
> my proposal would be to mix-in the @strategy and have the docos
> introduce the clarity on what happens in 'on-bind'
>
> wdyt?
I read all the threads and use cases. And yes, a unification of the
different repeater bindings is desirable goal. @strategy or @type or ...
is a good way to specify this explicitely.
Also the unification for binding to bean or XML is a one. This ends at
the latest with the repeater at the moment as the @parent-path/@row-path
is different for beans and XML.
Joerg
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Marc Portier <mp...@outerthought.org>.
Joerg Heinicke wrote:
> Vadim Gritsenko <vadim <at> reverycodes.com> writes:
>
>
>>>><wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
>>>> <wb:unique-row>
>>>> <wb:value id="myId1" path="myId1"/>
>>>> <wb:value id="myId2" path="myId2"/>
>>>> </wb:unique-row>
>>>> <wb:on-bind>
>>>> <wb:value id="field1" path="field1"/>
>>>> <wb:value id="field2" path="field2"/>
>>>> </wb:on-bind>
>>>></wb:repeater>
>>
>>I also tend to prefer this approach - same reasoning with ambiguity of
>>unique attribute.
>
>
> Yes, I only see that wb:unique-row (grouped by type: unique or not unique) is
> outside of wb:on-bind (grouped by event: on-bind, on-insert, on-delete) though
> it is executed also at on-bind event.
>
yes, but do you find that surprising?
(in fact all of the on-bind is implicit on-insert as well)
> Maybe a third alternative helps for that:
>
> <wb:repeater>
> <wb:on-bind>
> <wb:unique-row>
> <wb:value id="myId1" path="myId1"/>
> <wb:value id="myId2" path="myId2"/>
> </wb:unique-row>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
>
> And a fourth one is to specify values used for uniqueness independent on binding:
>
> <wb:repeater>
> <wb:unique-row>
> <!-- here *no* binding happens! -->
> <wb:element ref="myId1"/>
> <wb:element ref="myId2"/>
> </wb:unique-row>
> <wb:on-bind>
> <wb:value id="myId1" path="myId1"/>
> <wb:value id="myId2" path="myId2"/>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
>
> I used wb:element because I had no name in mind. It also must be clear if you
> refer to path (bean or XML) or to id (form model widget). From the XML this is
> very similar to Antonio's original proposal and current implementation, but
> there is the important difference that there does *not* happen any binding on
> wb:unique-row and children. Therefore it's probably clearer than the other
> proposals but more verbose.
>
> WDYT?
>
see my question about 'suprise' above:
I don't think the cost in verbosity is gained by clarity here?
I think replacing wb:unique-row with wb:identity does a far better job
at adding clarity.
IMHO the behaviour of what happens on the on-bind event is more related
to the 'strategy' of the repeater as discussed here:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107062679414114&w=2
my proposal would be to mix-in the @strategy and have the docos
introduce the clarity on what happens in 'on-bind'
wdyt?
> Joerg
>
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/mpo/
mpo@outerthought.org mpo@apache.org
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Joerg Heinicke <jo...@gmx.de>.
Vadim Gritsenko <vadim <at> reverycodes.com> writes:
> >><wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> >> <wb:unique-row>
> >> <wb:value id="myId1" path="myId1"/>
> >> <wb:value id="myId2" path="myId2"/>
> >> </wb:unique-row>
> >> <wb:on-bind>
> >> <wb:value id="field1" path="field1"/>
> >> <wb:value id="field2" path="field2"/>
> >> </wb:on-bind>
> >></wb:repeater>
>
> I also tend to prefer this approach - same reasoning with ambiguity of
> unique attribute.
Yes, I only see that wb:unique-row (grouped by type: unique or not unique) is
outside of wb:on-bind (grouped by event: on-bind, on-insert, on-delete) though
it is executed also at on-bind event.
Maybe a third alternative helps for that:
<wb:repeater>
<wb:on-bind>
<wb:unique-row>
<wb:value id="myId1" path="myId1"/>
<wb:value id="myId2" path="myId2"/>
</wb:unique-row>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
And a fourth one is to specify values used for uniqueness independent on binding:
<wb:repeater>
<wb:unique-row>
<!-- here *no* binding happens! -->
<wb:element ref="myId1"/>
<wb:element ref="myId2"/>
</wb:unique-row>
<wb:on-bind>
<wb:value id="myId1" path="myId1"/>
<wb:value id="myId2" path="myId2"/>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
I used wb:element because I had no name in mind. It also must be clear if you
refer to path (bean or XML) or to id (form model widget). From the XML this is
very similar to Antonio's original proposal and current implementation, but
there is the important difference that there does *not* happen any binding on
wb:unique-row and children. Therefore it's probably clearer than the other
proposals but more verbose.
WDYT?
Joerg
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Tim Larson wrote:
>On Fri, Mar 05, 2004 at 02:32:21AM +0100, Joerg Heinicke wrote:
>
>
>><wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
>> <wb:unique-row>
>> <wb:value id="myId1" path="myId1"/>
>> <wb:value id="myId2" path="myId2"/>
>> </wb:unique-row>
>> <wb:on-bind>
>> <wb:value id="field1" path="field1"/>
>> <wb:value id="field2" path="field2"/>
>> </wb:on-bind>
>></wb:repeater>
>>
>>
I also tend to prefer this approach - same reasoning with ambiguity of
unique attribute.
>><wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
>> <wb:on-bind>
>> <wb:value id="myId1" path="myId1" unique="true"/>
>> <wb:value id="myId2" path="myId2" unique="true"/>
>> <wb:value id="field1" path="field1"/>
>> <wb:value id="field2" path="field2"/>
>> </wb:on-bind>
>></wb:repeater>
>>
>>What do the other people think?
>>
>>
>
>I do not like this option, because it implies that the two wb:value's
>are individually unique. The first example above (with wb:unique-row)
>gives the right implication, that the values when combined identify a
>unique row. I have mixed feelings about using wb:unique-row, wb:key,
>or wb:unique-key, but I might be leaning toward wb:key.
>
>
I'm ok with <wb:key>... Oh, and I can suggest <wb:identity> - this will
not have RDBMS background :-)
Vadim
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Tim Larson <ti...@keow.org>.
On Fri, Mar 05, 2004 at 02:32:21AM +0100, Joerg Heinicke wrote:
> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> <wb:unique-row>
> <wb:value id="myId1" path="myId1"/>
> <wb:value id="myId2" path="myId2"/>
> </wb:unique-row>
> <wb:on-bind>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
>
> or
>
> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> <wb:on-bind>
> <wb:value id="myId1" path="myId1" unique="true"/>
> <wb:value id="myId2" path="myId2" unique="true"/>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
>
> What do the other people think?
I do not like this option, because it implies that the two wb:value's
are individually unique. The first example above (with wb:unique-row)
gives the right implication, that the values when combined identify a
unique row. I have mixed feelings about using wb:unique-row, wb:key,
or wb:unique-key, but I might be leaning toward wb:key.
--Tim Larson
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Joerg Heinicke <jo...@gmx.de>.
On 05.03.2004 02:10, Antonio Gallardo wrote:
> Hi Joerg:
>
> If the problem is just to change a name:
>
> from <wb:unique-field> to <wb:value>
>
> Then, no problem from my side. If you agree, I will change the code and
> this issue can be closed, right? :-D
No, please don't do another fast shot. I would like to have this
discussed by a few more people.
And it was more than just the name:
- the additional binding classes (bloated Java)
- the @direction
- wb:unique-row/wb:value vs. wb:on-bind/wb:value/@unique
So it's not just the name, but the binding to be used
(ValueJXPathBinding vs. UniqueFieldJXPathBinding). And we need agreement on
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<wb:unique-row>
<wb:value id="myId1" path="myId1"/>
<wb:value id="myId2" path="myId2"/>
</wb:unique-row>
<wb:on-bind>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
or
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<wb:on-bind>
<wb:value id="myId1" path="myId1" unique="true"/>
<wb:value id="myId2" path="myId2" unique="true"/>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
What do the other people think?
Joerg
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Joerg:
If the problem is just to change a name:
from <wb:unique-field> to <wb:value>
Then, no problem from my side. If you agree, I will change the code and
this issue can be closed, right? :-D
Best Regards,
Antonio Gallardo.
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.03.2004 05:04, Antonio Gallardo wrote:
> Joerg Heinicke dijo:
>
>>> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
>>> <wb:unique-row>
>>> <wb:unique-field id="myId1" path="myId1"/>
>>> <wb:unique-field id="myId2" path="myId2"/>
>>> </wb:unique-row>
>>> <wb:on-bind>
>>> <wb:value id="myId1" path="myId1"/>
>>> <wb:value id="myId2" path="myId2"/>
>>> <wb:value id="field1" path="field1"/>
>>> <wb:value id="field2" path="field2"/>
>>> </wb:on-bind>
>>> </wb:repeater>
>>
>>It was a good idea to replace the both attributes with a more
>>sophisticated XML structure, but it is a bad realization in my opinion.
>
>
> I posted a proposal for changes before I started to code it. Nobody answer
> (a silent aproval?), then I started the coding. Only Tim answered and give
> me his OK.
>
> The good news is it is not too hard to change the code and/or tag names. I
> agree with you: we can do it far better. But how to start if nobody cares
> about this change? On the other way I don't wanted to have this as another
> "aproved change" without implementation. Seems like coding is a good tool
> to put little pressure on other committers to review a proposal. Your
> comments are very welcomed. ;-D
This was why I ended my rant with
> Unfortunately not many Woody developers are really active on the list at the moment.
It was not a criticism to the maybe lazy people, but a real regret, that
discussions on CForms are missing at the moment.
On the other hand the proposal came in a thread without any relevance
("TempRepeater vs. SimpleRepeater"), so I for example just didn't read
it at the weekend as I still had to read things about conjoint
measurement and analysis of variances. A simple [proposal] in the
subject and a bit more time to react on it would have helped I think.
>><rant>
>>The above is redundant, irritating (unique-field is not really correctly
>>named, is it?)
>
>
> Not sure, we can change it, I don't got long time thinking in the "right"
> name. I am willing to change it for a more descriptive name. Can you give
> us a suggestion?
I will get to this topic later in the mail.
>>and (because of the more java code we need) bloated.
>
> ^^^^^^^
> (Don't understand the word).
No dictionary at hand? Bloating a balloon ... bloating our code ...
>>On
>>the one hand the redundancy above is obvious,
>
>
> The redundancy was always there (using the old attributes you will see
> it), maybe now it is more clear (evident) than before....
No, I don't see this in the samples and in my code. The binding is
already done by just @unique-row-id and @unique-path. That this binding
is completely differently specified than the other ones was the most
irritating on these attributes. Therefore I like the move to the
"sophisticated XML structure" as I called it.
>>on the other hand
>>sentences like "This unique-field element ... The id and path attributes
>>have the same meaning as in <wb:value>. ... The wd:convertor ... For
>>more info see the description of this element in <wb:value>." will get
>>me suspicious. Why the §$%& we need an additional XML element if we have
>>already one that seems to be perfect for it: wb:value as the frequent
>>references above show?
>
>
> I thought about this too. The <wb:unique-field> description don't need all
> the attributes of a <wb:value> element.
Sample for which of the attributes are not needed?
> After thinking on it, I thought it
> would be better (even from a descriptive POV) to have another tag
> describing clearly what the <wb:unique-field> is intendend for. It is a
> striped down version of <wb:value> and conceptually they are diferent.
Here I don't agree. It's exactly the same. You bind a value to a field.
But the binding does not know anything about the concept "field" - one
reason for not calling it wb:unique-field. So we would have
wb:unique-value. But this particular value is not needed to be unique,
only the aggregation of all childs of wb:unique-row. That's
wb:unique-value is also still irritating. Now we were back to wb:value.
> On the other side I don't mean to change the binding to much to allow a
> back compatibility with the old approach.
Don't get your point here. Using wb:value does not change anything in
relation to back compatibility or am I wrong?
>>Why do we have to specify @id and @path twice for
>>those identifying elements? And so on.
>
> Not necesary at all. Note, sometime you don't define (or want to define) a
> <wb:value> inside the <wb:on-binding> the key values. So it is valid too:
>
> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> <wb:unique-row>
> <wb:unique-field id="myId1" path="myId1"/>
> <wb:unique-field id="myId2" path="myId2"/>
> </wb:unique-row>
> <wb:on-bind>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
I hope I don't miss anything important. This does look much better of
course, but for which cases would you add it to wb:on-bind and for which
cases not?
>>And the latter we do this the more we
>>will break. Unfortunately not many Woody developers are really active on
>>the list at the moment.
>
>
> Because of short of time I don't posted this change to the user list. It
> is my fault. Now, I am not sure if I can post on the user list about the
> change since this mail looks like a total non-approval of the proposal.
> Then why to ring a bell to the users? We can easily undo all the changes
> and nothing will happens, then from a POV of users: it never happen at
> all. :-)
No, we will bring this to good end and announce it afterwards. As I said
using the elements wb:unique-row & Co. I like much more than the both
attributes.
>>Another thing that I don't like is the new restriction:
>>"Note: This binding is only active in the 'load' operation, so
>>specifying the direction="save" is meaningless."
>
> This is another thing that was there all the time, even before the
> changes. I just replicated the same approach at it was before. The change
> is just related to have multivalue "unique fields" instead of just one
> (old style). Nothing more nor nothing less.
No, that's not true. I lost my IDs in my own code when not specifying
direction="load" at the repeater element.
>>Sorry, Antonio, but you seem to be often the targets of my rants ...
>
>
> No problem at all. This help us to improve Cocoon. I am glad this happen,
> keep on it. ;-)
>
> The worse to me, will be when nobody will care on the work I do.
Good that you think so :)
> 2-Another initial proposal was:
>
> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> <wb:on-bind>
> <wb:value id="myId1" path="myId1" unique="true"/>
> <wb:value id="myId2" path="myId2" unique="true"/>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
>
> NOTE: see the new @unique on <wb:value>.
>
> PRO:
>
> It is shorter to write.
>
> CON: More dificult to parse, some problems can rise. Need to be used with
> @direction to state when we need it just as a readonly attribute. This can
> overcomplicate things.
"Difficult to parse" for the user? Yes, it's not that obvious like the
other one. But it would show that it does exactly the same. Indeed I
like this even a bit more than wb:unique-row.
For the @direction problem I already said I'm nearly sure that it must
be set explicitely to "load" at the moment too. I also don't want to
restrict this to much. Maybe someone really want's to change this key.
See the samples, there is uniqueness of the names (firstname + lastname)
tested. Uncouple it completely from any database stuff and you see that
it makes sense to allow also to save the changed value. The rest is up
to the application developer.
To summarize my thoughts:
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<wb:unique-row>
<wb:value id="myId1" path="myId1"/>
<wb:value id="myId2" path="myId2"/>
</wb:unique-row>
<wb:on-bind>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
or
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<wb:on-bind>
<wb:value id="myId1" path="myId1" unique="true"/>
<wb:value id="myId2" path="myId2" unique="true"/>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
both the explicite need for specifying @direction="load" if necessary!
Joerg
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Antonio Gallardo <ag...@agssa.net>.
Joerg Heinicke dijo:
>> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
>> <wb:unique-row>
>> <wb:unique-field id="myId1" path="myId1"/>
>> <wb:unique-field id="myId2" path="myId2"/>
>> </wb:unique-row>
>> <wb:on-bind>
>> <wb:value id="myId1" path="myId1"/>
>> <wb:value id="myId2" path="myId2"/>
>> <wb:value id="field1" path="field1"/>
>> <wb:value id="field2" path="field2"/>
>> </wb:on-bind>
>> </wb:repeater>
>
> It was a good idea to replace the both attributes with a more
> sophisticated XML structure, but it is a bad realization in my opinion.
I posted a proposal for changes before I started to code it. Nobody answer
(a silent aproval?), then I started the coding. Only Tim answered and give
me his OK.
The good news is it is not too hard to change the code and/or tag names. I
agree with you: we can do it far better. But how to start if nobody cares
about this change? On the other way I don't wanted to have this as another
"aproved change" without implementation. Seems like coding is a good tool
to put little pressure on other committers to review a proposal. Your
comments are very welcomed. ;-D
> <rant>
> The above is redundant, irritating (unique-field is not really correctly
> named, is it?)
Not sure, we can change it, I don't got long time thinking in the "right"
name. I am willing to change it for a more descriptive name. Can you give
us a suggestion?
> and (because of the more java code we need) bloated.
^^^^^^^
(Don't understand the word).
> On
> the one hand the redundancy above is obvious,
The redundancy was always there (using the old attributes you will see
it), maybe now it is more clear (evident) than before....
> on the other hand
> sentences like "This unique-field element ... The id and path attributes
> have the same meaning as in <wb:value>. ... The wd:convertor ... For
> more info see the description of this element in <wb:value>." will get
> me suspicious. Why the §$%& we need an additional XML element if we have
> already one that seems to be perfect for it: wb:value as the frequent
> references above show?
I thought about this too. The <wb:unique-field> description don't need all
the attributes of a <wb:value> element. After thinking on it, I thought it
would be better (even from a descriptive POV) to have another tag
describing clearly what the <wb:unique-field> is intendend for. It is a
striped down version of <wb:value> and conceptually they are diferent.
On the other side I don't mean to change the binding to much to allow a
back compatibility with the old approach.
> Why do we have to specify @id and @path twice for
> those identifying elements? And so on.
Not necesary at all. Note, sometime you don't define (or want to define) a
<wb:value> inside the <wb:on-binding> the key values. So it is valid too:
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<wb:unique-row>
<wb:unique-field id="myId1" path="myId1"/>
<wb:unique-field id="myId2" path="myId2"/>
</wb:unique-row>
<wb:on-bind>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
> Such changes should be well
> thought out, otherwise we have to change to much later on when
> sophisticating our XML elements.
They are, it cannot interefere with a more complex XML elements. Less is
sometimes better than nothing. It is just a first step. If this first step
was not taken we will not being discussing this issue at all. ;-)
> And the latter we do this the more we
> will break. Unfortunately not many Woody developers are really active on
> the list at the moment.
Because of short of time I don't posted this change to the user list. It
is my fault. Now, I am not sure if I can post on the user list about the
change since this mail looks like a total non-approval of the proposal.
Then why to ring a bell to the users? We can easily undo all the changes
and nothing will happens, then from a POV of users: it never happen at
all. :-)
> </rant>
>
> Another thing that I don't like is the new restriction:
> "Note: This binding is only active in the 'load' operation, so
> specifying the direction="save" is meaningless."
This is another thing that was there all the time, even before the
changes. I just replicated the same approach at it was before. The change
is just related to have multivalue "unique fields" instead of just one
(old style). Nothing more nor nothing less.
> Sorry, Antonio, but you seem to be often the targets of my rants ...
No problem at all. This help us to improve Cocoon. I am glad this happen,
keep on it. ;-)
The worse to me, will be when nobody will care on the work I do.
>> NOTE: The "old style" is also supported. You don't need to rewrite your
>> code. But I think we can also deprecate the old way (using attributes).
>
> I would not let live these deprecated attributes that long. Just like we
> did it for @readonly => @direction I would remove it as fast as possible
> and therefore do a big ANNOUNCEMENT on the users list.
OK. But I need an approval before make an ANNOUNCEMENT to the user list.
Let discuss it. I am sure we can improve the current solution.
> BTW, the wd:convertor element can also be deprecated and removed as it
> is used in combination with the unique-row-id.
Yep. I forgot to write about this. I already review the changes you do on
wiki. Thanks for you time to do this.
Some comments about other ways we droped while designing:
1-An initial name we tought was:
<wb:unique-field> --> <wb:key>
But this was for us much DB oriented and we are talking about forms here.
Carlos also pointed aout that a "primary key" in fact is just one. That
the "primary key" can be composed from more than one field, is another
story. Then we droped the <wb:key> name in favor of the current ONE that
looks more descriptive.
2-Another initial proposal was:
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<wb:on-bind>
<wb:value id="myId1" path="myId1" unique="true"/>
<wb:value id="myId2" path="myId2" unique="true"/>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
NOTE: see the new @unique on <wb:value>.
PRO:
It is shorter to write.
CON: More dificult to parse, some problems can rise. Need to be used with
@direction to state when we need it just as a readonly attribute. This can
overcomplicate things.
If you review the old and the new RepeaterJXPathBinging code, you will
note there is an issue:
"What happen when we change a <wb:unique-row-id> or a <wb:unique-field>?"
In fact given the current (and old) implementation, a change of the value
in this is done in this way:
"Remove the old one, then create a new one".
Why care about this? Because many DB implementation allow us to update the
Primary Key - PK (read <wb:unique-row-id> or <wb:unique-field>) without
removing the register at all, also we can define FOREIGN KEYS as "auto
updatables" (in case the PK on the other table change).
While review the code, I wondered (when discovered it) how good OJB can
manage it. But seems like other guys on the user list (not using OJB) are
having problems with this issue. Desafortunatelly, I cannot tell how to
fix this since I am not sure if this is work for CForms at all.
Last week, I spent the time learning this code. Don't wonder why I can
talk too much about it ;-)
Best Regards,
Antonio Gallardo.
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2004-03-03 at 22:24, Joerg Heinicke wrote:
> > <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> > <wb:unique-row>
> > <wb:unique-field id="myId1" path="myId1"/>
> > <wb:unique-field id="myId2" path="myId2"/>
> > </wb:unique-row>
> > <wb:on-bind>
> > <wb:value id="myId1" path="myId1"/>
> > <wb:value id="myId2" path="myId2"/>
> > <wb:value id="field1" path="field1"/>
> > <wb:value id="field2" path="field2"/>
> > </wb:on-bind>
> > </wb:repeater>
>
> It was a good idea to replace the both attributes with a more
> sophisticated XML structure, but it is a bad realization in my opinion.
>
> <rant>
> The above is redundant, irritating (unique-field is not really correctly
> named, is it?) and (because of the more java code we need) bloated. On
> the one hand the redundancy above is obvious, on the other hand
> sentences like "This unique-field element ... The id and path attributes
> have the same meaning as in <wb:value>. ... The wd:convertor ... For
> more info see the description of this element in <wb:value>." will get
> me suspicious. Why the §$%& we need an additional XML element if we have
> already one that seems to be perfect for it: wb:value as the frequent
> references above show? Why do we have to specify @id and @path twice for
> those identifying elements? And so on. Such changes should be well
> thought out, otherwise we have to change to much later on when
> sophisticating our XML elements. And the latter we do this the more we
> will break. Unfortunately not many Woody developers are really active on
> the list at the moment.
> </rant>
I don't have the time and energy currently to follow all these
developments, but thanks for keeping a critical eye on it.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [CForms] Support for multipe unique-row-id in Repeater
Posted by Joerg Heinicke <jo...@gmx.de>.
> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> <wb:unique-row>
> <wb:unique-field id="myId1" path="myId1"/>
> <wb:unique-field id="myId2" path="myId2"/>
> </wb:unique-row>
> <wb:on-bind>
> <wb:value id="myId1" path="myId1"/>
> <wb:value id="myId2" path="myId2"/>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
It was a good idea to replace the both attributes with a more
sophisticated XML structure, but it is a bad realization in my opinion.
<rant>
The above is redundant, irritating (unique-field is not really correctly
named, is it?) and (because of the more java code we need) bloated. On
the one hand the redundancy above is obvious, on the other hand
sentences like "This unique-field element ... The id and path attributes
have the same meaning as in <wb:value>. ... The wd:convertor ... For
more info see the description of this element in <wb:value>." will get
me suspicious. Why the §$%& we need an additional XML element if we have
already one that seems to be perfect for it: wb:value as the frequent
references above show? Why do we have to specify @id and @path twice for
those identifying elements? And so on. Such changes should be well
thought out, otherwise we have to change to much later on when
sophisticating our XML elements. And the latter we do this the more we
will break. Unfortunately not many Woody developers are really active on
the list at the moment.
</rant>
Another thing that I don't like is the new restriction:
"Note: This binding is only active in the 'load' operation, so
specifying the direction="save" is meaningless."
Sorry, Antonio, but you seem to be often the targets of my rants ...
> NOTE: The "old style" is also supported. You don't need to rewrite your
> code. But I think we can also deprecate the old way (using attributes).
I would not let live these deprecated attributes that long. Just like we
did it for @readonly => @direction I would remove it as fast as possible
and therefore do a big ANNOUNCEMENT on the users list.
BTW, the wd:convertor element can also be deprecated and removed as it
is used in combination with the unique-row-id.
Joerg
[CForms] Support for multipe unique-row-id in Repeater
Posted by Antonio Gallardo <ag...@agssa.net>.
OK.
It is done! Now we can write:
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<wb:unique-row>
<wb:unique-field id="myId1" path="myId1"/>
<wb:unique-field id="myId2" path="myId2"/>
</wb:unique-row>
<wb:on-bind>
<wb:value id="myId1" path="myId1"/>
<wb:value id="myId2" path="myId2"/>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
NOTE: The "old style" is also supported. You don't need to rewrite your
code. But I think we can also deprecate the old way (using attributes).
For more info see the initial mails below....
Best Regards,
Antonio Gallardo
Antonio Gallardo dijo:
> Hi Tim:
>
> Thanks for the description. Now I see to TempRepeater as a
> SimpleRpeater++. Is this correct?
>
> I am looking for a similar repeater some days ago. The problem is:
>
> I have a table with a Primary Key with more than one field. The current
> repeaters does not allow me to define a unique-id with more that one
> field. And in my case:
>
> rowNumber id1 id2
> 1 1 1
> 2 1 2
> 3 2 1
> 4 2 2
> ....
>
> In this way I cannot choose any of the ids to be unique. The result is
> nothing is updated.
>
> I wonder if I am the only one facing this problems with CForms. I think
> other people will need this enhancement. After thinking in how to solve
> this I come to 2 posible solutions:
>
> 1- The Best: Allow repeater to define unique-row with more than 1 field.
>
> 2- Based in an special requirement: I have a fixed length of rows in the
> repeater to display and the user cannot change the number of rows. The
> user just fill data. I can call it a FixedLengthRepeater. Of course I can
> do this based on the current Simple or Temp Repeater. But I don't like the
> idea of this special purpose repeater.
>
> Back to (1), in order to allow multiple unique-ids, we need to change from
> attributes to elements: @unique-row-id and @unique-path
>
> So in this way we can write:
>
> <wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
> <wb:unique-row>
> <wb:unique-field id="myId1" path="myId1"/>
> <wb:unique-field id="myId2" path="myId2"/>
> </wb:unique-row>
> <wb:on-bind>
> <wb:value id="myId1" path="myId1"/>
> <wb:value id="myId2" path="myId2"/>
> <wb:value id="field1" path="field1"/>
> <wb:value id="field2" path="field2"/>
> </wb:on-bind>
> </wb:repeater>
>
> WDYT?
>
> I need to have something like this for tomorrow. If this is OK. I will
> start to work right now on this.
>
> Best Regards,
>
> Antonio Gallardo
>
[CForms binding] - New repeater (was:Re: TempRepeater vs.
SimpleRepeater)
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Tim:
Thanks for the description. Now I see to TempRepeater as a
SimpleRpeater++. Is this correct?
I am looking for a similar repeater some days ago. The problem is:
I have a table with a Primary Key with more than one field. The current
repeaters does not allow me to define a unique-id with more that one
field. And in my case:
rowNumber id1 id2
1 1 1
2 1 2
3 2 1
4 2 2
....
In this way I cannot choose any of the ids to be unique. The result is
nothing is updated.
I wonder if I am the only one facing this problems with CForms. I think
other people will need this enhancement. After thinking in how to solve
this I come to 2 posible solutions:
1- The Best: Allow repeater to define unique-row with more than 1 field.
2- Based in an special requirement: I have a fixed length of rows in the
repeater to display and the user cannot change the number of rows. The
user just fill data. I can call it a FixedLengthRepeater. Of course I can
do this based on the current Simple or Temp Repeater. But I don't like the
idea of this special purpose repeater.
Back to (1), in order to allow multiple unique-ids, we need to change from
attributes to elements: @unique-row-id and @unique-path
So in this way we can write:
<wb:repeater id="myRepeaterId" parent-path="." row-path="TheRowPath">
<wb:unique-row>
<wb:unique-field id="myId1" path="myId1"/>
<wb:unique-field id="myId2" path="myId2"/>
</wb:unique-row>
<wb:on-bind>
<wb:value id="myId1" path="myId1"/>
<wb:value id="myId2" path="myId2"/>
<wb:value id="field1" path="field1"/>
<wb:value id="field2" path="field2"/>
</wb:on-bind>
</wb:repeater>
WDYT?
I need to have something like this for tomorrow. If this is OK. I will
start to work right now on this.
Best Regards,
Antonio Gallardo