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?
Niall
----- Original Message -----
From: "Laurie Harper" <[EMAIL PROTECTED]>
Sent: Tuesday, September 13, 2005 4:30 AM
The main reason not to do it that way is the number of attributes
involved and the combinatoric explosion involved in handling things that
way -- especially since most of them are optional.
It's not just attributes that have a 'foo' and a 'fooKey' that are the
issue. Writing foo="${foo}" is not equivalent to leaving the 'foo'
attribute unspecified even when the tag file is itself invoked with no
'foo' attribute :-(
L.
Kishore Senji wrote:
I don't know how much of work it would be to modify those tags, however,
just wondering why you wouldn't want to have such logic outside the
actual
struts tag.
You could have logic in the tag file which, If both "alt" and "altKey"
or
just "alt" is given, uses "alt" value and if just "altKey" is given then
fetches the value from the message resources using <bean:message/> and
uses
that.
<html:text property="${property}" alt="${resolvedAltValue} .../>
On 9/10/05, Laurie Harper <[EMAIL PROTECTED]> wrote:
This isn't really Struts specific, but I'm trying to wrap some of the
Struts HTML tags with tag files (in order to compose them into more
complex 'controls') and I'm running into a slight problem... Some
attributes are mutually exclusive (e.g. 'alt' vs. 'altKey'). I can't see
a way to pass attributes through from the tag file to the Struts tag
that works with this constraint. For example, if I write a tag file like
this:
<[EMAIL PROTECTED] name="property" required="true" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="alt" required="false" rtexprvalue="true"%>
<[EMAIL PROTECTED] name="altKey" required="false" rtexprvalue="true"%>
...
<html:text property="${property}" alt="${alt} altKey="${altKey}" .../>
then, regardless of whether I set alt and/or altKey in the call to the
tag file, the html:text tag complains that I can't specify both
attributes. I've tried passing in the values using "${empty alt ? null :
alt}" but get the same result.
Does anyone know a way to work around this (i.e. a 'correct' way to
pass-through attributes from tag files to custom tags)?
Failing that, how big a deal would it be to change the Struts tags to
treat the empty string equivalently to 'null' when performing these
checks? [I'll happy put together a patch to do that]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
