[jira] Updated: (TRINIDAD-1231) Server and client message formatters should be consistent with each other.

["Matthias Weßendorf (JIRA)" <de...@myfaces.apache.org>]

     [ https://issues.apache.org/jira/browse/TRINIDAD-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matthias Weßendorf updated TRINIDAD-1231:
-----------------------------------------

       Resolution: Fixed
    Fix Version/s:  1.2.11-core
                    1.0.11-core
         Assignee: Matthias Weßendorf
           Status: Resolved  (was: Patch Available)

Thanks for your patch, Cale.

> Server and client message formatters should be consistent with each other.
> --------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1231
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1231
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions: 1.0.9-core, 1.2.9-core
>            Reporter: Cale Scholl
>            Assignee: Matthias Weßendorf
>            Priority: Minor
>             Fix For:  1.0.11-core,  1.2.11-core
>
>         Attachments: 1.2.10.1_formatter.patch, 1.2.9.1_formatter.patch, trunk11_formatter.patch, trunk12_formatter.patch
>
>
>  The server unescapes custom message detail strings on inital page render.
>  For example,
>   
>  _facesBean.getProperty(_NOT_IN_RANGE_MESSAGE_DETAIL_KEY)
>    -> expression.getValue(context.getELContext())
>   
>  causes the resultant string to be unescaped.
>  (i.e. "isn\'t" ==> "isn't"
>        "isn't"  ==> "isn't")
>  Then, before the javascript for the client validator (and thus the client
>  formatter) is constructed, the message detail strings are re-escaped via
>  JsonUtils.writeMap. TrFastMessageFormatUtils.format -> _formatErrorString
>  fills in the format string one token at a time using regular expressions.
>  However, when the server does the formatting, it uses
>  FastMessageFormat.format  to format the unescaped message detail strings.
>  FastMessageFormat.format interprets text enclosed in single quotes as literal
>  text, and interprets double single quotes as an escaped single quote.
>  
>  Since the real issue is that we have two formatters that format differently, I have modified the  
>  client and server formatter so that they have the same behavior. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.