I’m don’t recall if it was intentional but iirc the advice we used to give
was to always use the OGNL expression syntax to be explicit and clear.
(Iiarc there was a reason for doing this at one point as well.) Seems like
still good advice.
It should get into the docs, though.
On Fri, Nov 24, 2023 at 09:35 Nate Kerkhofs <nate.kerkh...@ikan.be> wrote:
> 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
>
