On 2/16/07, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
There are several tickets concerning S1 taglib, either bugs or extensions. My position is that JSTL should be used instead of Struts tags whenever possible. <html:xxx> tags are exception because they build property keypath into corresponding HTML tag's "name" attribute. Nested tags may be other tags preferred over JSTL iterate tags. Otherwise, JSTL should be preferred and tickets for S1 taglib should be closed as "Not a problem" or "Won't fix" unless they refer to <html:xxx> tags. Opinions? I would like to make this a new policy for S1 and to deny extensions/fixes for S1 taglib. If it's ok with others I will close existing tickets.
It's fine to say that you're not interested in fixing bugs in the tag libraries, and I would be fine with stating somewhere that we recommend the use of JSTL over Struts tags wherever possible (if we don't already say that somewhere). However, I am against a *policy* that states that we do not fix taglib bugs, and I am against closing existing bug reports. I'm against a policy for two reasons. One, each of us is free to scratch his or her own itches. If that includes fixing bugs in S1 tags, then that is perfectly fine. Two, if one of us was brought in to help maintain an S1 project, stumbled across a bug in one of the tags, and tried to tell management "sorry, there's a policy against fixing that", even if it turned out to be a trivial fix, I doubt we'd be happy to be in that position. I'm against closing the open bug reports because they stand as a record of known issues with the tags. That is a useful record, and there is no good reason to eliminate it. Closing the reports doesn't make the bugs go away, and those reports could well be useful to the maintainers of the thousands upon thousands of existing S1 applications out there today. -- Martin Cooper I would like to deprecate... oh, bad word, I mean, to strongly
discourage usage of S1 tags that have clear JSTL counterparts. Like with image tag, not to remove it from taglib, I never wanted to do that, but to suggest other means to achieve the same result. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
