[
https://issues.apache.org/jira/browse/SLING-5886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15389268#comment-15389268
]
Alexander Saar commented on SLING-5886:
---------------------------------------
bq. 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 think it would be great if the approach described by [~cziegeler] together
with a default/sample content structure could be made the default, so that
users of sling have an example and not make the same mistakes as others in the
past when it comes to content structures for multi-site/tenant scenarios and we
have some guidance around access control settings etc. I know this is not
necessarily a pure Sling concern, but I assume almost everyone will use Sling
on top of a content repository. other resolve mechanisms can be provided on top
of that per project need.
> 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)
