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]

Reply via email to