portlet framework: the liferay way

Riccardo Rotondo

Tutorial on Science Gateways, Roma, 04.06.2013

Portlet Framework: the Liferay wayLiferay Service Builder, Portlet MVC

Riccardo RotondoTutorial on Science Gateways, Roma, 04.06.2013

Outline

Motivations Model View Controller design pattern Liferay Service Builder

Riccardo Rotondo

Portlet Framework

GenericPortlet class is not the only way of developing portlet.

Several framework are nowadays available to develop portlet: Struts JavaServer Faces Spring


Riccardo Rotondo

Liferay MVCPortlet

Make use of a subset of the classical MVC Framework

Easier to use Faster learning curve Less configuration files to deal with and

to synchronize with java sources MVC: Model View Controller paradigm

helps keeping the code tidy


Riccardo Rotondo

Model View Controller


Controller

View Model

Model: layer responsible to hold the data and the business logic to manipulate them. In case you use Liferay Service Builder to manage your data, it works at the model layer level.

View: layer containing the rules to display data to the users (typically the JSP pages)

Controller: layer behaving as traffic director. Determine which action will be executed according users input. Model and View layer shouldn’t communicate each other but interact with the controller

Riccardo Rotondo

Difference from the GenericPortlet

Unnecessary implementation of doView() and doEdit() and any others porlet API

Class is simpler, it contains just the action methods

In case you really want to use any portlet API they are available, MVCPorlet is a subclass of the GenericPortlet class


Riccardo Rotondo

Portlet accessing data

Several reasons to use a database behind a portlet

Java Programming offers different approach to deal with data

Object-relation mapping framework allow database access in a robust way. Java offers Persistence API (JPA) for database access

Liferay uses Hibernate to manage all its data


Riccardo Rotondo

Drawback in Hibernate direct usage

Development of independent portlets using Hibernate/JPA appears to work, but the runtime implications are not immediately recognizable:

• Stale caches because of multiple writers.

• Server resource consumption for multiple DB connections, memory usage for runtime copies of Hib/JPA objects.

• Synchronization issues (two portlets given new Hib/JPA config but one forgotten).

Tutorial on Science Gateways, Roma, 04.06.2013Source:

Riccardo Rotondo

The Service Builder Solution

Service Builder provides a single point to share code (DB access and business logic) to independent portlets, resolving the caching, resource, and synchronization issues.


Riccardo Rotondo

Service Builder Architecture Overview


Riccardo Rotondo

References

Liferay in Action: http://www.manning.com/sezov/ Liferay Service Builder:

http://www.liferay.com/it/community/wiki/-/wiki/Main/Service+Builder

https://www.liferay.com/c/document_library/get_file?p_l_id=8440633&fileEntryId=22887097


http://www.manning.com/sezov/

http://www.manning.com/sezov/







Riccardo Rotondo

Questions ?


portlet framework: the liferay way

Education