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 21:38:44 GMT

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

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

Janne --

I think the separation you are making is splitting things a little too finely. I agree that
"developers" (in all senses of the word) should be able to customize templates, and the messages
that go with them. But I am arguing here that unifying all of the presentation-tier messages
in a single set of properties (while leaving the back-end messages elsewhere if we want to)
is a pretty simple distinction to make. It's also very easy to hack. Hacking is good!

The clone-and-go model (like you described in your mytemplate.resources example) is totally
reasonable. After all, the hack-it approach is how jspwiki.properties works, right? We provide
a .tmpl original, and expect that deployers will customize this as they go. We also expect
that they keep it in sync with JSPWiki as it evolves, because it gains properties from time
to time! I don't see why presentation-tier messages should be any different.

I understand your concern about revision management, but it is only a minor concern. Our message
key names are (or should be) pretty stable by now. And frankly, the default.properties files
are ALREADY the original source for every third-party template's keys.

I agree that, in the short term, supplying our own errors is the way to go. But using @ValidateMethod
in preference to @Validate annotations is a poor use of committers' time. It would mean we'd
just re-write validation routines for simple things like length checking, optionality, regex,
etc. Stripes does this elegantly and in a bug-free way already. That is exactly the kind of
low-value-added coding we should NOT be doing.

> 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