struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musachy Barroso" <>
Subject Re: S2 tags, which attributes evaled, and docs.
Date Tue, 19 Aug 2008 01:59:12 GMT
this caused me a lot of confusion when I started with S2. If I don't
remember wrong some tags "expect" an string in some attributes, and
they use findString(...) to eval the attribute (like "name" in
textfield for example). Others expect a value, so they use findValue
(like "value" in property). The StrutsTagAttribute annotation has a
type attribute, which is used to say what is the type of the expected
object, but it is missing in most attributes.


On Mon, Aug 18, 2008 at 9:48 PM, Jeromy Evans
<> wrote:
> Dave Newton wrote:
>> I'm running into a weird difference between:
>> [1] <s:textfield name="" value=""/>
>> and
>> [2] <s:textfield name="" value="%{}"/>
>> Nutshell: when there's nothing submitted for (at least if it's the
>> only element on the page) [1] will print "" as a textfield's value,
>> [2] will print nothing.
> I've observed the same behaviour and out of habit always include %{} in the
> value attribute.  It's often redundant but is a reminder that I mean the
> value of evaluating the enclosed expression rather than the literal value
> (except when i use %{''}).
> IIRC, the presence of the %{} forces evaluation down the
> TextParseUtil.translateVariables path rather than the getStack().findValue()
> path, and the latter path handles default values differently.  Not good.
>> That, in turn, led me to wonder if it'd make sense to use the existing TLD
>> annotation to include whether or not the property is evaluated, and then use
>> the same annotation to run through a tag's properties and evaluate the
>> appropriate ones. Or if that's even possible.
> Agreed it's not good that a user can't determine how an attribute is
> evaluated without inspecting the source.  An annotation that at least states
> that would be helpful, but it's possible the annotation and implementation
> are inconsistent.  As you suggest, an automated way to evaluate an attribute
> (or not) is best, rather than the seemingly arbitrary findString and
> findValue invocations in the evaluateExtraParams method.
> The tags as built must go. They suffer from the "fragile base class" problem
> in that whenever you want to make an small improvement like this you break
> them all.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

"Hey you! Would you help me to carry the stone?" Pink Floyd

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message