Overloading web content Portlet in Liferay

Question

In Liferay, when you add a web content to a page, a Portlet is created and you can choose the web content that will be displayed (when logged as admin), and you can choose some parameters (rights to view the content, share...). I would like to create a Portlet that overloads this Portlet, to allow the admin to choose his / her web content with custom parameters.

Does anyone know how this could be done ? Thanks !

Answer 1

1. First idea which came to my mind is to hook default Web Content Display Portlet This would allow you to add some custom business logic to this portlet and not need to implement all you already get from original one. Still this will much depends on how much your new features you want to add, are complex.

   As you have said, you are beginner, so here are some hints, how to start up with hook creation:

   • Visit https://www.liferay.com/documentation/liferay-portal/6.1/development/-/ai/liferay-plugin-types-to-develop-with-maven section Developing Liferay Hook Plugins with Maven This archetype will create for you default structure of hook plugin.
   • Next step, is to download your liferay sources (if you haven't already) Visit official site https://www.liferay.com/downloads/liferay-portal/available-releases
   • Now when you have your sources, get these .jsp files which you want to modify, and copy to your hook. Make sure to keep folder structure as in default one.
   • Add your custom logic, in specified place and after deploying, test it.
   • Good luck

2. Another idea is to use maven war overlay which you can read about more under http://java.dzone.com/articles/mavens-war-overlay-what-are

Answer 2

As you say you're a beginner, I'd suggest to create your own portlet that is independent of Liferay's portlets. You can use Liferay's API to get the article you'd like and its content, while implementing your own functionality to filter out the content you like.

The reason I'm suggesting a custom portlet is: Liferay's portlets must be as generic as possible, to match as many usecases as possible. Thus there are lots of conditionals that you won't need (and won't need to understand) in the implementation. If you have some narrow non-generic requirements to have an alternative behavior, you're easier off implementing exactly those requirements rather than adding to the generic, highly conditional UI. Plus, you might want to keep the original UI for other purposes. If you make a mistake in your own implementation, the original Web Content Display Portlet would still continue to work.

That being said, you might also look at the AssetPublisher portlet. It's the swiss army knife of content management and might already do what you want (and a lot more). This takes criteria and will evaluate them at runtime, displaying matching articles (or other content types).