Yeah, i had the same experiences where i'd blame poor adoption of context aware configuration in AEM code.
Hence me planning to implement custom context path strategy (or else ?) that only considers content that AEM already handles (so I have all AEM's MSM/WCM features) On 12/10/2018 15:26, "Julian Sedding" <[email protected]> wrote: Hi Nicolas I'm working on an AEM project where we used CACs for various features. Given our experience, I assume we used them incorrectly. We will refactor the code and migrate existing content in the near future. Points to consider (mostly AEM specific): - CACs can be problematic with MSM - CACs can be problematic with replication - CACs can be problematic with translations (if CAC contents need to be translated) - CACs are unintuitive for content-editors So as long as you - store only "real" configurations - editing and distribution/replication of CACs is handled either via deployment or by a sys-admin or dev type user OR - all CACs editable by a (power?) content-editor are stored inside the page tree (that's where the extension SPIs come in) - fallback CACs are only ever deployed ...you should be fine. Note: - I tried solving some issues using the SPIs and had varying success. I didn't find them intuitive or transparent to implement. - If you're going down that route, I highly recommend debug logging (or trace? - cannot remember) on the CAC java packages. This will enumerate all candidate paths that are looked up. - It is easy to get into a situation where candidate lookup paths explode exponentially - watch out for this, as it can easily become a performance issue. Regards Julian On Fri, Oct 12, 2018 at 8:34 AM Nicolas Peltier <[email protected]> wrote: > > Hi, > > because i'm talking about context aware config, i'll give some context here > :-) i'd like test using caconfig logic to replace specific inheritance like > core breadcrumb's [0] that will allow less code and additional inheritance > levels (assuming i'm storing different content policies at different > places). > > While looking at SPI documentation level of configurability [1], i'm pretty > confident i'll be able to tweak things around pretty heavily and reach what > i want, it's also a bit scary in a way that the more possibilities you > have, the more wrong things you could do. > > what i'd need here is basically looked up paths to be > current resource, then locale specific content policy then some generic > content policy for that resource component. I guess i can do that > implementing ContextPathStrategy, but i'm confused with Configuration* e.g. > ".ConfigurationResourceResolvingStrategy you can define where configuration > data is looked up, and how resource and property inheritance is handled." > looks also like something that could help me. > > i'm happy here : to have some guidance, and through / after that > conversation contribute some samples / examples to that documentation page. > > Nicolas > > [0] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAdobe-Marketing-Cloud%2Faem-core-wcm-components%2Fblob%2Fmaster%2Fbundles%2Fcore%2Fsrc%2Fmain%2Fjava%2Fcom%2Fadobe%2Fcq%2Fwcm%2Fcore%2Fcomponents%2Finternal%2Fmodels%2Fv1%2FBreadcrumbImpl.java%23L72&data=02%7C01%7Cnpeltier%40adobe.com%7C480cd019e2d142014ceb08d630465c99%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636749476092360803&sdata=b%2Bw0Zwfm6qfNctYfayeYVdebA8ig8l820Ggekt3WNOw%3D&reserved=0 > [1] > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsling.apache.org%2Fdocumentation%2Fbundles%2Fcontext-aware-configuration%2Fcontext-aware-configuration-spi.html&data=02%7C01%7Cnpeltier%40adobe.com%7C480cd019e2d142014ceb08d630465c99%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636749476092360803&sdata=PHEH0WEFLirNWm4R1bPUU7UT1YtM94uMkG8jvTqXWy0%3D&reserved=0
