[
https://issues.apache.org/struts/browse/WW-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45303#action_45303
]
Pierre Thibaudeau commented on WW-2732:
---------------------------------------
Not quite, Kevin
If I use <s:text name="title"/>, it's because I should have a resource whose
keyname is "title" and whose value is something like "The Grant Title of This
Magnum Opus". Now, we all know that it's easy to overlook resources
(especially in development).
In Struts1, in the case of such omission, an error message is displayed in the
output of the JSP. That's a very reasonable option. Though rather annoying,
as it prevents from checking other details on the page.
In Struts2, the documentation states that:
>> If the named message is not found, then the body of the tag will be used as
>> default message. If no body is used, then the name of the message will be
>> used.<<
That seems to me like an even better proposition than with Struts1 (the
"reasonable default" aimed at by S2)! In my case, seeing "title" output is
almost as good as seeing what I had intended, namely "The Grand Title of This
Magnum Opus". Certainly it allows me to examine how the page looks like,
despite my having forgotten one resource.
In practice, while developping, I omit not one but 100 resources. But with S2
trying to evaluate lots and lots and lots of expression which were *clearly*
never intended to be evaluated, my development logs are becoming increasingly
impossible to read (because of all the OGNL-evaluation errors), lest I switch
most logging off (which is equally useless).
Now it seems reasonable to me that the "test" parameter of the <s:if/> tag
should be evaluated by default. (Even though it wouldn't bother me to have to
write %{1 == 1} each time.) But it seems to me to run against the natural
S2-grain (of "reasonable default") to assume that the keyname of a resource is
an expression in need of evaluation. I think instead that, for the very
unusual cases when we DO need to evaluate an expression denoting the keyname of
a resource, we should then rely on the explicit %{expression}-notation.
That is to say, for example, if "title" is the name of a property on the action
with value "The Great Gatsby" and if I forgot to include a "title" resource,
then the following two expressions should respectively yield:
<s:text name="title"/> ==> title
<s:text name="%{title}"/> ==> The Great Gatsby
If that's unreasonable, why not simply going back to S1's convention of
throwing an error message?
> <s:text name="key"/> OGNL-evaluates "key" when it is not found in resource
> bundle
> ---------------------------------------------------------------------------------
>
> Key: WW-2732
> URL: https://issues.apache.org/struts/browse/WW-2732
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tags, Value Stack
> Affects Versions: 2.1.2
> Environment: Tested with 2.1.2, but the issue could have existed
> earlier.
> Reporter: Pierre Thibaudeau
> Priority: Minor
> Fix For: 2.1.3
>
>
> <s:text name="key"/> outputs the resource message designated by "key".
> If no such message exists (and the body of the tag is empty), it reverts to
> outputting the name of the key itself, as an unevaluated string. At least,
> that's the behaviour of the tag, as described in the documentation.
> In fact, however, the name of the key is now being evaluated as an OGNL
> expression, and if that turns out to be valid, that is what's printed.
> This, in my view, is counter-intuitive and probably counter-productive.
> Consider the case of a ModelDriven<Book> action exposing a Book-object to the
> View.
> Normally,
> <s:text name="title"/>: ${title}
> would have yielded:
> title: The Great Gatsby
> if the resource message "title" was missing from the resource bundle. That's
> not too bad an outcome. However, with the key being OGNL-evaluated, we would
> get the following output:
> The Great Gatsby: The Great Gatsby
> which I find a little puzzling...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
