As the world's leading open source portal platform, Liferay is the market's leading provider of open source portal, web publishing, content, social and collaboration enterprise solutions, providing a unified web interface to data and tools scattered across many sources. Within Liferay, a portal is composed of a number of portlets, which are self-contained interactive elements that are written to a particular standard. Dynamic, content-rich, social systems could be built quickly and easily on top of Liferay Portal.
Liferay was created in 2000 to provide an enterprise portal solution for non-profit organizations. In 2004, the company was incorporated under the name Liferay. In 2011/2012, Liferay was going to bring several enhancements and new features such as an improved document library (renamed as document and media library), Dynamic Data Lists (DDL), Dynamic Data Mapping (DDM), setup wizard, mobile device enhancements, multiple repository mounting and apps store (called marketplace).
This book will show you how to develop and/or customize portal systems with Liferay Portal. In this chapter, we will look at:
The features that Liferay Portal has
Why Liferay Portal is an excellent choice for building custom systems
The Liferay Portal framework and architecture for customization
What portal development strategies are and how they work
Finding more technical information about what Liferay is and how it works
So let's begin by looking at exactly what Liferay Portal is and how to customize it.
Liferay currently has the following four main functionalities:
Liferay CMS and WCM— JSR-170 content management system and web content management
Liferay social collaboration— Collaboration software such as blogs, calendar, web mail, message boards, polls, RSS feeds, Wiki, presence (AJAX chat client, dynamic friend list, activity wall, and activity tracker), alert and announcement, asset links, asset tagging and classification, social equity, social activities, OpenSocial, and more
Liferay social office— A social collaboration on top of the portal; a dynamic team workspace solution all you have to do is log in and work the way you want to, at your convenience
Generally speaking, a website built by Liferay might consist of a portal, CMS and WCM, collaboration, and/or social office.
Document and Media Library is a useful tool to manage any media such as basic documents, images, records, videos, and audios with built-in features, for example, dynamic data list, dynamic data mapping, dynamic document type and metadata runtime creation, authoring, versioning, imaging, check-in / check-out, archiving, access control, and indexing. In particular, multiple repositories are supported as well as CMIS. For example, in the document and media library, you can add document types and metadata sets as well as folders and subfolders to manage and publish documents. The document and media library make up the Content Management Systems (CMS) available to power both intranets and extranets. The CMS is equipped with customizable document types and folders, and acts as a web-based shared drive for all your team members, no matter where they are. As content is accessible only to those authorized by administrators, each individual file is as open or as secure as you need it to be.
Your company may have a lot of HTML text, audio, videos, images, records, and documents using different structures and templates, and you may need to manage all of these as well. Therefore, you require the ability to manage a lot of web content, and then publish that web content to intranets or Internets.
We will see how to manage and publish web content within Liferay. Liferay Journal (renamed as Web Content) not only provides the ability to publish, manage, and maintain web content and documents, but it also separates content from layout. WCM allows us to create, edit, and publish web content (formerly called Journal articles) as well as article templates for one-click changes in layout. It has built-in workflow, article versioning, search and metadata.
The portal also provides dynamic data lists (DDL) and dynamic data mapping (DDM). Through DDL and DDM, we can define web forms, document types, metadata sets, and columns of various input styles, such as free form, drop-down lists, combo boxes, date, number, text, and pre-defined list values such as lists of users, order types, inventory types, and more.
All users get a personal space that can be either made public (published as a website with a unique, friendly URL) or kept private. In fact, users can have both private and public pages at the same time. You can also customize how the space looks, what tools and applications are included, what goes into the document and media library, and who can view and access any of this content.
In addition, you can use your own language. Multilingual organizations get out-of-the-box support for up to 42 languages (such as Hindi, Hebrew, Ukrainian, and Romanian), and new languages can be added easily within the portal framework. Users can toggle between different language settings with just one click and produce/publish multilingual documents and web content. You can also easily add other languages in your public pages, private pages, or other organizations.
You can use workflows to manage definitions, instances, and tasks. There are many workflow engines such as jBPM workflow, Kaleo workflow, Activiti BPM, and Intalio | BPMS, and all of these can be integrated easily with Liferay. And then, with a workflow engine as the backend, a portal user can add workflow functionality to any activity such as CMS content approval and the like. In addition, Liferay Portal allows you to define publishing workflows that track changes to web content as well as the pages of the site in which they live.
Staging is a major feature of Liferay Portal. The staging environment allows us to make changes to the site in a specialized staging area, and then publish the whole site to Live when you are done, either locally or remotely. Scheduling is another major feature of Liferay Portal, using a built-in Quartz job scheduling engine. Before going live, you are able to schedule events to publish selected pages with all included content.
The Site snapshot feature means that branching and versioning of staged layouts are supported as well. Thus at the end of a workflow, you would be able to keep the current version of the layout as history; this is done in case the users want to use an old version of the layout at a later time.
Liferay Portal supports social network— you can easily connect your accounts in Liferay with Facebook, MySpace, Google+, Twitter, and more. Of course, you can also manage your instant messenger accounts in Liferay Portal, such as AIM, ICQ, Jabber, MSN, Skype, and YM. In addition, you are able to track social activities and social equity as well.
Social office gives us social collaboration on top of the portal a full virtual workspace that streamlines communication and builds up group cohesion. All components in social office are tied together seamlessly, getting everyone on the same page by sharing the same look-and-feel. More importantly, the dynamic activity tracking gives us a bird's-eye view of who has been doing what and when within each individual site.
The portal provides abilities to monitor portlets and portal transactions. This includes— but is not limited to— average transaction time per portlet for each phase of the portlet life cycle, minimum and maximum transaction time for each portlet transaction, average time for portal requests (inclusive of all portlets), and minimum and maximum time for each portal request. By the way, statistics are exposed using JMX MBeans.
An audit trail of user actions is required by many organizations. Fortunately, the portal provides audit service, which is a method for storing the audit trail from the portal and plugins. Then the information processed by the audit service plugin can be stored in a log file or database. Note that audit services employ Liferay Lightweight Message Bus and Plugin architecture. The audit service itself is a plugin, handling the processing and logging of the audit messages sent through the Message Bus. Therefore, any plugin can produce audit messages to the audit Message Bus destination.
The Liferay JasperReports Report Engine provides an implementation of Liferay BI using Jasper. JasperReports is an open source Java reporting tool that can write to screen, a printer, or to PDF, HTML, Microsoft Excel, RTF, ODT, CSV (Comma Separated Value) formats, and XML files. The portal provides full integration of JasperReports with its reporting framework. The portal provides the ability to schedule reports and deliver them using document and media library and e-mail. In addition, the portal supports Jasper XLS data sources in its reporting framework.
The portal tagging system allows us to tag web content, documents, message board threads, and more, as well as to dynamically publish assets by tags. Tags provide a way of organizing and aggregating content. Folksonomies are a user-driven approach to organizing content through tags, cooperative classification, and communication through shared metadata. The portal implements folksonomies through tags. Taxonomies are a hierarchical structure used in scientific classification schemes. The portal implements taxonomies as vocabularies and categories, which includes category hierarchy, in order to tag contents and classify them.
In particular, the portal provides a framework so that you can integrate external applications easily. For example, you could integrate external applications such as Alfresco, Documentum, SharePoint, OpenX, LDAP, SSO CAS, Facebook, NTLM, OpenSSO, SiteMinder, SAML 2.0, Orbeon Forms, KonaKart, PayPal, Solr, Coveo, Salesforce.com, SugarCRM, JasperForge, Drools, jBPM, and more. With the portal, integrating standalone Java web applications into the portal is not an easy task. However, Liferay makes it possible to achieve near-native integration with minimal effort using the WAI (Web Application Integrator) portlet or the IFrame portlet.
In addition, the portal uses the OSGi framework, that is, the portal supports a module system and service platform for the Java programming language that implements a complete and dynamic component model. Please refer to http://www.osgi.org for more information.
In a word, the portal offers compelling benefits to today's enterprises— reduced operational costs, improved customer satisfaction, and streamlined business processes.
Liferay currently has the following four main functionalities:
Liferay CMS and WCM— JSR-170 content management system and web content management
Liferay social collaboration— Collaboration software such as blogs, calendar, web mail, message boards, polls, RSS feeds, Wiki, presence (AJAX chat client, dynamic friend list, activity wall, and activity tracker), alert and announcement, asset links, asset tagging and classification, social equity, social activities, OpenSocial, and more
Liferay social office— A social collaboration on top of the portal; a dynamic team workspace solution all you have to do is log in and work the way you want to, at your convenience
Generally speaking, a website built by Liferay might consist of a portal, CMS and WCM, collaboration, and/or social office.
Document and Media Library is a useful tool to manage any media such as basic documents, images, records, videos, and audios with built-in features, for example, dynamic data list, dynamic data mapping, dynamic document type and metadata runtime creation, authoring, versioning, imaging, check-in / check-out, archiving, access control, and indexing. In particular, multiple repositories are supported as well as CMIS. For example, in the document and media library, you can add document types and metadata sets as well as folders and subfolders to manage and publish documents. The document and media library make up the Content Management Systems (CMS) available to power both intranets and extranets. The CMS is equipped with customizable document types and folders, and acts as a web-based shared drive for all your team members, no matter where they are. As content is accessible only to those authorized by administrators, each individual file is as open or as secure as you need it to be.
Your company may have a lot of HTML text, audio, videos, images, records, and documents using different structures and templates, and you may need to manage all of these as well. Therefore, you require the ability to manage a lot of web content, and then publish that web content to intranets or Internets.
We will see how to manage and publish web content within Liferay. Liferay Journal (renamed as Web Content) not only provides the ability to publish, manage, and maintain web content and documents, but it also separates content from layout. WCM allows us to create, edit, and publish web content (formerly called Journal articles) as well as article templates for one-click changes in layout. It has built-in workflow, article versioning, search and metadata.
The portal also provides dynamic data lists (DDL) and dynamic data mapping (DDM). Through DDL and DDM, we can define web forms, document types, metadata sets, and columns of various input styles, such as free form, drop-down lists, combo boxes, date, number, text, and pre-defined list values such as lists of users, order types, inventory types, and more.
All users get a personal space that can be either made public (published as a website with a unique, friendly URL) or kept private. In fact, users can have both private and public pages at the same time. You can also customize how the space looks, what tools and applications are included, what goes into the document and media library, and who can view and access any of this content.
In addition, you can use your own language. Multilingual organizations get out-of-the-box support for up to 42 languages (such as Hindi, Hebrew, Ukrainian, and Romanian), and new languages can be added easily within the portal framework. Users can toggle between different language settings with just one click and produce/publish multilingual documents and web content. You can also easily add other languages in your public pages, private pages, or other organizations.
You can use workflows to manage definitions, instances, and tasks. There are many workflow engines such as jBPM workflow, Kaleo workflow, Activiti BPM, and Intalio | BPMS, and all of these can be integrated easily with Liferay. And then, with a workflow engine as the backend, a portal user can add workflow functionality to any activity such as CMS content approval and the like. In addition, Liferay Portal allows you to define publishing workflows that track changes to web content as well as the pages of the site in which they live.
Staging is a major feature of Liferay Portal. The staging environment allows us to make changes to the site in a specialized staging area, and then publish the whole site to Live when you are done, either locally or remotely. Scheduling is another major feature of Liferay Portal, using a built-in Quartz job scheduling engine. Before going live, you are able to schedule events to publish selected pages with all included content.
The Site snapshot feature means that branching and versioning of staged layouts are supported as well. Thus at the end of a workflow, you would be able to keep the current version of the layout as history; this is done in case the users want to use an old version of the layout at a later time.
Liferay Portal supports social network— you can easily connect your accounts in Liferay with Facebook, MySpace, Google+, Twitter, and more. Of course, you can also manage your instant messenger accounts in Liferay Portal, such as AIM, ICQ, Jabber, MSN, Skype, and YM. In addition, you are able to track social activities and social equity as well.
Social office gives us social collaboration on top of the portal a full virtual workspace that streamlines communication and builds up group cohesion. All components in social office are tied together seamlessly, getting everyone on the same page by sharing the same look-and-feel. More importantly, the dynamic activity tracking gives us a bird's-eye view of who has been doing what and when within each individual site.
The portal provides abilities to monitor portlets and portal transactions. This includes— but is not limited to— average transaction time per portlet for each phase of the portlet life cycle, minimum and maximum transaction time for each portlet transaction, average time for portal requests (inclusive of all portlets), and minimum and maximum time for each portal request. By the way, statistics are exposed using JMX MBeans.
An audit trail of user actions is required by many organizations. Fortunately, the portal provides audit service, which is a method for storing the audit trail from the portal and plugins. Then the information processed by the audit service plugin can be stored in a log file or database. Note that audit services employ Liferay Lightweight Message Bus and Plugin architecture. The audit service itself is a plugin, handling the processing and logging of the audit messages sent through the Message Bus. Therefore, any plugin can produce audit messages to the audit Message Bus destination.
The Liferay JasperReports Report Engine provides an implementation of Liferay BI using Jasper. JasperReports is an open source Java reporting tool that can write to screen, a printer, or to PDF, HTML, Microsoft Excel, RTF, ODT, CSV (Comma Separated Value) formats, and XML files. The portal provides full integration of JasperReports with its reporting framework. The portal provides the ability to schedule reports and deliver them using document and media library and e-mail. In addition, the portal supports Jasper XLS data sources in its reporting framework.
The portal tagging system allows us to tag web content, documents, message board threads, and more, as well as to dynamically publish assets by tags. Tags provide a way of organizing and aggregating content. Folksonomies are a user-driven approach to organizing content through tags, cooperative classification, and communication through shared metadata. The portal implements folksonomies through tags. Taxonomies are a hierarchical structure used in scientific classification schemes. The portal implements taxonomies as vocabularies and categories, which includes category hierarchy, in order to tag contents and classify them.
In particular, the portal provides a framework so that you can integrate external applications easily. For example, you could integrate external applications such as Alfresco, Documentum, SharePoint, OpenX, LDAP, SSO CAS, Facebook, NTLM, OpenSSO, SiteMinder, SAML 2.0, Orbeon Forms, KonaKart, PayPal, Solr, Coveo, Salesforce.com, SugarCRM, JasperForge, Drools, jBPM, and more. With the portal, integrating standalone Java web applications into the portal is not an easy task. However, Liferay makes it possible to achieve near-native integration with minimal effort using the WAI (Web Application Integrator) portlet or the IFrame portlet.
In addition, the portal uses the OSGi framework, that is, the portal supports a module system and service platform for the Java programming language that implements a complete and dynamic component model. Please refer to http://www.osgi.org for more information.
In a word, the portal offers compelling benefits to today's enterprises— reduced operational costs, improved customer satisfaction, and streamlined business processes.
Liferay Portal architecture supports high availability for mission-critical applications using clustering, as well as fully-distributed cache and replication support across multiple servers.
The following diagram depicts various architectural layers and portlet functionality:
 |
