[List] Allow custom sources, sort orders and filters to be defined

[henrykuijpers]

https://github.com/Adobe-Marketing-Cloud/aem-core-wcm-components/blob/be656c09ea43ea80b37e0727399aa48de3e43c8a/bundles/core/src/main/java/com/adobe/cq/wcm/core/components/models/impl/v1/ListImpl.java

As you can see, the options are now hardcoded. In most cases you will definitely want to reuse the existing options, you will probably only want to add a few more sources. And probably also a few more ways of sorting the list.

I think we can easily facilitate this with the OSGi framework - They can be separate components that are gathered and used by the List-component.

[henrykuijpers]

Also, the List component currently contains a lot of specifics that are related to rendering a specific list item.

I.e. showDescription, showModificationDate, getDateFormatString, linkItems, etc.

[raducotescu]

Henry, that's because until now the List only provided Pages as items. All those optional specifics make sense for Pages.

We've discussed a bit your comment and we understood this: you'd like a SPI for collecting items that could dynamically be selected from the list's configuration dialog; to that extent I think this could be achieved with a data source that would return collector types, bound to SPI implementations.

The concern I have with this approach is documenting the collectors, since the returned result will greatly differ from what you can document when you know the possible collection types.

Could you please provide more details / a minimal patch that would provide the functionality you'd like to see implemented?

[henrykuijpers]

Indeed:

Collectors

A collector would consist of, at a minimum, a class that defines a way to return the contents of the list (i.e. from a CAConfig, based on an inherited page property, based on a date, related articles, .... could be anything) + a way to describe it (i.e. a name and a title)

It could also contain a dialog definition that allows the author to further configure any specifics regarding the collector.

I.e. if tags are the source, then the dialog partial would contain a field that allows the author to pick the tag (already there, but "tied" into the List-component dialog and "hardcoded" in the List-model). If a search query would be the result, then the dialog partial would contain a text field where the author can enter the query (already there, but "tied" into the List-component dialog and "hardcoded" in the List-model). If a CAConfig is the source, then it could be a list of all configs/properties that would be allowed to function as a list source (this could be custom code, as this doesn't sound like a very generic use case - It's more about being able to do this, without having to adjust/override almost the complete list component).

Renderers In most cases, the result would be pages (I assume letting the List-component support Assets is a whole other use case?).

Given the outcome of the collector, a list of pages, the renderer would be responsible for rendering out the resulting pages.

It can simply be a component, with again a dialog partial that allows the author to customize the rendering.

Examples:

Simple list

This would be the rendering that we have right now, the most basic rendering that you can do. The dialog could contain the various properties (showDescription, showModificationDate, linkItems, etc).

Other renders

The above renderer would be a perfect starting point. Any website that wants to show a basic list, can use the 'simple list' renderer to at least show the outcome of a certain list configuration.

However, with this approach you can add different custom renderers. Such as:

• Cardview
• Mosaic grid
• Article
• Teaser
• Carousel slide etc. etc.

The renderers could be documented on their own. They don't necessarily need to be documented in the List-documentation itself.

If any more examples are appreciated, I can share some with you. We have lots of different implementations for all our customers and it feels kind of clumsy to have to do that all the time, while we now have the chance to share our ideas and make the "ootb" list-component ready for more complex use-cases.

So, I'm not saying that the List-component itself should become very specific and very complex, I'm just saying that it would be great to have this flexibility ootb. :)

[rubnig]

Makes sense @henrykuijpers, list component is a component that almost always returns somewhere in your project and is really hard to extend right now (without copying all of the code). This should be more pluggable indeed.

[gabrielwalt]

(CQ-4218127)