[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15393592#comment-15393592
]
Stefan Seifert commented on SLING-5886:
---------------------------------------
yes, it makes since to allow a configuration name for the custom annotation
classes as well - although it makes the default value handling a bit more
complex (default values should apply to the value map variants as well, not
only for mapping to annotation classes, thus the configuration name is the link
between those two signatures - default values would only apply in the ValueMap
signatures if the "default config name" derived from the custom class is used).
adding optional name would lead to more overloads in the get methods of the
ConfigurationResolver - what about just using a builder pattern for the API?
https://github.com/stefanseifert/sling-config/commit/86c089ddc3f8c8ac81a7caa7fe2f0322a80cc719
code snippet examples:
{code:java}
SimpleConfig cfg = cfgResolver.get(resource).as(SimpleConfig.class);
Collection<ListConfig> cfgList =
cfgResolver.get(resource).asList(ListConfig.class);
SimpleConfig cfg =
cfgResolver.get(resource).name("myoptionalname").as(SimpleConfig.class);
ValueMap props = cfgResolver.get(resource).name("myname").asValueMap();
Collection<ValueMap> propsList =
cfgResolver.get(resource).name("myname").asValueMapList();
{code}
> 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)
