Re: [CForms] Support for multipe unique-row-id in Repeater
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
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
Re: [CForms] Support for multipe unique-row-id in Repeater
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
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-devm=107062679414114w=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 Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [CForms] Support for multipe unique-row-id in Repeater
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
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-devm=107062679414114w=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
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
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
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-devm=107062679414114w=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 Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [CForms] Support for multipe unique-row-id in Repeater
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
Re: [CForms] Support for multipe unique-row-id in Repeater
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
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
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
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
Re: [CForms] Support for multipe unique-row-id in Repeater
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [CForms] Support for multipe unique-row-id in Repeater
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
