[
https://issues.apache.org/jira/browse/SLING-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated SLING-3407:
-----------------------------------------
Attachment: SLING-3407.patch
Here is a quick patch (compiles & tests success, but not fully tested in
reality yet): [^SLING-3407.patch]
There are 2 open questions:
1) getDefaultLocale() method: do we need that anymore? I don't think a provider
should be responsible for the default locale, and with multiple providers it
doesn't really make sense anymore. Currently it is a fixed configuration on the
JcrResourceBundleProvider and used as a fallback in case a "null" locale is
passed to the provider. But IMO this needs to be handled at higher levels, such
as the request object, which already does that - if you pass null as locale, it
will use the request.getLocale() method which has its own resolution.
getDefaultLocale() is used in the I18nFilter though, as a default fallback for
request.getLocale() in some cases (in case it's not a SlingHttpServletRequest
afaics). But this is after the RequestLocaleResolver returned null - and I
don't think this needs another fallback. One should have the default fallback
over in the RequestLocaleResolver.
Long story short: don't have getDefaultLocale() on the new RBManager (note:
it's currently in the patch), and deprecate it on the RBProvider interface.
2) BUNDLE_REQ_ATTR constant: I moved it over to the new RBManager interface and
deprecated it on the RBProvider. But it seems it is not really used - the
I18nFilter only reads it from the request attributes, but it never writes it.
So application code would have to set it itself, not sure if that is a frequent
thing to do.
So it might be ok to just keep it on the RBProvider for backwards compatibility
and not bring it over and promote it further on RBManager.
> ResourceBundleManager API
> -------------------------
>
> Key: SLING-3407
> URL: https://issues.apache.org/jira/browse/SLING-3407
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Alexander Klimetschek
> Labels: i18n
> Attachments: SLING-3407.patch
>
>
> Currently there is the ResourceBundleProvider service interface, which really
> is an SPI, now that you can have multiple of them. The right way of accessing
> them is to get all service references, sort by service ranking (highest
> first) and then take the result from the first one that doesn't give you a
> null result (null resource bundle from getResourceBundle()). This is done in
> the I18nFilter and is quite a bit of boilerplate that client code should not
> have to worry about.
> Thus there should be a new API, something like a ResourceBundleManager with
> the 2 methods for getResourceBundle() (with basename and without).
> [1]
> http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/I18NFilter.java
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
