I agree, not trimming! Personally I don't have a problem with making the change (i.e. checking for zero length strings) in the html taglib, since an easy one line change will catch alot of them. I'm not that interested in doing it for the other taglibs though.
The way to do it would be to attach a patch to the bug and then ask for objections before committing it. Besides changing BaseHandlerTag, do you have any idea of how many other tags might need custom changes. The ones that spring to mindare the ones that take action/forward/page/href etc. as attributes to generate urls Niall ----- Original Message ----- From: "Laurie Harper" <[EMAIL PROTECTED]> Sent: Wednesday, September 14, 2005 2:13 AM > Thanks Niall, yes, that's exactly what I'm talking about (thanks for the > link). > > OK, so the issue is the impact on backwards compatibility if the tags > change such that empty values suppress attribute rendering. One > possibility would be to test for null or empty string, without trimming. > That would support the case you mentioned below where someone was > relying on rendering value=" ". It's still a behavioural change, though. > > My vote would definately be to make the change suggested in 33064, but I > can see why that might be unacceptable. Short of adding a new attribute > to all tags to switch this behaviour on, or a global config option, I > don't see any way to resolve the issue that does retain backwards > compatibility though :-( > > I suppose I should take this up on the dev list. > > L. > > Niall Pemberton wrote: > > Laurie > > > > Theres an open bugzilla ticket for the same kind of thing: > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=33064 > > > > Changing the prepareAttribute() method in o.a.s.t.h.BaseHandlerTag will deal > > with alot of the html taglib attributes that are simply output. For > > alt/altkey and title/titleKey - the message() method in BaseHandlerTag deals > > with those attributes. > > > > Having said that I added a trim() to the label for the SubmitTag a while ago > > and that caused a problem for someone who relied on the fact that it would > > emit value=" " so I'm wondering if adding a length() check is going to cause > > anyone else issues? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
