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:52:44 GMT

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

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

The broader issue here is how customizations are done. The model we've used in the presentation-tier,
largely, is one that uses the custom version of the file if supplied, but reverts to the default
version if not supplied.

This is, for example, why we don't use jsp:include tabs, but have our own wiki:include tag.
And the reason we have THAT is because the top-level JSPs are really controller pages that
link to the template presentation JSPs.

But with Stripes we do not need to be so rigid. It means we can blow up some of those assumptions,
and simplify things considerably while keeping things very customizable.

For example, the parameter binding stuff is taken care of the StripesFilter and/or useActionBean
tag. Validations become annotations on ActionBean properties. And the business logic moves
up into ActionBean methods. There is nothing for the top-level JSPs to do other than forward
to the content JSP!

In a world like that, I would argue that it's actually easier to have NO templates at all
-- just encourage template customizers to hack the top-level JSPs, which would be 100% presentation.
That's how WordPress does it, for example. This is a different model than the hypothetical
JAR model you mentioned, which is something that doesn't exist today.

Now, that's a detailed example. But it's related to the discussion we are having about presentation-tier
messages. ...

> 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