[ 
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.

Reply via email to