Ask Questions and Find Answers

Let me start first:

1. Web tier
The best thing i like about liferay is its pluggability, you drop portlets(plugins) and configure them and thats it.. And a broken portlet doesnt affect the overall system. Hence making it a solid architecture (close like OSGi i think)

1.1 The default liferay portal uses struts and tiles for web tier and velocity templates for theming. Most of JSR 168 and 286 spec is here. The tag library support of liferay is excellent. For eg: to show an article you just do :

<liferay-ui:journal-article articleId="<%= articleId %>" groupId="<%= themeDisplay.getScopeGroupId()%>" />

1.2 The main entry point for handling portlet request is com.liferay.portal.servlet.MainServlet (web.xml) . Before that a series of filters are applied(cache, autologin, header, etc)
The MainServlet deligates the request to PortletRequestProcessor which decides which of the PortletAction to call. So basically liferay core web tier is an extended struts implementation.

1.3 Most of us extend PortletAction and implement appropriate methods to solve our functional requirement

p.s:
Guys please feel free to type in anything you feel is useful. Just remember to mark them with one of the points listed in the begining.

10. Bootstrap

Some notes on how liferay creates database schema tables and default data the first time when application is deployed(in a blank database) are below:

1. ReleaseLocalServiceImpl.createTablesAndPopulate generates the database objects. It is used to generate database tables, sequence, etc
By default the property schema.run.minimal is true hence its doesn't load sample data (from portal-data-sample.vm)

2. On MainServlet initialization, default user is added to company(if not found).The default admin user is test@liferay.com. The interaction is below:
MainServlet.init() > PortalInstances.initCompany() [web id: liferay.com] > PortalInstances.initCompany() > CompanyLocalServiceImpl.checkCompany creates a Default admin > UserLocalServiceImpl.addUser

9. Database

portal-hbm.xml has the hibernate mappings for hibernate to use.

Web content related tables are below :
journalstructure
Webcontent structures is stored here. The structure id is a string like OUTER_STRUCTURE,etc

journalarticle
Holds the article . has _id and resourcPrimKey .Always use articleId. Remember a data handler should switch articles from staging to live. As staging and live article ids are different.

journaltemplate
Velocity templates are stored here. Column xsl has the velocity content.

Authentication and user info
User profile tables:
User_
Address
contact_

Staging information is stored in
group_

portletpreferences
Store portlet preference. duplicated on moving from staging to live.

10. Liferay CMS

The web content resource are organized as below:

In liferay control panel you have the following for CMS:

Article
Holds the content. The article fields can be configured using a structure. Can belong to a type. Can apply a category. Can be tagged. Stored in DB column journalarticle.content as xml. Web content list and web content article portlets use these articles.
Article version support is available out of the box.

Structure
Defines all the fields the article will have like text input, text area, image input,etc . Also the velocity template can access these fields using the names configured here.

Template
An article can be displayed using a velocity template. Template can have a structure applied to it. So an article on using a structure can choose one of these templates.

Tags and categories
Provides a way to organize articles and make them searchable/filterable.

Document library
Documents can be uploaded from your file system. They are stored in the database. There is a document library portlet for managing this.

Image gallery
Holds images. These are available for article.

-----------------------------------------------------------------------------

Workflow
Liferay has a basic workflow support in it.
Workflow works with staging, hence staging should be turned on first(control panel -> organization -> manage pages -> settings).
It can be turned on once the staging is selected in the same page.

With workflow turned on the portal pages has to go through a content editor -> publisher user who has roles to verify the changes and then make the portal page live from staging.


Publishing
This is also a part of workflow.
The publish from staging to live or publish to a portal instance is questionable.
The way liferay does is through a bunch of data handlers for each portlet.
Also content is physically copied over and duplicated for each article with structure,etc.

The live and staging distinction is done by groups. Live and staging both are separate groups and maintain a copy of web content. Would it have been better if just a status flag was maintained instead of copies? . This would mean any publish should copy content from live group to staging. The data handler in each portlet should ensure this. Most of the pain points are in publish as it is not consistent. It hangs some time and crashes without a clue when one of the web content is broken. Also the publish mechanism is reused for both local and remote publish. In memory the data handler generates a zip archive for contents being exported and unzips it when importing. It would simply mean heap memory will become low on every publilsh. This slows down the publish process heavily. It would be worth if publish bits of liferay is redesigned.

Given a chance i would recommend people not to use liferay web CMS, but instead integrate alternate CMS like Alfresco into it. Maybe it could be an effort upfront, but its worth it. Alfresco has done a good job in CMS front. Liferay is good with portlets. A breed of this would give you a solid CMS based web 2.0 portal i think.

A website in liferay is internally modelled as group. Groups can be 2 types:

a. Community
Liferay comes by default with Guest community. Ideal for hosting a flat website without having any complex hierarchy. Useful when you just have to deploy a single website.

b. Organization
Ideal for enterprise having to host multiple sub websites. It has a hierarchy like organization, sub-organization, sub-sub-organization,etc.


The above two groups can co-exist as well.
All web content articles, structures, tags etc belong to one of these type of group.

Each website page consisting of several portlets is internally modelled as layout.

By default liferay does not enable staging. When staging is enabled for a community or organization a new staging group is created(please refer point 11. in my earlier notes).
With staging comes additional complexity of syncing content over to live group(community or org). This is very painful in liferay as the way publish is implemented and designed is terrible. It works well if you have a small data set. But is really messy (data handler,remote publish, copy from live, etc).

Portal instance
Portal instance can maintain separation between various groups content.
This feature enables you to deploy multiple websites in a single box. Internally liferay models it as a company. Both groups (community and organization) should belong to a company. The default out of the box company is called liferay Inc. There is no portal instance however. This feature is only required for complex hosting requirements i think.

For managing
organization - Goto >> control panel > organization
community - Goto >> control panel > community
Portal Instances - Goto >> control panel > Portal Instances