The Proposals Wiki has been deprecated in favor of creating Feature Requests in JIRA. If you wish to propose a new idea for a feature, visit the Community Ideas Dashboard and read the Feature Requests Wiki page for more information about submitting your proposal.
« Torna a FrontPage

JCR Portal Domain Model

Project Description#

What's in the Portal Domain Model#

  • Portal instance Configuration
  • Portlet Definition
  • Portlet Entity
  • Layout
  • Theme
  • Page
    • Portlet Roster
    • URLs
    • Theme
    • Layout
    • Security strategy
    • Rendering strategy


JCR is a standard which in some ways is similar to the SQL standard. Neither SQL nor JCR dictate specific domain models. They are standards that are intended to formalize the mechanisms for access to the data. JCR is unlike SQL in that it does not provide a grammar for querying a repository.


Portal lacks any standards beyond JSR-168 and the soon to be released JSR-286 portlet specifications. The Portlet specification is intended to provide the requirements an application must meet in order to run inside a portlet container. There is no standardization around portlet containers or portals other than what is implied by the Portlet specification. Due to the lack of standardization in the space portal products have grown highly proprietary.

Standards are nice but#

While standardization in the portal space would be an interesting outcome of this proposal it is not the intention of the proposal. Clearly Liferay stands to benefit from the proposal with or without standardization.

Reasons for a JCR Based Domain Model#

There are a number of reasons for moving the Portal Domain model inside a JCR (Java Content Repository) repository.

  • A number of tools and products are emerging around the JCR.
  • The basic Liferay domain model can be easily extended through the use of extensions and mixins.
  • Liferay model objects could be managed by other applications (particularly JCR enable CMS.) This means that Liferay would automatically inherit the capabilities of whatever JCR repository is below it and whatever content management capabilities are built around the repository itself.
    • Versioning of the model
    • Auditing of the model
    • Rules execution
    • Lifecycle and management
    • Virtualization
    • Workflow and BP
    • Publishing

<b>In other words, Change the persistence model and let other tools do the heavy lifting.</b>

The Liferay staff does not just develop portal it develops applications and utilities around portal. This approach is good. While there is some risk to what is core vs. what is context. The issue is easily solved. When we look at the portal and its architecture we must wear the portal hat. When we are developing the portlet business we must think from that side.

Liferay has to provide some solution for the following capabilities

  • Versioning of the model
  • Auditing of the model
  • Rules execution
  • Lifecycle and management
  • Virtualization
  • Workflow and BP
  • Publishing

A basic concept of these is required within the product. This is because we want to provide a holistic solution for customers who wanting only one download, one setup, one product. The basic concept should be pluggable with more advanced feature rich, enterprise class solutions. Over time one would expect the Liferay solutions would grow in capability - start simple and grow organically from there as the need arises. These capabilities are align more with the portlet side or application side of Liferay than they do from the portal infrastructure side.

From the infrastructure side we must ask. If someone where to adopt up to be used with other products outside Liferay what is needed? What would help others (including ourselves) build pluggable tools around this infrastructure. I would contend that a domain model based in JCR is one of these items. Standardization of the basic model across all portals would be of even greater benefit but is outside the scope of this proposal. Standardization is not the aim here. The aim is to create a platform for extensibility and plugability around the Liferay platform.

Project Requirements/Objectives#

There are no prerequisites for this project.

The project would consist of two deliverables:

  • A Liferay Portal Domain Model
  • Delivery of the portal running on top of a JCR and the Liferay JCR based Domain model.

The risks are:

  • JCR does not "take off" in the same way that Portal has not "taken off"
  • Lack of standardization around domain model is too high a barrier to entry for toolers.
  • Liferay reliance on hibernate for performance enhancement is dropped. JCR is a black box to Liferay which means we will need to find a new mechanism to compensate for slow JCR actions or simply accept that some repositories will be slower than others (as we tend to do with SQL.)

Initial Project Scope#

The initial scope of the project is determined by what is in the core model and what is not. Liferay's "domain model" extends far beyond simple portal structure to include organizational mapping etc. I recommend that we begin with the simple portal model and extend from there.

Discussion of Design/Implementation Approach#

Targeted SQL Tables#

The following are the tables within the existing Liferay SQL Model targeted by this proposal. These tables do not provide the complete description of the model as several of them have fields which hold xml documents in the form of CLOBS.

Also these tables link out to other portions of the model (ie security.) In order to facilitate a clean break between these models an interface/abstraction is needed.


  • layoutId varchar(75) not null,
  • ownerId varchar(75) not null,
  • companyId varchar(75) not null,
  • parentLayoutId varchar(75) null,
  • name longtext null,
    • Contains xml IE
  <?xml version="1.0"?>
    <name>The Home Forum</name> 
  • type_ varchar(75) null,
  • typeSettings longtext null,
    • Contains properites IE


  • hidden_ tinyint,
  • friendlyURL varchar(75) null,
    • Should be 1 to many URL should be able to be anything (NOT a portal-sh URL)
  • themeId varchar(75) null,
  • colorSchemeId varchar(75) null,
  • priority integer,
  • primary key (layoutId, ownerId)


  • ownerId varchar(75) not null primary key,
  • companyId varchar(75) not null,
  • groupId varchar(75) not null,
  • userId varchar(75) not null,
  • privateLayout tinyint,
  • themeId varchar(75) null,
  • colorSchemeId varchar(75) null,
  • pageCount integer


  • portletId varchar(75) not null,
  • companyId varchar(75) not null,
  • narrow tinyint,
  • roles varchar(75) null,
  • active_ tinyint,
  • primary key (portletId, companyId)


  • portletId varchar(75) not null,
  • layoutId varchar(75) not null,
  • ownerId varchar(75) not null,
  • preferences longtext null,
    • Stored as XML IE
  <portlet-preferences   xmlns="">
  • primary key (portletId, layoutId, ownerId)


  • websiteId varchar(75) not null primary key,
  • companyId varchar(75) not null,
  • userId varchar(75) not null,
  • userName varchar(75) null,
  • createDate datetime null,
  • modifiedDate datetime null,
  • className varchar(75) null,
  • classPK varchar(75) null,
  • url varchar(75) null,
  • typeId varchar(75) null,
  • primary_ tinyint

The Database Model#

1 Allegato
36528 Visualizzazioni
Media (1 Voto)
La media del punteggio è 5.0 stelle su 5.