cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [CForms] Support for multipe unique-row-id in Repeater
Date Fri, 05 Mar 2004 00:40:05 GMT
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

Mime
View raw message