incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Jaquith (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JSPWIKI-351) Incorrect bundles specified in JSPs
Date Wed, 20 Aug 2008 23:40:44 GMT

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


Mime
View raw message