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://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/master/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/internal/models/v1/BreadcrumbImpl.java#L72 > [1] > https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration-spi.html
