You are raising two different issues:
- whether users should be able to choose the template at run-time
- whether each template should be able to specify the location of its
i18n bundles
The answer to the first issue could go either way, although I lean
against it. The default template allows users to change their 'skin
(CSS)', not the template. If you meant "allow users to change their
skin", then nothing about the default i18n location will prevent skin-
changing in any way. So the setBundle issue is completely separate
from template-changing.
Absence or presence of setBundle tags in the default template doesn't
affect you using them in custom templates, so the second question is a
non-issue too. In other words, even if we specify the default location
in web.xml, you can still override it via your own setBundle tags.
This is, in fact, what 2.6 does now.
On Mar 6, 2008, at 3:09, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]
> wrote:
Hi.
I just noticed in changelog of latest nightly the following:
2007-2-24 Andrew Jaquith <ajaquith AT apache DOT org>
* Reverted the JSP changes from my last commit so that
existing 2.6 deployments
don't need to reconfigure web.xml. That commit removed the
fmt:setBundle tag
because of the addition of a servlet config parameter in
web.xml. The web.xml
modifications remain, however, so that any new JSPs won't need
to use setBundle.
For 2.8, we will remove the setBundle tags entirely.
2007-2-24 Andrew Jaquith <ajaquith AT apache DOT org>
* [JSPWIKI-195]: Superfluous WEB-INF/i18n directory created
during war build.
Also, several unneeded JARs were also being included.
* Eliminated the need to hard-code <fmr:setBundle> tags in
JSPs by setting
the web.xml <comtext-param>
javax.servlet.jsp.jstl.fmt.localizationContext
so that it points to templates.default. Removed the setBundle
tags from
all JSPs.
I see a possible problem here. If the bundle is expected to be set
in the web.xml (and references within jsp removed) how
it can be managed to have multiple templates and choosing them
through user preferences? Fixing the template within
a given JSPWiki instance may be acceptable (not so sure) but in that
case it should not be possible for users to choose
their preferred one. Or is there any other expected way to manage
this?
LG
