Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Three suggestions for AssetPublisher aditional CollectionProviders
Hi all,
I just found out about Collection Providers for Asset Publisher (hooray!!) and this is totally aligned with our current worries about segmentation and user experience improvement.
So, here are three suggestions to improve this even more.
#1 - On a display page, a secondary asset publisher should have the possibility to show a collection of assets based on the tags or categories from the main asset; this is somewhat similar to the related assets, with a big difference: content is selected on-the-fly instead of being pre-prepared and easily outdated; I would call this the See Also Collection Provider
#2 - On any page, an asset publisher should investigate the page main content (ie TITLE, H1, H2) and perform an elastic search to recommend assets with the same keyworks; I would call this the Recommended Collection Provider
#3 - User segments should be taggable and categorized, so that on any page an Asset Publisher could show a collection of assets with the same tags / categories; I would call this the User Segment Collection Provider
HTH
Fernando
I just found out about Collection Providers for Asset Publisher (hooray!!) and this is totally aligned with our current worries about segmentation and user experience improvement.
So, here are three suggestions to improve this even more.
#1 - On a display page, a secondary asset publisher should have the possibility to show a collection of assets based on the tags or categories from the main asset; this is somewhat similar to the related assets, with a big difference: content is selected on-the-fly instead of being pre-prepared and easily outdated; I would call this the See Also Collection Provider
#2 - On any page, an asset publisher should investigate the page main content (ie TITLE, H1, H2) and perform an elastic search to recommend assets with the same keyworks; I would call this the Recommended Collection Provider
#3 - User segments should be taggable and categorized, so that on any page an Asset Publisher could show a collection of assets with the same tags / categories; I would call this the User Segment Collection Provider
HTH
Fernando
Hey Fernando,
Thanks a lot for the suggestions. I'm also glad that you like the feature of Collection Providers, I hope that you find lots of uses for it.
I'm happy to say that what you are proposing in points #1 and (maybe) #2 are already possible. As you may have already seen, you can develop your own Collection Providers by implementing the interface InfoListProvider<AssetEntry>. Its getInfoList() methods receive an InfoListProviderContext which has an InfoDisplayObjectProvider (which is optional). When the method is invoked from a display page, this provider allows accessing the content being presented in the display page. You can then use it to perform any desired query or search for related content. Since all of this is programmatic you can use any logic you want to find related content.
The first part of suggestion #2, searching for <h1>, etc seems very fragile to me. However in the context you have the layout object so you can retrieve it and retrieve any desired information from it in a custom InfoListProvider. And, of course, you can pass it to an elastic search query to retrieve similar content.
We are considering providing some out of the box InfoListProvider's as well as we identify common use cases that people develop, so we'd love to continue hearing what you are build with them.
Thanks a lot for the suggestions. I'm also glad that you like the feature of Collection Providers, I hope that you find lots of uses for it.
I'm happy to say that what you are proposing in points #1 and (maybe) #2 are already possible. As you may have already seen, you can develop your own Collection Providers by implementing the interface InfoListProvider<AssetEntry>. Its getInfoList() methods receive an InfoListProviderContext which has an InfoDisplayObjectProvider (which is optional). When the method is invoked from a display page, this provider allows accessing the content being presented in the display page. You can then use it to perform any desired query or search for related content. Since all of this is programmatic you can use any logic you want to find related content.
The first part of suggestion #2, searching for <h1>, etc seems very fragile to me. However in the context you have the layout object so you can retrieve it and retrieve any desired information from it in a custom InfoListProvider. And, of course, you can pass it to an elastic search query to retrieve similar content.
We are considering providing some out of the box InfoListProvider's as well as we identify common use cases that people develop, so we'd love to continue hearing what you are build with them.
<p>This sounds a bit too complicated for me. I would solve it in a different way.</p>
<p>#1 - I would create a special webcontent template and map it to a place on the page. In the template I would either use serviceLocator + assetEntryLocalService or a helper in the form of a template context contributor to fetch a list of items and display them. I am not sure, why I should use an InfoListProvider here? Except for the "template inflation", the need to create many templates for the same structure, I have already mentioned in a previous test of the mapping feature.</p>
<p>#2 Basically I would use the same solution idea. But instead of using title/h1/h2 I would use the webcontent title or something to do the search.</p>
<p>My main issue here is that it is currently awfully inconvenient to reuse content in content. It is actually rather complicated to fetch the categories/tags/... in a Webcontent. Oh, I can do it, I have a ton of example code and helper functions available. But for most people, it is hard.</p>
<p> </p>
<p>#3 I am not sure why this is needed? I mean, I can already create an asset collection for a segment. So, I would just need to create one list with whatever categories/tags I see fit. Or even simpler, I could configure the asset publisher on the page for each segment differently.</p>
<p> </p>
<p> </p>
<p>#1 - I would create a special webcontent template and map it to a place on the page. In the template I would either use serviceLocator + assetEntryLocalService or a helper in the form of a template context contributor to fetch a list of items and display them. I am not sure, why I should use an InfoListProvider here? Except for the "template inflation", the need to create many templates for the same structure, I have already mentioned in a previous test of the mapping feature.</p>
<p>#2 Basically I would use the same solution idea. But instead of using title/h1/h2 I would use the webcontent title or something to do the search.</p>
<p>My main issue here is that it is currently awfully inconvenient to reuse content in content. It is actually rather complicated to fetch the categories/tags/... in a Webcontent. Oh, I can do it, I have a ton of example code and helper functions available. But for most people, it is hard.</p>
<p> </p>
<p>#3 I am not sure why this is needed? I mean, I can already create an asset collection for a segment. So, I would just need to create one list with whatever categories/tags I see fit. Or even simpler, I could configure the asset publisher on the page for each segment differently.</p>
<p> </p>
<p> </p>
Hey Christoph,
Using a template and the serviceLocator is a valid solution too.
The ultimate benefit of using a Collection Provider is to decouple the retrieval of information from its display. In 7.2 this benefit is still not very easy to leverage, but it will be larger in 7.3. In particular, 7.3GA3 already introduced a new way of display collections (the Collection Display fragment) which provides a lot of flexibility in deciding how each item will be displayed (leveraging other fragments and mapping). In this release it's still limited to a few content types (web content, blog entries and documents) but in GA4 it will support any type of entity (provided that the developers provide an implementation of an interface).
Ultimate, what we want to do is to simplify the creation of solutions on top of Liferay that retrieve, handle and display information, by facilitating the reuse of existing components and reducing the amount of code (and time) necessary. This, of course, builds on the infrastructure that Liferay has had for a long time including web content, templates, etc, and adds additional capabilities to empower not only developers but also non-technical users.
Using a template and the serviceLocator is a valid solution too.
The ultimate benefit of using a Collection Provider is to decouple the retrieval of information from its display. In 7.2 this benefit is still not very easy to leverage, but it will be larger in 7.3. In particular, 7.3GA3 already introduced a new way of display collections (the Collection Display fragment) which provides a lot of flexibility in deciding how each item will be displayed (leveraging other fragments and mapping). In this release it's still limited to a few content types (web content, blog entries and documents) but in GA4 it will support any type of entity (provided that the developers provide an implementation of an interface).
Ultimate, what we want to do is to simplify the creation of solutions on top of Liferay that retrieve, handle and display information, by facilitating the reuse of existing components and reducing the amount of code (and time) necessary. This, of course, builds on the infrastructure that Liferay has had for a long time including web content, templates, etc, and adds additional capabilities to empower not only developers but also non-technical users.
Please don't get me wrong, I can see the merits of that feature in general. Asset Publisher is great, but it has several limitations. e.g. we needed to display next three Events (in our case just webcontent) in the future, News per Month/Year, ... and so on. Using Asset Publisher with a custom "entry search backend" would have been quite useful.
I just don't see it in this case since the configuration has to be "dynamic". It isn't a fixed list, but a list depending on another content. Btw.: the requested features would be quite useful, I have created similar things for my customers already. I believe it would be quite useful to have an easy way to access the context information (e.g. which webcontent is mapped to the display page) in a fragment. Maybe it is already there, but it would be useful.
And I didn't realize that GA3 was already released, I will certainly try that Collection Display fragment. Quite interesting.
I just don't see it in this case since the configuration has to be "dynamic". It isn't a fixed list, but a list depending on another content. Btw.: the requested features would be quite useful, I have created similar things for my customers already. I believe it would be quite useful to have an easy way to access the context information (e.g. which webcontent is mapped to the display page) in a fragment. Maybe it is already there, but it would be useful.
And I didn't realize that GA3 was already released, I will certainly try that Collection Display fragment. Quite interesting.
One of the ideas that we have in mind is to allow each Collection Provider implementation to define its own configuration. The way it would work is that once the user has selected an specific provider, then the configuration options associated to that provider would be shown. I'm not sure if we'll be able to do this in the 7.3 cycle, but I would love it. You can keep track of the progress of this idea here: https://issues.liferay.com/browse/LPS-114236
Christoph, the point is exactly that: when the configuration for the asset publisher has to be dynamic, you can easily do it with specialized CollectionProviders.
Jorge, my suggestion is precisely that you could provide some additional CollectionProviders OOTB. ;-) I understand your objections to #2 but the main point is that we could offer more OOTB value from elastic search and a good recommendation mechanism would be great.
My 3rd suggestion comes from the need to combine several user segments into a page experience. If we only have 3 segments, we can create an experience for each of the 9 segment combinations an user can belong to. But if you have more than 3 segments it becomes a nightmare. Hence the suggestion of attaching tags or categories to segments and allow a specialized CollectionProvider search assets on the fly for the combination of all the user segments.
HTH
Fernando
Jorge, my suggestion is precisely that you could provide some additional CollectionProviders OOTB. ;-) I understand your objections to #2 but the main point is that we could offer more OOTB value from elastic search and a good recommendation mechanism would be great.
My 3rd suggestion comes from the need to combine several user segments into a page experience. If we only have 3 segments, we can create an experience for each of the 9 segment combinations an user can belong to. But if you have more than 3 segments it becomes a nightmare. Hence the suggestion of attaching tags or categories to segments and allow a specialized CollectionProvider search assets on the fly for the combination of all the user segments.
HTH
Fernando
Sure, you can. I am just doubting that it is "less effort" than other solutions. But I will have to look into GA3, how it is done there, maybe I am thinking "too 7.0" here. ;)
I agree with you that the segment mapping is a bit unflexible, since essentially only one experience will be used on a page. But maybe the solution shouldn't be the ability to categorize segments but to add attributes to them. And these attributes should then be available in the form of a context to the page and it's modules.
Once upon a time I was working with Sun Portal Server. In general it wasn't really an impressive toy, but it had a really nice mechanism of xml inheritance. A page was defined by an xml. A role also could contain an xml. The role xmls were merged (with a priority defined in the xml) with page xml and the result defined the page. So, a role could change all configuration options on a page.
I am not saying that this should be implemented, but that approach had some merits and was for most usecases quite flexible.
I agree with you that the segment mapping is a bit unflexible, since essentially only one experience will be used on a page. But maybe the solution shouldn't be the ability to categorize segments but to add attributes to them. And these attributes should then be available in the form of a context to the page and it's modules.
Once upon a time I was working with Sun Portal Server. In general it wasn't really an impressive toy, but it had a really nice mechanism of xml inheritance. A page was defined by an xml. A role also could contain an xml. The role xmls were merged (with a priority defined in the xml) with page xml and the result defined the page. So, a role could change all configuration options on a page.
I am not saying that this should be implemented, but that approach had some merits and was for most usecases quite flexible.
Hey Fernando,
Understood. Would you mind creating a Feature Request in issues.liferay.com for each of the Collection Providers that you believe it would make sense to be provided out of the box with Liferay?
That way we can discuss each of them and measure interest. Please provide as many details and you believe could be useful on the type of needs that each provider would help solve.
Thanks in advance
Understood. Would you mind creating a Feature Request in issues.liferay.com for each of the Collection Providers that you believe it would make sense to be provided out of the box with Liferay?
That way we can discuss each of them and measure interest. Please provide as many details and you believe could be useful on the type of needs that each provider would help solve.
Thanks in advance
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™