Blogs

Override the AssetEntry implementation

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.