When I started working with Liferay some things took me a while to figure out due to a certain difference in names used for Liferay features in user documentation and interface (Control Panel in particular) and names used internally in Java APIs, database tables etc. So I though a little table of correspondence might come handy for someone starting with Liferay or getting from user to developer level.
Let’s start with an extended example – Web Content, the base of Liferay CMS features.
It is actually mentioned on Liferay Wiki that some time ago Web Content was called Journal or something like this, but at a certain point all related portlets, control panel sections etc got renamed. Yet internally you will find no sings of “Web Content”.
The Java APIs for working with webcontent as well as DB tables are all still using old naming.
Web Content item is JournalArticle, Structure is JournalStructure and template is JournalTemplate.
To manipulate those you would use classes like JournalArticle(Local)ServiceUtil, JournalStructure(Local)ServiceUtil, JournalTemplate(Local)ServiceUtil, and to see them in database you’d have to look up tables also called “journalarticle”, “journalstructure” and “journaltemplate”.
So, let’s move on to our vocabulary:
|Web Content Item, Structure, Template||JournalArticle, JournalStructure, JournalTemplate||Explained above.|
|Portal page||Layout||Yes, the layouts are actually “Layout Plugins”, and Pages are “Layouts” – this might be quite confusing at first. The often used name plid stands for Page Layout ID, I suppose, and it is an ID of a portal page. See “layout” DB table for all pages in a portal. ThemeDisplay.getLayout() returns current page, and ThemeDisplay.getLayout.getPlid() returns it’s ID (so I suppose, ThemeDisplay.getLayout().getPlid() always equals ThemeDisplay.getPlid() – unless there are some special cases I don’t know of yet, or, well, a bug in Liferay (-: ).|
|Community (and also Organization AFAIK)||Group||BTW each user has own private Community, so you’ll find plenty of interesting data in “group_” DB table.|
|Global Group (Scope)||(Default) Company Group||See for example ThemeDisplay method getCompanyGroupId() – it returns an ID of that “Global” group/scope you see in Control Panel.|
|Portal Instance||Company||Not to be confused with Organization. Portal instance is a completely separate set of portal communities, groups, pages, users etc (well, a separate Web Portal on same Liferay deployment, with same Portlets/Plugins, but different content). Portal Instance has it’s own URL. To find out which instance you’re using you check companyId, as in ThemeDisplay.getCompanyId().|
|Porlet Instance||Portlet Preferences||Yes, each instance of a portlet is represented by set of it’s preferences, and manipulated with API of PortletPreferences(Local)ServiceUtil and related. If you want to find out what pages have instance of youre portlet – it’s all in “portletpreferences” DB table. You can see “plid” column for Page Id, so it’s obvious these “preferences” are tied to portal pages|
|Custom Fields||Expando (Table, Row, Column, Value)||Expando tables are not exclusively used to store custom fields values, but that’s where you find those (see methods with “Default Table” in Expando API). Some portlets also use expando API to create their own tables (like WebForm portlet for example – each instance of it creates it’s own expando table to store in DB data of each form). You can create your own programmatically too – using Expando Bridge APIs.|
|Categories, Vocabularies, Tags||Asset Categories, Asset Vocabularies, Asset Tags||Well, this is just a bit different naming.|
|Document library documents, folders etc||DLFileEntry, DLFolder etc|
|Comments||MBThread, MBMessage||Yes, those comments you can add to an asset in Asset Publisher portlet are stored as MB (Message Board obviously) Message and MB Thread. As always, you can see corresponding DB tables and Java APIs|
Well, that’s more/less it. Enjoy.