Hi Nate,

Thanks for reaching out!

What I can't understand is how your app evaluates the value. Because I see the 
following in Struts UIBean.java since 2006:

        // see if the value was specified as a parameter already
        if (parameters.containsKey("value")) {
            parameters.put("nameValue" , parameters.get("value"));
        } else {

which I think means that it doesn't evaluate value if you've already set it. As 
far as I remember Struts evaluates name to calculate value if it's not already 
set.

Don't you have some specific magic in your app? Could you please see also 
Struts logs for any WARN message?

Regards,
Yasser

________________________________________
From: Nate Kerkhofs <nate.kerkh...@ikan.be>
Sent: Friday, November 24, 2023 3:23 PM
To: user@struts.apache.org
Subject: Struts 6.3 tags do not automatically evaluate the value field against 
the ognl stack

Greetings,

I am currently upgrading a Struts 2.5 project to Struts 6.3, and I ran into an 
issue with Struts 6.3 tags not evaluating the value against the ognl stack. I 
have reproduced this issue both with the radio map included in the struts2-core 
jar and with a custom radiomap.ftl, and also with an s:textfield instead of an 
s:radio. In both cases, the value attribute on the source page doesn't get 
resolved against the ognl stack, instead using the string literal entered in 
the value attribute.

I have about 140 s:radio components formatted like below, with "locked" being a 
Boolean field in the Action java controller:

<s:set var="lockedOptionMap" value="#{'true':getText('label.true'), 
'false':getText('label.false')}" />
<s:radio label="%{getText('label.projectStream.locked')}" 
list="lockedOptionMap" id="locked" name="locked" value="locked" />

In this case, none of the radios with a value set are setting their checked 
status based on the boolean value because parameters.nameValue doesn't get 
evaluated by ognl. If I remove the value attribute or make it an explicit ognl 
expression using %{}, it does resolve the attribute against the ognl stack and 
select the right item, but with the code above, the value got resolved against 
the ognl ValueStack in 2.5, but that doesn't happen in 6.3. Instead, it just 
sets nameValue to "locked" or whatever string literal "value" is set to.

I cannot find any mention of this breaking change in the migration guide, 
though I did find an issue dating back to 2007 mentioning a similar problem: 
https://issues.apache.org/jira/browse/WW-1907 which means that this either is a 
regression or it a deliberate design decision to no longer evaluate this 
property against the ognl stack.

Either way, I'd like to know whether this is an intentional change, and if so 
what the recommended way is to use a field on the ognl stack to configure the 
value of a field: should I add an explicit %{} evaluation symbol around the 
value attribute, or should I just leave out the value attribute entirely, 
instead relying solely on the name attribute set on the tag?

Kind regards,

Nate Kerkhofs

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Reply via email to