On 11/19/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
<snip>
Hmm. Personally, I think 'styleId' is a poor name in the first place, so I'm
not all that enamored of perpetuating it. (It seemed like a decent choice at
the time, but that was many years ago, and if we were to be choosing the
name today, I'd have suggested 'domId' instead. But that's all water under
the bridge. ;)
How about we just stick with 'for'? We have generally tried to use the same
name for an attribute as for what will be rendered, and there's no reason we
can't use 'for' (unlike 'id' which we could not use, which is why 'styleId'
exists).
An aside: How did we end up with the 'errorStyleId' thing? I must have been
asleep when that happened. Why on earth would I want to give an element a
different DOM identifier if there's an error in the field's value? That
would certainly complicate any JavaScript code I have that references that
element. A different style, yes, but a different id?
</snip>
[1][2] Mea culpa :-( Its not that long ago when "no script" was a
common refrain and the very naming of "styleId" indicates that these
attributes were seen in purely CSS terms. That now looks dated but for
anyone who was using "id" just to apply style, then having an error
equivalent seemed consistent in terms of the three "style" attributes
that Struts tags supported. As you said earlier though, in hindsight
styleId could have been better named (domId) in the current rich
client experience environment.
Niall
[1] https://issues.apache.org/struts/browse/STR-1525
[2] http://svn.apache.org/viewvc?view=rev&revision=51839
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