Liferay Portal uses Service Oriented Architecture (SOA) design principles throughout, and provides the tools and framework to extend the SOA to other enterprise applications. Under the Liferay enterprise architecture, not only can the users access the portal from traditional and/or wireless devices, but the developers can also access it from the exposed APIs using REST, SOAP, RMI, XML-RPC, XML, JSON, Hessian, Burlap, and custom-tunnel classes.
In addition, Liferay Portal is designed to deploy portlets that adhere to the portlet API, which is compliant with both JSR-168 and JSR-286. A set of useful portlets built on top of Struts 1.2.9 are bundled with the portal, such as document and media library, calendar, message boards, blogs, wikis, and so on. They can be used as examples for adding custom portlets.
The Enterprise Service Bus (ESB) is a central connection manager that allows applications and services to be added quickly to an enterprise infrastructure. When an application needs to be replaced, it can be easily disconnected from the bus at a single point. Liferay Portal can use either Mule or ServiceMix as the ESB.
Through the ESB, the portal can integrate with SharePoint, BPM (such as jBPM workflow engine, Intalio | BPMS engine), a rule engine (Drools), BI Xforms reporting, JCR repository, and so on. It adds another layer like JSR-170, where the repository can be abstracted. Furthermore, it supports events' system with asynchronous messaging and Lightweight Message Bus.
Liferay Portal uses Spring framework for its business and data services layers. It also uses Spring framework for its transaction management. Based on service interfaces (Spring framework), portal-implementation (portal-impl) is implemented and exposed only for internal use — for example, they are used for the extension environment or Ext plugins. Both portal-kernel and portal-service (these two packages are merged into one known as portal-service) are provided for both external and internal use — for example, they are used for the Plugins SDK environment. Custom portlets, both JSR-168 and JSR-286, and web services can be built based on portal-kernel and portal-service.
In addition, the Web 2.0 Mail portlet and Chat portlet are supported. More interestingly, scheduled staging and remote staging and publishing serve as a foundation via tunnel web for web content management and publishing.
Liferay Portal supports web services to make it easy for different applications in an enterprise to communicate with each other. Java, .NET, and proprietary applications can work together easily because its web services use XML standards. It also supports REST-style JSON web services for lightweight, maintainable code, and it also supports AJAX-based user interfaces.
Liferay Portal uses industry-standard, government-grade encryption technologies, including advanced algorithms such as DES, MD5, and RSA. Liferay was benchmarked as one of the most secure portal platforms using LogicLibrary's Logiscan suite. Liferay offers customizable single sign-on with Yale CAS, JAAS, LDAP, NTLM, Netegrity, Microsoft Exchange, Facebook, and more. Open ID, OpenAuth, Yale CAS, Facebook, Siteminder, and OpenSSO (renamed as OpenAM) integration are offered by the portal out-of-the-box.
In short, Liferay Portal uses the ESB in order to provide an abstraction layer on top of an implementation of an enterprise messaging system. It allows integration architects to exploit the value of messaging without having to write the code. As you can see, understanding the framework and architecture will be helpful if you want to customize the portal correctly.
Liferay Portal runs on existing application servers, databases, and operating systems to eliminate new expenses on infrastructure. Moreover, Liferay Portal is built based around common standards. This is a more technical benefit, however, a very useful one if you ever want to use Liferay in a more specialized way.
Liferay is developed based on standard technologies that are popular with developers and other IT experts. Liferay is standards compliant, namely, open standards for content, portlets, web services, and frontend technologies to reduce development cost. The main features are listed as follows:
Built using Java: Java is a very popular programming language that can run on just about any computer. There are millions of Java programmers in the world, so it won't be too hard to find developers who can customize Liferay.
Based on tried and tested components: With any tool, there's a danger of bugs. Liferay uses lots of well known, widely-tested components to minimize the likelihood of bugs creeping in. If you are interested, these are some of the well known components and technologies Liferay uses—Apache ServiceMix, Mule, ehcache, Hibernate, ICEfaces, Java J2EE/JEE, jBPM, Intalio | BPMS, JGroups, Alloy UI, Lucene, and Solr, Seam, Spring and AOP, Struts and Tiles, Tapestry, Vaadin, Velocity, and FreeMarker. Especially, Liferay runs PHP, Ruby, Python, Grails and other lightweight scripting technologies within a robust Java framework.
Uses standard methods to communicate with other software: There are various standards established for sharing data between pieces of software. Liferay uses these so that you can easily get information from Liferay into other systems. The standards implemented by Liferay include AJAX, iCalendar, Microformat, JSR-168, JSR-127, JSR-170, JSR-286 (Portlet 2.0), and JSR-314 (JSF 2.0), OpenSearch, Open platform with support for web services (including JSON, Hessian, Burlap, REST, RMI, and WSRP), WebDAV, and CalDAV.
Makes publication and collaboration tools WCAG 2.0 (Web Content Accessibility Guidelines) compliant: This is the new W3C recommendation to make web content accessible to a wide range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity, and combinations of these. For example, the portal is integrated with CKEditor, which supports standards W3C (WAI-AA and WCAG), 508 (Section 508).
Supports HTML 5, CSS 3, and YUI 3 (Yahoo! User Interface Library).
Supports Apache Ant 1.8 and Maven 2: Liferay Portal could be run through Apache Ant by default, where you can build services, clean, compile, build JavaScript CMD, build language native to ASCII, deploy, fast deploy, and support most application servers such as Tomcat, JBoss, Websphere, Weblogic, and so on. Moreover, Liferay supports Maven 2 SDK, providing Community Edition (CE) releases through public Maven repositories as well as allowing Enterprise Edition (EE) customers to install Maven artifacts in their local Maven repository.
Many of these standards are things that you will never need to know much about, so don't worry if you've never heard of them. Liferay is better for using them, but mostly, you won't even know they are there.
Earlier, we have addressed many terminologies regarding Liferay Portal. So here we're going to introduce a pattern: Portal-Group-Page-Content (PGPC). As you would expect, we are trying to summarize the main features and behaviors of the portal in a simple pattern.
First of all, let's examine a high-level overview of terminologies, scope and hierarchy in the portal. As shown in the following diagram, the portal is implemented by Portal Instances. The portal can manage multiple portal instances in one installation. Of course, you can also install multiple portal instances in multiple installations, separately.
 |
