« Back

Hooks revisited (3) - overriding finders in the core

Technical requirements

In order to use custom filters / sorting in the Asset Publisher portlet, we want to override the current finder implementation in a hook. Let's consider, what can be achieved within the scope of the current architecture. Here are the requirements for customization:


  1. The portlet preferences should accommodate additional filtering, sorting and rendering parameters. As an example we will use the parameter “author” that should match the asset's owner.

  2. All custom parameters should be persisted together with the currently available standard parameters. The combination of the parameters "asset type" and "author" will enable that, for example, all wiki articles of an author can be selected.

  3. The complete set of search criteria should be implemented as a new bean class, for example CustomAssetEntryQuery. Ideally this would be an extension of the AssetEntryQuery which currently holds the standard search criteria.

  4. The AssetEntryFinderImpl  class should be extended, for example by CustomAssetEntryFinderImpl, that makes use of the new CustomAssetEntryQuery bean as an argument in its methods.

  5. Finally, the AssetEntryLocalServiceImpl should be extended in such a way that the extended CustomAssetEntryFinderImpl will return the required target list of asset entries.

Changing the view component


The first two requirements can easily be fulfilled. Requirement a) can be achieved by a hook plug-in which replaces some Java Server Pages in /html/portlet/asset_publisher/. For example something like:


<aui:select label="author" name="preferences—authorName--">


<optgroup label="<liferay-ui:message key="author" />"





will need to be added in configuration_dynamic.jspf. This will include a new dropdown list in the preferences form of the portlet. Later we will have to read the extended portlet preferences and instantiate the CustomAssetEntryQuery bean in init.jsp. The rendering will need to be adapted in view_dynamic_list.jspf.


Requirement b) happens to have been already covered by the framework's AssetPublisherUtil class. In the next segment we will focus on the requirement c).