Allow collectionSelector fragment configuration fields to select all collection provider types when no itemType is specified

Product Ideas
,
1

Hello,

I would like to request an improvement for the collectionSelector configuration field in fragments.

Current behavior

When creating a Search Blueprint and enabling it to be usable as a collection, the resulting collection can be selected in a standard Collection Display widget.

However, if a custom fragment contains a configuration field of type collectionSelector without specifying an itemType, the same collection is not selectable.

Example fragment configuration:

json

{
"fieldSets": [
{
"label": "Collection",
"fields": [
{
"name": "collection",
"type": "collectionSelector"
}
]
}
]
}

In this case, only certain collection providers are shown. Blueprints that are registered for a specific type, for example JournalArticle, are not displayed.

As a workaround, the fragment configuration can be restricted to a specific item type:

json

{
"fieldSets": [
{
"label": "Collection",
"fields": [
{
"name": "collection",
"type": "collectionSelector",
"typeOptions": {
"itemType": "com.liferay.journal.model.JournalArticle"
}
}
]
}
]
}

With this configuration, Journal Article blueprint collections become selectable.

Expected behavior

If no itemType is specified in the collectionSelector configuration, the selector should behave like the selector used in the standard Collection Display widget.

That means all compatible collections should be selectable, including collections based on:

  • All Searchable Types
  • Journal Articles
  • Documents / File Entries
  • Object Entries
  • Other supported asset or entity types

In other words, an omitted itemType should mean “do not restrict the selectable collection types”, instead of implicitly limiting the selector to only AssetEntry-type providers.

Reasoning

The current behavior is confusing because it differs from the behavior of the Collection Display widget.

In the Collection Display widget, the same component can be used with collections from different provider types. A user can select blueprint collections based on “All Searchable Types”, Journal Articles, or other supported types.

For fragments, however, the current implementation requires the developer to define a fixed itemType. This makes fragments much less flexible.

If a fragment should support multiple blueprint collection types, developers currently have to duplicate the fragment for each possible item type, for example:

  • one fragment for JournalArticle
  • one fragment for FileEntry
  • one fragment for ObjectEntry
  • one fragment for AssetEntry
  • etc.

This is difficult to maintain and not scalable, especially when the fragment itself is generic and can render different collection types.

Use case

We create reusable fragments where editors can select a collection in the fragment configuration. These fragments should not be limited to one specific content type.

For example, the same fragment may be used on different pages with different collections:

  • a collection of web content articles
  • a collection of documents
  • a collection of object entries
  • a collection based on all searchable types

The fragment is designed to be generic, and the selected collection determines the content. Therefore, the fragment should not have to be duplicated only because the collection provider type is different.

Requested improvement

Please consider changing or extending the collectionSelector behavior so that:

  1. If typeOptions.itemType is specified, the selector only shows collections for that item type.
  2. If typeOptions.itemType is not specified, the selector shows all available/compatible collection providers, similar to the Collection Display widget.
  3. Blueprint collections for specific item types should also be selectable when no itemType restriction is configured.

This would make the collectionSelector more intuitive, more consistent with the Collection Display widget, and much easier to use for reusable generic fragments.

Best regards,
Jan