On 11/20/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
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.
Thanks for the links. I did completely miss that at the time. ;-( My question, though, is not answered in the discussion in the JIRA issue. I understand why you'd want different style classes, but why would you want to change the id itself? The discussion mentions the errorStyleId attribute, but doesn't explain why I would want it. Yes, I can associate a CSS class with a specific id, but changing that id to pick up a different style for errors seems quite peculiar, especially when I could simply change the class instead. -- Martin Cooper 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]