Each portal instance can have many groups, which are implemented as organizations, communities, user groups, and users. Note that each user can be represented as a group by itself, since if a user is a power user, they will get public pages and private page as any group does. Here we can use the term Group Instance to present organizations, locations, communities, user groups, and users (there is only one user in a group). Each portal instance has complete isolation of the users, organizations, locations, and user groups. In particular, organizations have a hierarchical, for example, parent organization, child organizations, and location. Note that one page can have only one parent organization and many child organizations.
Each group has two sets of pages (that is, public pages and private pages, called layout-set); each page is implemented as a layout. Most interestingly, there is a hierarchy in layouts too, such as parent pages and child pages. Note that a page can have one and only one parent page and many child pages.
Each page may contain different content, which would be implemented as portlets. Thus the content will have different scopes. For example, the content would be scoped into page, group, portal instance and portal. This pattern is known as Portal-Group-Page-Content. We will address these terminologies, scope and hierarchy in detail in the coming sections and chapters.
Liferay Portal allows us to run more than one portal instance on a single installation. Data used for each portal instance is maintained separately from every other portal instance. Portal data, however, can be kept either in the same database or in different databases. This is called database sharding.
This feature should be useful for Multi-tenancy, which is a principle in software architecture where a single instance of the software serves multiple client organizations (called tenants). With a multi-tenant architecture, the portal is designed to virtually partition its data and configuration and each client organization works with a customized virtual portal instance.
 |
