Foren

RE: Asset Publisher improvements

Matteo S, geändert vor 12 Jahren.

Asset Publisher improvements

New Member Beiträge: 7 Beitrittsdatum: 14.04.09 Neueste Beiträge
Hi all.
I've been using Liferay since 4.x versions, and I've found a lot of work has been done to improve Asset Publisher, expecially in 6.x branch.
However, as of 6.2, Asset Publisher still lacks some useful features which can be easily added.

1. Results filtering
As of today, asset publisher can read categoryId or tag from path and then filter result's set. This is limited to a single category/tag, and requires the use of another portlet (categories or tag navigation).
Search portlet instead can provide multiple filters, by using facets.
Same concept (allow user filter results), much better implementation and result.

2. Search backend
Currently, asset publisher relies on service level to search and fetch relevant assets. This means lots of queries and accesses to persistance layer. Combined with permission filtering, this leads to a massive performance drop when used with 1000s of assets.
As someone has already pointed out, search framework is the best candidate for this job.
Asset publisher can easily translate its configuration in a search context, and then fetch its results by invoking a Searcher.

My proposal is to add a new display mode to asset publisher (search?), based on search framework, with facets (static and dynamic filters available).
As side note, look at Ray's post on Faceted Search
http://www.liferay.com/web/raymond.auge/blog/-/blogs/12917352#h.f00vmxvfmnha345
Image Search Example looks a lot like an asset publisher, configured to display images. Main (only?) difference: no "default search with no keywords".

Anyone else thinks this could be useful?

Bottom line: I have already implemented this and can contribute my code (although at "proof-of-concept" stage).
thumbnail
Jorge Ferrer, geändert vor 12 Jahren.

RE: Asset Publisher improvements

Liferay Legend Beiträge: 2871 Beitrittsdatum: 31.08.06 Neueste Beiträge
Hi Matteo,

Thanks for your feedback. I've added some notes below:

Matteo S:

1. Results filtering
As of today, asset publisher can read categoryId or tag from path and then filter result's set. This is limited to a single category/tag, and requires the use of another portlet (categories or tag navigation).
Search portlet instead can provide multiple filters, by using facets.
Same concept (allow user filter results), much better implementation and result.

If I understand properly what you are suggesting is that the asset publisher comes with a menu similar to the left menu in the new faceted search to do further filtering in the set of assets displayed. Is that right?

If so, I had thought about that as well and I think it's a great idea.
Matteo S:

2. Search backend
Currently, asset publisher relies on service level to search and fetch relevant assets. This means lots of queries and accesses to persistance layer. Combined with permission filtering, this leads to a massive performance drop when used with 1000s of assets.
As someone has already pointed out, search framework is the best candidate for this job.
Asset publisher can easily translate its configuration in a search context, and then fetch its results by invoking a Searcher.

My proposal is to add a new display mode to asset publisher (search?), based on search framework, with facets (static and dynamic filters available).
As side note, look at Ray's post on Faceted Search
http://www.liferay.com/web/raymond.auge/blog/-/blogs/12917352#h.f00vmxvfmnha345
Image Search Example looks a lot like an asset publisher, configured to display images. Main (only?) difference: no "default search with no keywords".


Yeah, Ray has been heavily proposing this for a while and we are looking to applying this idea for 6.2.

Matteo S:

Bottom line: I have already implemented this and can contribute my code (although at "proof-of-concept" stage).


That would be awesome. Feel free to send me a pull request. My github name is jorgeferrer. If possible be sure to make your code comply with Liferay's coding guidelines.
Matteo S, geändert vor 12 Jahren.

RE: Asset Publisher improvements

New Member Beiträge: 7 Beitrittsdatum: 14.04.09 Neueste Beiträge
Jorge Ferrer:
Hi Matteo,

Thanks for your feedback. I've added some notes below:

Matteo S:

1. Results filtering

If I understand properly what you are suggesting is that the asset publisher comes with a menu similar to the left menu in the new faceted search to do further filtering in the set of assets displayed. Is that right?

If so, I had thought about that as well and I think it's a great idea.


Yes, exactly. I was also suggesting to use the same code.
Jorge Ferrer:

Matteo S:

2. Search backend


Yeah, Ray has been heavily proposing this for a while and we are looking to applying this idea for 6.2.

Good!

Jorge Ferrer:

Matteo S:

Bottom line: I have already implemented this and can contribute my code (although at "proof-of-concept" stage).


That would be awesome. Feel free to send me a pull request. My github name is jorgeferrer. If possible be sure to make your code comply with Liferay's coding guidelines.



Well, actual code doesn't comply, it's kind of a hack to get the job done..
I've had to patch some jsps and rewrite facet jsps. I can provide my hook, based on 6.1 GA1 codebase. I can also clean up code and provide patch for current trunk, but I've got some issues to solve before.

http://issues.liferay.com/browse/LPS-28228
I need to obtain an "AND" query with facet values, which ain't possible with current implementation.

http://issues.liferay.com/browse/LPS-28378
To be able to provide the same level of functionality as today, while adding dynamic filtering, I need to merge static values with dynamic ones in facet's code.

I've patched MultiValueFacet, but I think writing a new Facet would be better. I don't really know where and how actual code is used, I am just speculating.

Another observation: search portlet should provide the same functionality (drilled down search). I simply ported my patched facets to search portlet (via hook).

Thanks for your response Jorge.