Blogs

If you are a portlet developer you have many options how to develop the portlets. There are many framework that make your everyday struggle easier. In this blog post I would like to talk about one of these frameworks - Liferay MVCPortlet.

Liferay MVCPortlet is quite useful tool for developing portlets. It is much simpler then frameworks like Spring MVC or JSF but sometime these frameworks are just too big for the job at hands. MVCPortlet is a portlet framework only and offers many conventions that simplify portlet development and make your code nice and short.

Despite all the goodies it is offering, I have one issue with it - the claim that it is a MVC. I would rather call it a VA (View-Action) framework. Why? Because the main components it is build from are the JSP files - the View layer and the portlet class that is optional and the framework mainly uses it for processing of actions.

This behaviour has its roots in Liferay functionality. If you are familiar with core Liferay functionality and Struts, you know, that all portlet render stuff is handled by the JSP files and if a portlet action is invoked a struts action class is called. In this case we mix view and model/business logic calls and have a week controller. This exact behaviour was transferred onto MVCPortlet.

This approach has its benefits and as Liferay developer we leverage on them every time when we create a JSP hook but for custom portlets a clean MVC approach may be more beneficial.

So I dedicated a free weekend to this and an Improved MVCPortlet lib came to life :). This small library extends Liferay MVCPortlet with the intention to provide a cleaner MVC framework. It keeps all the good features present in MVCPortlet and strengthens the position of the controller as the only point of interaction with business logic. This leads to a clean separation between View and Controller.

• The call of render phase was extended to call a setModel method. This method is used to populate the model that is then forwarded to view.
• User can define oven "setModel" method for different view. The methods are called as custom action method in original MVCPortlet
• The past values are stored as request attributes so EL expression can be easily used.
• Serve resource method may be called the same way as custom action methods in original MVCPortlet. The method name must be the same as the resourceId

The code of the library can be found on my github and there is also an example portlet that uses this lib.

Let me know what you think about this. I am also looking for suggestions on possible improvements. So comment or send pull requests. My goal here is to improve it and get as much as possible from it into Liferay core.