Let's have a brief look at multi-tenant capabilities. As shown in the previous diagram, a portal instance is implemented as a set of database tables such as Company, Account_, Shard, and VirtualHost. As you can see, portal instances are presented as different values of companyId; each portal instance has its own account information (presented as database table Account_), possible database (implemented as database table Shard_), and virtual host settings (presented as database table VirtualHost).
Traditional membership security models address two basic criteria: authentication (who can access) and authorization (what they can do):
The portal extends the security model by terminologies: resources, users, organizations, locations, user groups, communities, teams, roles, permissions, and so on. The portal provides a fine-grained, role-based permission security model (known as RBAC) - a full access control security model:
 |
As shown in the preceding diagram, a resource is a base object. It can be a portlet (message boards, calendar, document and media library, and so on), an entity (message board topics, calendar event, document and media library folder, and so on), or a file (documents, images, applications, and so on). Resources are scoped into portal, group, page, and content model-resource and application (or called portlet).
Permission is an action on a resource. Portal-level permissions can be assigned to the portal (users, user groups, communities, and organizations) using roles. Group-level permissions can be assigned to groups such as organization and communities. Page-level permissions can be assigned to page layouts. Model permissions can be assigned to model resource such as blog entries, web, and content. Portlet permissions can be assigned to portlets such as View and Configuration.
A role is a collection of permissions. Roles can be assigned to a user, user group, site, location, or organization. If a role is assigned to a user group, site, organization, or location, then all the users who are members of that entity receive the permissions of that role.
A user is an individual who performs tasks using the portal. Depending on what permissions have been assigned, the user either has the permission or doesn't have the permission to perform certain tasks.
Additionally, a registered user who has the permission can have public pages and private pages. More interestingly, a user's private pages and public pages have the ability to use page templates which can be used to customize a set of pages. The pages — private/public — are configurable in properties. You can turn on or turn off access to these pages. Also, only a power user can use a private/public page. A guest is also a user.
A group is implemented as an organization, user, and user group. A user is a group with only one member, that is, the user itself. An organization could be a regular organization and location.
Organizations represent the enterprise-department-location hierarchy. Organizations can contain other organizations as sub-organizations. Moreover, an organization acting as a child of a top-level organization can also represent departments of a parent corporation.
A location is a special organization, having only one parent organization associated and having no child organization associated. Organizations can have any number of locations and sub organizations. Both roles and users can be assigned to organizations (locations or sub organizations). By default, locations and sub organizations inherit permissions from their parent organization using roles.
A community (renamed as site) is a special organization with a flat structure. It may hold a number of users who share common interests. Thus we can say a site is a collection of users who have a common interest. Both roles and users can be assigned to a site.
A user group is a special group with no context, which may hold a number of users. In other words, users can be gathered into user groups. Users can be assigned to user groups, and permissions can be assigned to user groups using roles. Therefore, every user that belongs to that user group will receive those role-based permissions.
A team is a group of users under a community or an organization. A community or organization can group a set of users and create a team. The notion of a team is somewhat similar to a role, but a role is a portal-wide entry, while a team is restricted to a particular site or organization. Therefore, you can manage the permissions of a team like a role. That is, a team is like a site or organization role, but specific to a certain site or organization. A team is different from a User Group too. A user group has the scope of a portal, while a team is always exclusive to a site or organization.
In addition, each group can have public pages and private pages. Thus users in a user group can share private and public pages. More interestingly, a group's private and public pages do have the ability to apply page templates or site templates in order to customize a set of pages in a fast way.
Liferay is, first and foremost, a platform where you can build your applications with the tools you feel most comfortable using, such as JSF 2 - ICEfaces, Struts 2, Spring 3 MVC, Vaadin, jQuery, Wicket, Dojo and more.
When developing systems, the Model View Controller (MVC) pattern is followed throughout the book. The model manages the behavior and data of the portal domain, responds to requests for information about its state from the view, and responds to instructions to change its state from the controller. The view (like JSP, XHTML, JavaScript) renders the model into a form suitable for interaction, typically a user interface element; while the controller (such as actions, controllers) receives input and initiates a response by making calls on model objects.
In Liferay, there's a concept called a plugin, which is a WAR file that can be hot-deployed into the portal at runtime. Plugins can be categorized as portlets, themes, layout templates, hooks, and webs. These plugins can be developed using the Plugins SDK. Prior to Liferay 6, there used to be an ext environment, where the developer could customize the core portal module. Since Liferay 6, it has been replaced by the Ext plugins approach.
Service-Builder is a Liferay tool to generate persistence and service-layer code, by reading an XML file.
Of course, you're not required to write a lot of code yourself. You can use Service-Builder to generate a lot of the code for building the models and services. Generally speaking, the Service-Builder is a tool built by Liferay to automate the creation of interfaces and classes that are used by a given portal or portlet. The Service-Builder is used to build Java services that can be accessed in a variety of ways, including local access from Java code, as well as remote access using web services.
In general, the Service-Builder is a code generator. Using an XML descriptor, it generates:
Java Beans
SQL scripts for database tables creation
Hibernate Configuration
Spring Configuration
Axis Web Services
JSON JavaScript Interface
The Plugins SDK Environment is a simple environment for the development of Liferay plugins, such as ext, themes, layout templates, portlets, hooks, and webs (web applications). It is completely separated from the Liferay Portal core services by using external services only if required.
The portal supports six different types of plugins out-of-the-box. They are Portlets, Themes, Layout Templates, Webs, Hooks, and Ext:
Portlets: Web applications that run in a portion of a web page
Layout Templates: Ways of choosing how the portlets will be arranged on a page
Webs: Regular Java EE web modules designed to work with the portal such as ESB (Enterprise Service Bus), and SSO (Single Sign-On). Note that a web is a pure web application where a thin layer is added to provide checking for dependencies. A web also adds support for embedding hook definitions or Service Builder services within a plain old web application. And finally, you can deploy them using the auto-deploy mechanism the same way that you can with other plugins.
Ext: ext environment as a plugin means you can use the extension environment as a plugin in the Plugins SDK environment.
As you can see, you can generate code for plugin Portlets, Webs, and Ext. Normally, you would have one project for each plugin, for example, theme, layout template, hook, ext, or web; you can have many portlets in one plugin project portlet. Hook plugins can be standalone, or they could be included with portlets and web. This means, in one plugin project portlet or web, you can have hooks and many portlets or a web as one WAR file. What are the advantages of aggregating many portlets into one WAR? We have shared database workspace with many portlets and can implement collaboration between each other.
Liferay IDE is used to provide best-of-breed Eclipse tooling for the Liferay Portal development platform for version 6 and greater. The availabilities of Liferay IDE cover, but are not limited to, the plugins SDK support, plugin projects support, project import and conversion, wizards, code assist such as portlet taglibs, customizable templates, and XML catalog (XSD) contributions.
The Extension environment provides the capability to customize Liferay Portal completely. As it is an environment which extends Liferay Portal development environment, it has the name "Extension", (called "Ext"). With Ext, we could modify internal portlets which are also called by the out-of-the-box portlets. Moreover, we could override the JSP files of the portal and out-of-the-box portlets. This kind of customization is kept separate from the Liferay Portal source code. That is, the Liferay Portal source code does not have to be modified, and a clear upgrade path is available in the Ext.
Starting with version 6, Ext environment is available as a plugin called Ext plugin. As shown in the following diagram, custom code will override Liferay Portal source code in the Ext plugins only. In the deployment process, custom code is merged with Liferay Portal source code. That is, developers can override the Liferay Portal source code. Moreover, custom code and Liferay Portal source code will be constructed as a customized Liferay Portal first, and then the customized Liferay Portal will be deployed to an application server. In addition, both direct deploy (ant direct-deploy) and standard deploy (ant deploy) are available.
 |
