« Back

Hooks revisited (2) - extending the AssetPublisher preferences

Technical Blogs April 28, 2014 By Peter Breuer

The AssetEntryQuery class

Note: please find an UML class diagram of the referenced classes in the DL.

 

The Asset Publisher portlet is used for rendering blog entries, wiki pages, web articles, and all kinds of other assets stored in the portal framework. It can be customized in order to render only a subset of assets in a given sort order. That part of the portlet preferences are represented by the AssetEntryQuery bean that can be regarded as a model implementation class. Its members hold standard filter and sort criteria that are eventually transformed into SQL WHERE conditions and a list of ORDER BY columns. The AssetEntryQuery bean itself is never persisted. Its primary use is as follows:

 

public interface AssetEntryFinder

public List<AssetEntry>

findEntries(AssetEntryQuery entryQuery)

throws SystemException;

}

 

The method above is implemented in the AssetEntryFinderImpl service bean. It will be located by the generic bean lookup service and called within the AssetEntryLocalServiceImpl class. In particular, the list of filtered and sorted asset entries are returned by the method

 

public List<AssetEntry> getEntries(AssetEntryQuery entryQuery)

 

Now suppose that we want to render only web articles authored by a specific user. In the current architecture this is only feasible if the argument AssetEntryQuery included “author” among the search criteria. Unfortunately that is not the case and we are reluctant to make use of an Ext plug-in.

 

It might be interesting to mention that the portal version 6.0 used to include some 20 members holding search criteria in the AssetEntryQuery class. Later it was increased to 25 members in the version 6.1, and over 30 members in the version 6.2. Apparently each new release requires to cover an increasing number of search criteria. All those criteria member definitions seem to be reasonable, yet, to a great deal, they are also arbitrary. Apparently, a more generic approach would be beneficial.

 

Let me briefly wrap up, what is the issue here:

  • Assets' meta-data can be extended in different ways, e.g. by Expando Bridge, or Article Structure. The extension is fully supported by the architecture and the core technology.

  • The Asset Publisher portlet preferences covers only a limited choice of asset meta-data for filtering and sorting. Custom extensions are currently not supported in a Hook plug-in.

  • There is a gap between the availability and the usability of assets' meta-data.

How can we attempt to fill the gap? Please read further.

 

No comments yet. Be the first.