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