Hi, Properties should not be merged, as that will produce undesirable side effects, however some things need to be merged.
Having attempted to write documentation I found it easiest to describe in terms of json documents. Using the examples in https://gist.github.com/ieb/460504e79c861cb980f4f0154210a869 given 2 configs from different locations Location A { "socialmedia" : { "youtube" : { "enabled" : false, "url" : "https://youtube.com"; }, "facebook" : { "enabled" : false, "apiusage" : false, "url" : "https://youtube.com"; }, Location B { "socialmedia" : { "facebook" : { "enabled" : true, "url" : "https://facebook.com"; } } } The result of A then B should be { "socialmedia" : { "youtube" : { "enabled" : false, "url" : "https://youtube.com"; }, "facebook" : { "enabled" : true, "url" : "https://facebook.com"; } } } ie Objects are merged but properties are not. socialmedia.facebook from A does not add @apiusage to the result, as socialmedia.facebook form B overwrites socialmedia.facebook from A. That will allow a deployer to completely replace a configuration "object" without having to get their head around more complex inheritance rules. This does assume that configurations are collected together into "objects". I think its is important to keep it simple. If this isnt simple enough then it needs some more thought. Best Regards Ian On 29 July 2016 at 15:11, Carsten Ziegeler <[email protected]> wrote: > Hi, > > looking at various documentations on the different approaches and the > implementations, there seem to be totally different opinions about if > merging of resources (and therefore resources) should be done. > > For this topic, let's not discuss names or how the resolving really > should work, let's focus on one topic: merging. > > Let's assume you have a global config at: > /config/global/foo - with properties @a, @b > and a content aware one at: > /config/mysite/foo - with properties @b, @c > > A content resource now sets /config/mysite as its context. If you get > the "foo" configuration, do we merge the properties and the result will > have @a, @b, and @c? Or is it just @b and @c? > > I personally think we should *not* support any merging because as soon > as you support merging you will need additional ways of not merging > properties etc etc. I think a configuration should be the full set of > properties. The confmgr implementation works exactly this way as well. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
