Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Message-ID: <1700310773.1219275644224.JavaMail.jira@brutus>
Date: Wed, 20 Aug 2008 16:40:44 -0700 (PDT)
From: "Andrew Jaquith (JIRA)" <jira@apache.org>
To: jspwiki-dev@incubator.apache.org
Subject: [jira] Commented: (JSPWIKI-351) Incorrect bundles specified in JSPs
In-Reply-To: <295912370.1219243844529.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JSPWIKI-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624188#action_12624188 ] 

Andrew Jaquith commented on JSPWIKI-351:
----------------------------------------

You've finally conceded something: "We can easily default this to a particular resourcebundle, and, should we need something more complex, we can use a @ValidateMethod"

Allrighty then. Here are the guidelines that I propose:

1. Default the @Validate messages to the same resource bundle used by the templates. This would be default*.properties. Practically speaking, this means that the current contents of StripesResources.properties (which have the default messages for @Validate validations) would be appended to default*.properties. Stripes messages and keys are VERY stable.
2. For @ValidateMethod custom validation methods, always add SimpleErrors to the ValidationProperties object. The message string passed to the SimpleError constructor should be the final text that is obtained by looking it up in CoreResources.
3. For event handler methods (i.e., they have a @HandlesEvent annotation) that generate errors, do the same as #2: look up the final string in CoreResources and pass it to the SimpleError constructor.   

This does not give me what I really want, namely tier-based rather than template-based separation (or complete unification, which would be even simpler). But it does mean we can make this work without having to subclass the @Validate annotation, create our own ValidationError implementation, or write crazy @ValidationMethod methods even for the simplest cases.

Reasonable?

> Incorrect bundles specified in JSPs
> -----------------------------------
>
>                 Key: JSPWIKI-351
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-351
>             Project: JSPWiki
>          Issue Type: Bug
>          Components: Default template
>    Affects Versions: 2.8
>         Environment: All
>            Reporter: Andrew Jaquith
>             Fix For: 2.8
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> i18n strings are improperly stored in CoreResources_*.properties, when they should have been specified in templates/default_*.properties. The comments at the top of CoreResources specifies that messages are for "JSPWiki internal code, the so-called core code." But these JSPs all look up and use message strings from CoreResources:
> * Comment.jsp
> * Install.jsp
> * LostPassword.jsp
> * NewGroup.jsp
> * Rename.jsp
> Example: 
>         // Weepy tears and hankies all 'round.
>         if( wikiSession.isAuthenticated() )
>         {
>             response.sendError( HttpServletResponse.SC_FORBIDDEN, rb.getString("login.error.noaccess") );
>             return;
>         }
> This is clearly a template/JSP-level error message, NOT an internal error. And similar kinds of code are sprinked all over the other JSPs.
> I recommend we consolidate default.properties and CoreResources.properties. The easiest way would simply be to concatenate the files. Then, in WikiContext.getBundle(), any requests for "CoreResources" could be simply diverted to default.properties.

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