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]