Hooks are a feature to catch hold of the properties and JSP files into an instance of the portal, as if we were catching them with a hook. Hook plugins are more powerful plugins that complement portlets, themes, layout templates, and web modules. A hook plugin can, but does not have to, be combined with a portlet plugin or a web plugin. For instance, the portlet called so-portlet is a portlet plugin for social office with hooks; a hook plugin can simply provide translation or override a JSP page.
In general, hooks are a very helpful tool to customize the portal without touching the code of the portal, as shown in the following diagram. In addition, you could use hooks to provide patches for portal systems or social office products.
In general, there are several kinds of hook parameters:
 |
As you can see, JSPs hooks can set a custom-jsp-dir that will overwrite portal JSPs. You can also add<custom-jsp-global>false</custom-jsp-global> (default to true) so that JSPs hooks will not apply globally but only to the current scope. Each site (or organization) can choose to have that hook apply just for that site (or organization).
In addition, Liferay allows portal JSPs to be overloaded by theme templates this pattern will require that within the theme's templates folder, the complete path to the original JSP be maintained with the file extension replaced to match that of the theme's chosen template language.
As you can see, the Plugins SDK is a simple environment for the development of Liferay plugins, including portlets, layout templates, and webs (that is, web applications). It provides the capability to create hot-deployable hooks, themes, layout templates, portlets, and webs.
How does it work? As shown in the following diagram, the Plugins SDK provides an environment for developers to build portlets and webs. Later, it uses the Ant Target Deploy or Maven to form a WAR file and copy it to the Deploy directory. Then, Liferay Portal together with the application server will detect any WAR files in the Deploy (auto deploy, hot deploy, or sandbox deploy) folder, and automatically extract the WAR files into the application server deployment folder. Note that the portal is able to recognize the type of the plugin and enhance it appropriately before hot-deploying it. For example, for portlets it will modify web.xml by adding required listeners and filters.
During customization, you could use the Service-Builder to generate models and services in portlets and/or web plugins. In general, the Service-Builder is a code generator using an XML descriptor. For a given service.xml XML file, it will generate SQL for creating tables, Java Beans, Hibernate configuration, Spring configuration, Axis Web Service, and JSON JavaScript Interface. Of course, you can add hooks in portlets and/or webs plugins.
 |
