[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389170#comment-15389170
]
Stefan Seifert commented on SLING-5886:
---------------------------------------
ah, this good timing. i've started with the basic API approach as well. there
are several similarities already.
as in wcm.io config and your apporach my primary entry point to configuration
is adaptTo - but with typed annotation class access, which is mapped internally
to a valuemap from a resource (this was your idea as well some time ago...) -
e.g.
{code:java}
// 'config' contains the resolved and inherited configuration matching for this
content resources
MyConfigClass config = myContentResource.adaptTo(MyConfigClass.class);
{code}
you are currently using Preferences/Preference classes which is a thin layer
about a ValueMap - much like it was in wcm.io Config before.
my main entry point if adaptTo is not used is
[ConfigurationResolver|https://github.com/stefanseifert/sling-config/blob/develop/api/src/main/java/org/apache/sling/config/ConfigurationResolver.java]
which provides both typed access via annotation class and lower level to the
same config using a value map.
the logic where the configuration is stored and how the link is done between
content path and configuration locations is not hard-wired in my plan, but
pluggable which it was before in wcm.io config. the approach you describe in
your prototype should be one - perhaps the primary default - approach. i like
to add a declarative as well to get rid of the {{sling:config}} property
wherever possible (declarative = configure a strategy once where configuration
is stored and how it can be different on different levels and apply it
automatically to all sites). but this is only a step further from your approach.
the major difference in your prototype to additionally provide a "low-level"
configuration support which just returns resources. in my terminology i would
rather have called "preferences" "configuration", and what you call
"configuration", the low-level resource-anything support, something else (don't
know hat currently). but this feature is definitely missing in my usecase
listing outlined in https://wcm-io.atlassian.net/wiki/x/BQBLAQ
> 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)
