This website uses cookies to ensure you get the best experience. Learn More.
Hooks revisited (7) - put the custom finder in place
It remains to show that requirement e) can be met as well. Actually this part is already supported by existing standard development methods. We need to create a Service Hook in our plug-in package. In the liferay-hook.xml file include the override description:
<service>
<service-type>
com.liferay.portlet.asset.service.AssetEntryLocalService
</service-type>
<service-impl>
ch.portalis.service.impl.CustomAssetEntryLocalServiceImpl
</service-impl>
</service>
Subsequently create the custom implementation as follows:
public class CustomAssetEntryLocalServiceImpl
extends AssetEntryLocalServiceWrapper {
public CustomAssetEntryLocalServiceImpl(
AssetEntryLocalService assetEntryLocalService) {
super(assetEntryLocalService);
}
...
@Override
public List<AssetEntry> getEntries(AssetEntryQuery entryQuery)
throws SystemException {
if (entryQuery instanceof CustomAssetEntryQueryWrapper) {
return
CustomAssetEntryQueryFinderUtil.findEntries(
(CustomAssetEntryQueryWrapper) entryQuery);
else {
return super.getEntries(entryQuery);
Now we can use the framework's AssetEntryLocalServiceUtil.getEntries(AssetEntryQuery) method to retrieve the asset entries matching the extended search criteria. If the parameter happens to belong to the custom subclass then the custom search criteria, if any, will be effective.
Ideally we should simply inject the finder class into the above service implementation. Unfortunately this is where the current framework version is painfully restrictive. A bit more flexibility in the AssetEntry interface would help. Well, we might have gone up to the wall this time.