[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15392614#comment-15392614
]
Stefan Seifert commented on SLING-5886:
---------------------------------------
{quote}I like the name ConfigurationResourceResolver and I think it makes sense
to keep the interfaces separate.{quote}
moved it to a separate sub-package.
{quote}
The CR is has methods to return a value map, I think we should only return
read-only configurations and make this clear in the javadocs. In my prototype I
have the NamedValueMap (extends ValueMap) in order to have a way to return the
config name. Another option would be to include the name in the value map as a
predefined key.
{quote}
do we really need this? if the configuration annotation class is returned it
does not contain a "name" method either. name in the valuemap as predefined key
is not nice either.
{quote}
I personally don't like the method names "get" and "getList" as by just looking
at these names it's not clear what they do, but if I'm the only one we can go
with these.
{quote}
do you not like the names "get" and "getList", or just that there is no suffix
what they get?
i've renamed the method that return a valuemap to include a valuemap in it's
name. i do not wanted to use "resolve..." as method name as in you prototype,
because when looking at the ResourceResolver the getResource method is the
primary method to go, whereas the "resolve" method is a very special method
applications rarely should use.
i've not (yet) renamed the get/getList methods that return a custom annotation
class because ... it returns custom annotation class.
> Sling Configuration - Initial Contribution
> ------------------------------------------
>
> Key: SLING-5886
> URL: https://issues.apache.org/jira/browse/SLING-5886
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Reporter: Stefan Seifert
> Assignee: Stefan Seifert
>
> as discussed in the mailing list (see [my post from april
> 2016|http://apache-sling.73963.n3.nabble.com/RT-Use-cases-for-content-specific-configurations-in-Sling-amp-Contribution-td4060813.html])
> i want to contribute the wcm.io Configuration parts that are not
> AEM-specific.
> the current features of wcm.io Configuration are described here:
> http://wcm.io/config/
> the main goal is to support "context-specific" configuration, that means
> configuration that is different for different content paths (e.g. sites,
> tenants).
> during the contribution some changes and refactorings are required/planned,
> e.g.:
> * remove some dependencies to wcm.io build environment, Guava and others
> * remove the "application" distinction currently part of wcm.io Configuration
> in favor or a more path-based distinction
> * refactor the user-faced configuration API to further simplify it and
> support OSGi R6-style annotation classed for typed configuration access
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
