struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Willis <>
Subject Re: Handling of value attribute in param and hidden tags
Date Fri, 04 Mar 2016 19:06:41 GMT
I think I understand what you're saying, a param tag doesn't correspond to any directly generated
html tag, so its 'value' attribute is special and gets evaluated. Whereas other tags, like
'hidden' correspond to html elements that actually have a 'value' attribute themselves, so
the literal value you pass in just gets set straight on the html element.

However, this page
says the following:

> Since value is not a String, whatever is passed to value is evaluated as an expression
- NOT a String literal.
> <s:textfield key="state.label" name="state" value="ca"/>
> If a textfield is passed the value attribute "ca", the framework will look for a property
named getCa.

That seems like it's describing the behavior I experience (and you describe) for the 'param'
tag where the string gets evaluated, and not what I understand you to be saying should happen
with 'textfield' and other 'input' type tags. I actually just tried with 'hidden' and 'textfield'
tags and any plain string (no %{} or ${}) inside quotes is inserted literally into the html
and not evaluated. So is the description at the URL given above incorrect? Should it only
be about the 'value' attribute on the 'param' tag? Are there other tags whose 'value' attributes
act like 'param'?

-Steven Willis

On 3/4/16, 1:08 PM, "Lukasz Lenart" <> wrote:

>I don't know the exact explanation and reasons why it behaves that
>way, but looking at the code I can say it's by design :)
><s:param/> tag doesn't play alone, you must use it in context of other
>tag so it is natural that its "value" attribute should be evaluated as
>an expression - you can read this as: evaluate expression of "value"
>attribute and assign its result to property of "name" attribute. You
>can call it a "named expression" :)
>Other tags' "value" attribute has the same meaning as value attribute
>of normal html tags (ie. <input/>) - it represent that tag's value.
>You can tell Struts to evaluate "value"'s value by defining an
>expression with %{} or ${} - it forces Struts to treat "value"'s value
>as OGNL expression - it has nothing to do with EL expressions. In that
>context you can treat <s:param/> as manifestation of %{}/${} but
>result of evaluating "value" attribute will be assigned to property
>named by "name" attribute. ${}/%{} is an anonymous though :)
>I hope you will understand, if not ask :)
>2016-03-04 18:30 GMT+01:00 Steven Willis <>:
>> I was having some issues with how freemarker/struts handles the 'value' attribute
on the 'param' tag. I figured it out and saw that struts will try to evaluate any string passed
in to 'value'. Freemarker had been evaluating my expressions, sending in the resulting string
to struts, and struts was evaluating it again.
>> After figuring that out, I assumed that other tags, like 'hidden' would behave the
same way with their 'value' attribute, but that doesn't appear to be the case. It seems like
I need to do the following for the 'param' tag:
>>     <@s.param name="foo" value="someProperty"/>
>> But with the hidden tag (or I'm assuming any form-based tag) I have to do:
>>     <@s.hidden name="foo" value=someProperty/>
>> or:
>>     <@s.hidden name="foo" value="${someProperty}"/>
>> Is this the expected behavior? And if so, why the different handling of the value
attribute between the different tags? This page:
seems to indicate that all value attributes are evaluated and even gives the example of a
textfield. But the behavior I'm seeing with hidden is that if you used value="someProperty",
you'd get the literal string value: "someProperty" in the html, not the result of evaluating
"someProperty" against the value stack.
>> Also, the table of parameters for all of the following tags:
>> Indicate that 'value' is a String field, even on the param page where the 'Description'
section indicates exactly the opposite.
>> Is there a place I could see definitively which attributes are evaluated against
the value stack and which are taken as-is? Or am I just missing/not-understanding something
(very likely)?
>> -Steven Willis
>To unsubscribe, e-mail:
>For additional commands, e-mail:
View raw message