hello alex. >-----Original Message----- >From: Alexander Klimetschek [mailto:aklim...@adobe.com] >Sent: Tuesday, October 14, 2014 10:13 PM >To: dev@sling.apache.org >Subject: Re: [PROPOSAL] Context-specific configuration for Apache Sling, >Multitenancy > >I see 3 problems: > >- allowing to hook in a custom lookup strategy and not defining a clear lookup >& content model (too much magic in such things is bad, it should be obvious by >just browsing the JCR, just as with resource types) >- the idea of putting configurations itself under /content; configs have a >different management lifecycle and ACLs
to shorten a discussion i've written a persistence provider that stores exactly you want it - in a shadow structure below /conf. this was only a small deviation from the existing persistence provider, documentation of "ConfStructurePersistenceProvider" at [1], impl at [2] still i see a need for a pluggable architecture at this point. starting on the green you are right. but we have already thousands of sling-based applications out there. and because no standard for context-specific configs existed in the past, every dev team has invented their own strategy having tens of thousands of sites with existing configuration. supporting them only needs an implementation of a custom PeristenceProvider, new configuration can be stored at /conf (the implementation supports multiple persistence providers for reading). and not all configuration parameters are so sensitive that they cannot be stored together with content. we have configuration parameters like "list of news category names" or parameters to tweak the style or behavior of some marketing features on the site. they should be allowed to be configured by authors and are more or less part of the content. but let's not start philosophical discussions on that. >- complexity of the API, Parameter<> generics just replicate the valuemap, but >in what seems to me like an overengineered fashion & one that shields too much >from the power of JCR, which might lead to have people invent custom string >formats instead of using JCR properties; in reality, 80% of properties are >strings, 10% each are boolean or integers (subjective experience stats TM :)) the Parameter<> generics only supports types supported by JCR (single and multi-valued), and a map which is stored in a string array internally. see more on this topic in my answer to justins mail. [1] http://wcm.io/config/core/persistence-providers.html [2] https://github.com/wcm-io/wcm-io/blob/master/config/core/src/main/java/io/wcm/config/core/persistence/impl/ConfStructurePersistenceProvider.java
