Stefan Seifert wrote
> sounds basically ok to me.
>
> of course we could check first if the tweaks we want to enable using this SPI
> might be as well directly implemented in the
> DefaultConfigurationResourceResolvingStrategy, if they are a good addition to
> the general default behavior.
>
> if the usecases are too exotic for the "mainstream" such an SPI makes sense.
>
Right, so basically we have two use cases:
a) If the value from the sling:confRef property ends with the bucket
name, then a warning is logged and this value is ignored
b) If the value from the sling:confRef property is relative, the parent
hierarchy of the context resource is traversed up to find a context
resource with an absolute property. Once found, these are concatenated.
For example
/content/a
+ sling:confRef=/conf/a
/content/a/b
+ sling:confRef=b
If you try to find configurations for /content/a/b it searches in
/conf/a/b first, then /conf/a
Regards
Carsten
> stefan
>
>> -----Original Message-----
>> From: Carsten Ziegeler [mailto:[email protected]]
>> Sent: Thursday, November 3, 2016 9:51 AM
>> To: Sling Developers
>> Subject: [CAConfig] Provide an SPI for transformation of config refs
>>
>> Hi,
>>
>> the current mechanism (implemented in
>> DefaultConfigurationResourceResolvingStrategy) uses the value from the
>> sling:confRef property and validates it against some built-in rules.
>> One of them is discarding relative paths.
>>
>> We would like to have a hook/SPI for allowing relative paths and for
>> further validation like if the sling:confRef property contains the
>> bucketName "sling:configs", the value should be discarded.
>>
>> So basically what I'm thinking of is an interface with a single method
>> taking the ContextResource and the bucket name and returning a string
>> (absolute path) or null.
>>
>> WDYT?
>>
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> [email protected]
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
