You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Pierre Thibaudeau (JIRA)" <ji...@apache.org> on 2008/12/16 17:01:37 UTC

[jira] Issue Comment Edited: (WW-2732) OGNL-evaluates "key" when it is not found in resource bundle

    [ https://issues.apache.org/struts/browse/WW-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45275#action_45275 ] 

pierdeux edited comment on WW-2732 at 12/16/08 8:00 AM:
-----------------------------------------------------------------

Apologies if I am being stupid here, but I think I don't grasp Musachy's comment.  In my earlier example, I specifically did NOT want to output a property value when using the <s:text> tag.  Therefore I specifically (under no circumstance) want <s:text name="title"/> to mean the same thing as <s:property value="title"/>.  (I am not mistaking one tag for the other, whereas the actual implementation seems to...)

(In my "Great Gatsby" example above, please don't get sidetracked by the "${title}":  that was not part of the issue at all.  You can rewrite my example, swapping ${title} for <s:property value="title"/> without changing the point I intended to make.)

The reason to worry about such details is not purely one of clarifying muddied categories.  It's also one of efficiency.  OGNL is noticeably slow, and I am certain that calling for OGNL-evaluation when it's unwanted is most undesirable...

      was (Author: pierdeux):
    Apologies if I am being stupid here, but I don't understand the relevance of Musachy's comment.  In my earlier example, I specifically did NOT want to output a property value when using the <s:text> tag.  Therefore I specifically (under no circumstance) want <s:text name="title"/> to mean the same thing as <s:property value="title"/>.  (I am not mistaking one tag for the other, whereas the actual implementation seems to...)

(In my "Great Gatsby" example above, please don't get sidetracked by the "${title}":  that was not part of the issue at all.  You can rewrite my example, swapping ${title} for <s:property value="title"/> without changing the point I intended to make.)

The reason to worry about such details is not purely one of clarifying muddied categories.  It's also one of efficiency.  OGNL is noticeably slow, and I am certain that calling for OGNL-evaluation when it's unwanted is most undesirable...
  
> <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: Future
>
>
> <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.