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