A theme specifies the styles of all major global portlets and content; therefore, it controls the way the portal will look. In general, a theme uses CSS, images, JavaScript, and Velocity (or FreeMarker) templates to control the whole look-and-feel of the pages generated by the portal.
As shown in the following diagram, the theme plugin can use default themes as a basis, building differences on top.
 |
As mentioned earlier, there are at least three development environments: portal core source code, Ext plugin, and normal plugins. Thus, you may ask: Which kind of development environment is suitable for our requirements? When should we use the Ext plugin? And when should we use other plugins, or even Liferay Portal source code? Let's take a deep look at the development strategies.
As shown in the following diagram, Liferay Portal is extensible on at least three levels, for example the Plugins SDK Environment (Level I), Ext plugin (Level II), and Liferay Portal source code (Level III). As you can see, each level of extensibility offers a different compromise of flexibility with different migration requirements to future versions. Thus we need to choose the appropriate level for the requirements at hand ; one which allows for the easiest future maintainability.
 |
In Level I, we can develop portlets, themes, layout templates, hooks, and webs as independent software components. Moreover, these plugins can be distributed and deployed as WAR files, and can be organized in plugin repositories. Liferay Portal provides the Plugins SDK to help us with the development of these plugins.
In addition, portlets developed in the Plugins SDK can only import classes from the portal API (Portal-Service), not Portal-Impl. This means, portlet development in the Plugins SDK does not touch portal properties, language properties, core services, and JSP files related to Portal-Impl. Fortunately, hooks provide the capability to access portal properties, language properties, struts actions, core services related to Portal-Impl, and custom JSP files.
In Level II, we can manage configuration files, custom source code, custom JSP files, and modified JSP files related to the Portal-Impl. This means that the, Ext plugin provides different sublevels (for example, configuration files, custom source code, custom JSP files, and modified JSP files) of extensibility.
Among the configuration files, portal-ext.properties has the main configuration options: layouts, deployment, themes, Hibernate, cache, instance settings, users, groups, language, session, auth, integration, and events. Meanwhile, the system-ext.properties file is a convenient way to provide and extend the Java System properties used by Liferay Portal. We can also create custom classes for the most common extensibility, which need to be configured through the portal.properties file. Examples are authentication chain, upgrade and verification processes, deployment processes, database access and caching, user fields' generation and validation, session events, permissions, and model listeners.
For custom source code, we can use Spring-based dependency injection mechanisms configured in the ext-spring.xml file as follows:
1. Add the
Servletextended in theweb.xmlfile.2. Add the Struts action extended in the
struts-config.xmlfile.3. Moreover, create portlets that access
Portal-Impl, or events extending its models and services.
For custom JSP files and modified JSP files, we can customize any of the JSP files used by the out-of-the-box portlets and management tools. This is a very flexible extension mechanism.
Note
Without a doubt, it is easier to develop portlets in Ext plugin, where you can easily access and use all of the Portal APIs, taglibs, JSP files, and almost everything else. This isn't the case with the other plugins.
Starting with version 6, the Extension environment becomes the Ext plugin. Golden rule: support for Service-Builder in Ext plugins will be deprecated in future versions. Ext plugins are designed to override the portal's core code in ways that can't be done with hooks, layout templates, portlets, or themes. Ext plugins aren't meant to contain new custom services. Thus any 5.x service.xml in Ext environment should be migrated into a portlet plugin.
In Level III, we can modify the Liferay Portal source code. This approach can only be used for sponsored development or providing patches for bug fixes, new features/improvements, and portal core contribution development. This means, you can develop specific features for specific projects first and then contribute back to Liferay Portal source code, or provide patches to override Portal-Impl, Util-Java, Util-Taglib and Util-Bridges partially.
In brief, if your requirements are related to customize and/or extend Portal-Impl (for example, UI changing, LDAP import algorithms, document and media library lock mechanism, forms for user registration or organization creation, integration, modifying the out of the box portlets, and so on.), you should use Ext plugin. Otherwise, it is better to use other Plugins. Note that with hooks, you can hook up portal properties, language properties, core services, and Struts actions related to Portal-Impl.
Keep in mind that Ext plugin is designed to override the portal's core code in ways that can't be done with hooks, layout templates, portlets, or themes; and Ext plugin shouldn't contain any custom services.
What's a knowledge base? According to Business Dictionary (refer to http://www.businessdictionary.com/definition/knowledge-base.html), a knowledge base is defined as:
"Organized repository of knowledge (in a computer system or an organization) consisting of concepts, data, objectives, requirements, rules, and specifications. Its form depends on whether it supports an (1) artificial intelligence or expert system-based retrieval, or (2) human-based retrieval. In the first case, it takes the form of data, design constructs, couplings, and linkages incorporated in software. In the second case, it takes the form of physical documents and textual information."
How to implement a knowledge base in the portal? A knowledge base could be implemented as a set of portlets plus hooks with the following major requirements. Of course, you can add your specific requirements in knowledge base management (KB).
Modeling knowledge base as articles plus article templates, article comments, private messages, contacts, and tasks
Versioning and authoring articles, and organizing them in a hierarchy of navigable and scope-able articles
Supporting multiple languages on title, content, and description of articles
Ability to lock and unlock articles
Supporting look-ahead typing in articles search
Supporting caching, asynchronous threads, indexing, and advanced search
Representing knowledge base management as a set of JSR-286 portlets, for example, Admin, Private Messaging, Contacts, Tasks, Docs Viewer, Aggregator, Display, Search, and List; and supporting inter-portlet communication (IPC events and public render parameters) among portlets Aggregator, Display and List; and leveraging different portlet bridges such as Struts 2, JSF 2, Spring 3 MVC, Wicket, and so on
Leveraging dynamic data list and dynamic data mapping to build dynamic document types and meta-data sets
Leveraging dynamic query APIs and custom SQL
Adding permission checker on articles
Ability to add attachments and images to articles
Ability to add asset links, asset ratings, and asset view counts
Ability to add asset comments to articles and votes on comments
Ability to add hierarchy of asset categories
Ability to add asset tags to articles
Ability to add RSS feeds and to subscribe to articles
Ability to add polls on articles
Exporting and converting articles to PDF and other formats
Supporting configurable workflow
Ability to add custom attributes (called custom fields)
Ability to archive (import and export) and to remotely publish articles
Allowing use of auditing, rule engine (Drools), and reporting engine (JasperReports)
Ability to import a semantic mark-up language for technical documentation called DocBook, referring to http://www.docbook.org
Providing web services for knowledge base articles
Providing JSON services for knowledge base articles
Providing RESTful services for knowledge base articles
Integrating CAPTCHA or reCAPTCHA with knowledge base articles
Applying JavaScript such as jQuery and mash-ups when building portlets
Supporting asset rendering in the Asset Publisher portlet
Integrating social activity and social equity
Ability to apply portal core and other features to knowledge base articles
This book is going to show you how to develop portal systems via a real example—knowledge base management. By the end of this book, you will be familiar with major portal features, be able to apply them to knowledge base articles, and implement the aforementioned requirements as well. Of course, you will know the portal in-depth from a systems development viewpoint, and moreover, on top of Liferay Portal, you will be able to cook your own favorite dishes quickly and concisely.
In this chapter, we have looked at what Liferay can do for your corporate intranet, and we have briefly seen why it's a good choice.
If you want more background information on Liferay, the best place to start is the Liferay corporate website (http://www.liferay.com) itself. You can find the latest news and events, various training programs offered worldwide, presentations, demonstrations, and hosted trials. More interestingly, Liferay eats its own dog food; corporate websites with forums (called message boards), blogs, and wikis are built by Liferay using its own products. It is a real demo for the Liferay Portal.
Liferay is 100 percent open source and all downloads are available from the Liferay Portal website (http://www.liferay.com/web/guest/downloads/portal) and the SourceForge website at http://sourceforge.net/projects/lportal/files. The source code repository is available at http://svn.liferay.com/repos/public (credentials the username is Guest and no password) and Github (https://github.com/liferay), and source code can be explored at http://svn.liferay.com.
Liferay's website wiki (http://www.liferay.com/web/guest/community/wiki) contains documentation such as a tutorial, user guide, developer guide, administrator guide, roadmap, and more.
Liferay's website discussion forums can be accessed at http://www.liferay.com/web/guest/community/forums and the blogs at http://www.liferay.com/web/guest/community/blogs. The road map can be found at http://www.liferay.com/web/guest/community/wiki/-/wiki/Main/RoadMap. The official plugins are available from http://www.liferay.com/web/guest/downloads/official_plugins.
The community plugins are available from http://www.liferay.com/web/guest/downloads/community_plugins. They are the best places to share your thoughts, to get tips and tricks about Liferay implementation, to examine the road map, and to use and contribute community plugins.
If you would like to file a bug or know more about the fixes in a specific release, then you should visit the bug tracking system at http://issues.liferay.com/.
Alloy UI Forms is a set of taglibs built on top of the Alloy UI JavaScript + CSS framework. For more information about the framework, you can visit: http://alloy.liferay.com. CSS3, CSS level 3, is available from http://www.w3.org/Style/CSS/current-work. A detailed description of HTML5 is available from http://dev.w3.org/html5/spec/Overview.html.YUI 3 is Yahoo!'s next-generation JavaScript and CSS library at http://developer.yahoo.com/yui/3/.
In this chapter, we have looked at what Liferay can offer to your intranets and Internet. Particularly, we saw:
The portal provides shared documents, videos, audios, images, and records, discussions, collaborative wikis, social activities, dynamic web content, web forms, and more in a single, searchable portal
The portal is a great choice for intranets and Internets, easy-to-use, open source, extensible, integrated with other tools and standards
Service-Builder and the Plugins SDK provide portal systems development and customization environments with plugins such as Ext, themes, layout templates, webs, portlets, and hooks
In the next chapter, we're going to introduce the Service-Builder and the development environment.
