Portlet Framework: the Liferay way


Published on

Published in: Education
  • Be the first to comment

Portlet Framework: the Liferay way

  1. 1. Portlet Framework: the Liferay way Liferay Service Builder, Portlet MVC Catania, 10/03/2014Riccardo Rotondo
  2. 2. Outline  Motivations  ModelView Controller design pattern  Liferay Service Builder 2
  3. 3. Portlet Framework  GenericPortlet class is not the only way of developing portlet.  Several framework are nowadays available to develop portlet:  Struts  JavaServer Faces  Spring 3
  4. 4. 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: ModelView Controller paradigm helps keeping the code tidy 4
  5. 5. Model View Controller Controller View Model 5  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 andView layer shouldn’t communicate each other but interact with the controller
  6. 6. 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 6
  7. 7. 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 7
  8. 8. 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). Source:8
  9. 9. 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. Source:9
  10. 10. Service Builder Architecture Overview Source:10
  11. 11. 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=8440 633&fileEntryId=22887097 11
  12. 12. Questions ? 12