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.
musachy
On Mon, Aug 18, 2008 at 9:48 PM, Jeromy Evans
<[EMAIL PROTECTED]> wrote:
> Dave Newton wrote:
>>
>> I'm running into a weird difference between:
>>
>> [1] <s:textfield name="foo.bar" value="foo.bar"/>
>>
>> and
>>
>> [2] <s:textfield name="foo.bar" value="%{foo.bar}"/>
>>
>> Nutshell: when there's nothing submitted for foo.bar (at least if it's the
>> only element on the page) [1] will print "foo.bar" 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 %{'foo.bar'}).
>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
