Core Component Model Logic not easy customizable

[stefanseifert]

The proxy pattern of the core components is very flexible and allows to override everything as required by a custom application. But overwriting is always an "all or nothing" choice. This is ok for the HTL files, which are usually not very big, and ideally already modularized in a set of chunks where only a few needs to be overridden.

But for the Java side this looks different. Some models - e.g. the ImageImpl, ListImpl or SocialMediaHelperImpl contain a lot of logic. If we want to customize only one line of code, we have to copy (duplicated) the whole class and change the single line. Once the next core components version is deployed the copied code is outdated.

It would be better for complex models to use the model impl classes only for "glue code" like reading the property, providing the setters for the interface methods - but putting the real business logic in separate classes which are published via OSGi and can be reused by applications. This business classes could not only be re-used by customization of this model, but also by custom components.

This separation of logic would be especially useful for "aspects" needed by a lot of components like:

• externalizing and rewriting URLs and links
• resolving assets and building sets of responsive image URLs
• collecting lists of pages for navigation components

[justinedelson]

Leaving aside the broader question of whether or not the existing model classes can be decomposed into substitutable services (which is a good topic nevertheless), there shouldn't be a need to copy any code when creating custom model classes. This is what https://issues.apache.org/jira/browse/SLING-6778 was designed to avoid. A custom model class should be able to delegate the methods it isn't interested in to the adapted model from the super type as well as use the super type methods inside custom implementation of methods.

[stefanseifert]

thanks @justinedelson, this is great - i've missed the new delegation feature from SLING-6778. with this it is possible to replace or post-process the result from single interface methods without affecting the others.

it does not resolve customization use cases where some "deeper logic" hidden in private methods in the sling models classes, tough - but the delegation feature helps a lot.

[gabrielwalt]

We need to make sure that the delegation pattern is well documented.

[bpauli]

I added an example of using the delegation pattern at https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/wiki/Delegation-Pattern-for-Sling-Models