[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15388994#comment-15388994
]
Carsten Ziegeler commented on SLING-5886:
-----------------------------------------
[[email protected]] That's great - we have worked on a similar solution
and I've committed a prototype (which basically shows the API and how it should
work) at https://svn.apache.org/repos/asf/sling/whiteboard/cziegeler/sling-conf
. It would be great if we can somehow combine these two things and get the best
of both worlds.
That prototype provides support for context specific configurations which are
named resources: e.g., if you have a content resource you can the configuration
resource named "myconfig/something" and then do whatever you want with this
resource. This is the "low level" support which can be used for everything that
is context specific, so not just pure configurations but for example other
things like a workflow description etc.
Based on this low level support, there is support for something I called
preferences. Again you can get a named preference like "services/foo.service"
for a content resource and get back a (named) value map. The implementation for
preferences is more or less just convenience API and the implementation uses
the above mentioned low level support.
That's in a nutshell the API
> 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)
