Re: [caconfig] changing config path

2016-12-19 Thread Nicolas Peltier

> On Dec 16, 2016, at 6:52 PM, Stefan Seifert <sseif...@pro-vision.de> wrote:
> 
> this gets very AEM product specific, i'm not sure if this is the right list 
> for it.
not “forcing” one configuration to be in a place and not in another would make 
that discussion slingy again :-)

> but anyway - as i understood one main of the learnings of different 
> configuration approaches of the last years was: keep all configuration out of 
> /content. so this was the main guideline for the default strategies.
yep, and it’s a good rule i think if configuration is only configuration, but 
if you need your users to manipulate it, it becomes content too.


> stefan
> 
>> -Original Message-
>> From: Nicolas Peltier [mailto:npelt...@adobe.com]
>> Sent: Friday, December 16, 2016 3:53 PM
>> To: users@sling.apache.org
>> Subject: Re: [caconfig] changing config path
>> 
>> Hi,
>> 
>> bear in mind i really want to “customize” as less as possible. Hence in my
>> point of view it’s wrong too to customize the conf path.
>> 
>> However, context aware configuration allows me to use widgets for AEM pages
>> in /content/conf, i can then reuse in component dialogs in my site, and
>> then have a single point of entry for entering the configuration data, and
>> have fallback, e.g:
>> 
>> /content/mysite/us/en/mypage/jcr:content/comp@myData which is let say a
>> list of AEM tags,
>> i can configure in comp’s dialog, in case there is nothing
>> it fall backs to
>> /content/conf/us/en/myconf@myData
>> fall backs to
>> /content/conf/global/myconf@myData
>> 
>> with that setup i have the two following features for free :
>> - configure a widget for handling myData once, and reuse in all other
>> places, which brings me consistency,
>> - copy / paste / activate / delete / edit /content/conf/* items very
>> quickly.
>> 
>> *not* doing so would make me customize / develop things for the two above
>> features.
>> 
>> Nicolas
>> 
>>> On Dec 16, 2016, at 10:52 AM, Stefan Seifert <sseif...@pro-vision.de>
>> wrote:
>>> 
>>> in my point of view it is wrong to store the config data in /content/conf
>> if the only motivation to do this is the limitation of some tooling.
>>> i would recommend to keep the config root of the default strategies at
>> /conf.
>>> 
>>> what is the purpose of the "AEM content management tools" - edit the
>> configuration?
>>> then have a look at the (not yet finished and not yet documented)
>> http://wcm.io/caconfig/editor/
>>> the is also a sample project https://github.com/wcm-io/wcm-io-
>> caconfig/tree/develop/sample-app
>>> 
>>> it allows to create config editor templates in /content/*, but the config
>> data is loaded from and stored in /conf. the editor shows the config data
>> of the context where the page is created.
>>> 
>>> stefan
>>> 
>>>> -Original Message-
>>>> From: Nicolas Peltier [mailto:npelt...@adobe.com]
>>>> Sent: Thursday, December 15, 2016 9:38 AM
>>>> To: users@sling.apache.org
>>>> Subject: [caconfig] changing config path
>>>> 
>>>> Hi,
>>>> 
>>>> on my project i want to use context aware config, but in order for me to
>>>> profit from some AEM content management tools, i would like to move the
>>>> root of my configuration to /content/conf.
>>>> 
>>>> I realized it was not possible unless i change config path in
>> configuration
>>>> from /conf to /content/conf. Looks to me that this configuration is just
>>>> used to *check* that configuration is allowed.
>>>> 
>>>> what is the best:
>>>> - changing it to be “/“ (to allow applications using /conf to still
>> work):
>>>> i’m not conscious right now of the risk this represents,
>>>> - patching default configuration component to accept multiple
>> configuration
>>>> paths,
>>>> - tweaking AEM tools to work under /conf (aka you shall not use anything
>>>> but “/conf”)
>>>> 
>>>> thanks,
>>>> Nicolas
>>>> 
>>> 
> 



RE: [caconfig] changing config path

2016-12-16 Thread Stefan Seifert
this gets very AEM product specific, i'm not sure if this is the right list for 
it.

still, why do you want to configure your fallback below /content/conf and not 
in /conf? they could be stored in /conf as cq:Page nodes as well with some 
tweaking of configuration. looking up configuration data in the page itself and 
then in the fallbacks is not supported by the default strategies, although it 
would be possible to add this aspect by providing an additional configuration 
resource resolving strategy.

but anyway - as i understood one main of the learnings of different 
configuration approaches of the last years was: keep all configuration out of 
/content. so this was the main guideline for the default strategies.

stefan

>-Original Message-
>From: Nicolas Peltier [mailto:npelt...@adobe.com]
>Sent: Friday, December 16, 2016 3:53 PM
>To: users@sling.apache.org
>Subject: Re: [caconfig] changing config path
>
>Hi,
>
>bear in mind i really want to “customize” as less as possible. Hence in my
>point of view it’s wrong too to customize the conf path.
>
>However, context aware configuration allows me to use widgets for AEM pages
>in /content/conf, i can then reuse in component dialogs in my site, and
>then have a single point of entry for entering the configuration data, and
>have fallback, e.g:
>
>/content/mysite/us/en/mypage/jcr:content/comp@myData which is let say a
>list of AEM tags,
>i can configure in comp’s dialog, in case there is nothing
>it fall backs to
>/content/conf/us/en/myconf@myData
>fall backs to
>/content/conf/global/myconf@myData
>
>with that setup i have the two following features for free :
>- configure a widget for handling myData once, and reuse in all other
>places, which brings me consistency,
>- copy / paste / activate / delete / edit /content/conf/* items very
>quickly.
>
>*not* doing so would make me customize / develop things for the two above
>features.
>
>Nicolas
>
>> On Dec 16, 2016, at 10:52 AM, Stefan Seifert <sseif...@pro-vision.de>
>wrote:
>>
>> in my point of view it is wrong to store the config data in /content/conf
>if the only motivation to do this is the limitation of some tooling.
>> i would recommend to keep the config root of the default strategies at
>/conf.
>>
>> what is the purpose of the "AEM content management tools" - edit the
>configuration?
>> then have a look at the (not yet finished and not yet documented)
>http://wcm.io/caconfig/editor/
>> the is also a sample project https://github.com/wcm-io/wcm-io-
>caconfig/tree/develop/sample-app
>>
>> it allows to create config editor templates in /content/*, but the config
>data is loaded from and stored in /conf. the editor shows the config data
>of the context where the page is created.
>>
>> stefan
>>
>>> -Original Message-
>>> From: Nicolas Peltier [mailto:npelt...@adobe.com]
>>> Sent: Thursday, December 15, 2016 9:38 AM
>>> To: users@sling.apache.org
>>> Subject: [caconfig] changing config path
>>>
>>> Hi,
>>>
>>> on my project i want to use context aware config, but in order for me to
>>> profit from some AEM content management tools, i would like to move the
>>> root of my configuration to /content/conf.
>>>
>>> I realized it was not possible unless i change config path in
>configuration
>>> from /conf to /content/conf. Looks to me that this configuration is just
>>> used to *check* that configuration is allowed.
>>>
>>> what is the best:
>>> - changing it to be “/“ (to allow applications using /conf to still
>work):
>>> i’m not conscious right now of the risk this represents,
>>> - patching default configuration component to accept multiple
>configuration
>>> paths,
>>> - tweaking AEM tools to work under /conf (aka you shall not use anything
>>> but “/conf”)
>>>
>>> thanks,
>>> Nicolas
>>>
>>



Re: [caconfig] changing config path

2016-12-16 Thread Nicolas Peltier
Hi, 

bear in mind i really want to “customize” as less as possible. Hence in my 
point of view it’s wrong too to customize the conf path. 

However, context aware configuration allows me to use widgets for AEM pages in 
/content/conf, i can then reuse in component dialogs in my site, and then have 
a single point of entry for entering the configuration data, and have fallback, 
e.g:

/content/mysite/us/en/mypage/jcr:content/comp@myData which is let say a list of 
AEM tags,
i can configure in comp’s dialog, in case there is nothing
it fall backs to 
/content/conf/us/en/myconf@myData
fall backs to
/content/conf/global/myconf@myData

with that setup i have the two following features for free :
- configure a widget for handling myData once, and reuse in all other places, 
which brings me consistency,
- copy / paste / activate / delete / edit /content/conf/* items very quickly.

*not* doing so would make me customize / develop things for the two above 
features.

Nicolas

> On Dec 16, 2016, at 10:52 AM, Stefan Seifert  wrote:
> 
> in my point of view it is wrong to store the config data in /content/conf if 
> the only motivation to do this is the limitation of some tooling.
> i would recommend to keep the config root of the default strategies at /conf.
> 
> what is the purpose of the "AEM content management tools" - edit the 
> configuration?
> then have a look at the (not yet finished and not yet documented) 
> http://wcm.io/caconfig/editor/
> the is also a sample project 
> https://github.com/wcm-io/wcm-io-caconfig/tree/develop/sample-app
> 
> it allows to create config editor templates in /content/*, but the config 
> data is loaded from and stored in /conf. the editor shows the config data of 
> the context where the page is created.
> 
> stefan
> 
>> -Original Message-
>> From: Nicolas Peltier [mailto:npelt...@adobe.com]
>> Sent: Thursday, December 15, 2016 9:38 AM
>> To: users@sling.apache.org
>> Subject: [caconfig] changing config path
>> 
>> Hi,
>> 
>> on my project i want to use context aware config, but in order for me to
>> profit from some AEM content management tools, i would like to move the
>> root of my configuration to /content/conf.
>> 
>> I realized it was not possible unless i change config path in configuration
>> from /conf to /content/conf. Looks to me that this configuration is just
>> used to *check* that configuration is allowed.
>> 
>> what is the best:
>> - changing it to be “/“ (to allow applications using /conf to still work):
>> i’m not conscious right now of the risk this represents,
>> - patching default configuration component to accept multiple configuration
>> paths,
>> - tweaking AEM tools to work under /conf (aka you shall not use anything
>> but “/conf”)
>> 
>> thanks,
>> Nicolas
>> 
> 



RE: [caconfig] changing config path

2016-12-16 Thread Stefan Seifert
in my point of view it is wrong to store the config data in /content/conf if 
the only motivation to do this is the limitation of some tooling.
i would recommend to keep the config root of the default strategies at /conf.

what is the purpose of the "AEM content management tools" - edit the 
configuration?
then have a look at the (not yet finished and not yet documented) 
http://wcm.io/caconfig/editor/
the is also a sample project 
https://github.com/wcm-io/wcm-io-caconfig/tree/develop/sample-app

it allows to create config editor templates in /content/*, but the config data 
is loaded from and stored in /conf. the editor shows the config data of the 
context where the page is created.

stefan

>-Original Message-
>From: Nicolas Peltier [mailto:npelt...@adobe.com]
>Sent: Thursday, December 15, 2016 9:38 AM
>To: users@sling.apache.org
>Subject: [caconfig] changing config path
>
>Hi,
>
>on my project i want to use context aware config, but in order for me to
>profit from some AEM content management tools, i would like to move the
>root of my configuration to /content/conf.
>
>I realized it was not possible unless i change config path in configuration
>from /conf to /content/conf. Looks to me that this configuration is just
>used to *check* that configuration is allowed.
>
>what is the best:
>- changing it to be “/“ (to allow applications using /conf to still work):
>i’m not conscious right now of the risk this represents,
>- patching default configuration component to accept multiple configuration
>paths,
>- tweaking AEM tools to work under /conf (aka you shall not use anything
>but “/conf”)
>
>thanks,
>Nicolas
>