- REDIRECT Portlets
Integrations
Repository Integration
There are two sides of the repository integration that need to be considered: the extension of the Alfresco repository itself, and the client.
Alfresco Repository
One of the major concerns that needs to be addressed is how what will be stored in the repository. Today Liferay relies heavily on a RDB SQL based back end. Many portals and other projects are adopting JCR as their persistence store.
Comment from rdanner
I have seen this trend which seems to me to be an early adoption of JCR on a scale which seems somewhat premature. The spec has already re-initiated in the JCP with JCR 283. JCR is a huge step forward but it is not a silver bullet. Also in terms of CMS standards which will emerge from AIIM like iECM seem to be a far better option in the future.
I would prefer if we concentrate on managing content and website related assets initially. If Liferay chooses to adopt JCR as a general approach to storage later on it will be good to have some experience with it first.
In terms of the repository we need to decide what items will be modeled and how. I will post some of the things we would like to do at the CS Monitor and I hope others will as well. This help guide us and draw a scope around the Horizon 1 on the roadmap.
Client (Repository Consumer)
It is my hope that Liferay can consume services from the Alfresco repository via the JCR platform, at least in the short term. Depending on the requirements this may not be possible or wise, however it is best for the Liferay portal to be JCR compliant rather then maintaining adapters for different repositories Jackrabbit, Alfresco, Magnolia etc. From the portal's perspective the repository is context.
Web Client Integration
Alfresco is going to release a WCM product at the end of the summer. If you have looked at the user stories for the WCM project there are a number of use cases which are useful to this project but none that directly deal with something like managing a Liferay community or page hierarchy (obviously).
When you manage content in one place like Alfresco where you are also likely to manage transforms and other design artifacts for that content, there is discontinuity with a portal because it also has design and layout artifacts which need to be managed.
Atomic content items
- Images
- Copy (text) usually an XML document
- Audio and video media
Composite content
- XHTML fragments
- Flash
- Articles (Transformed / Rendered Content)
- You name it
Content Design Artifacts
- Transforms / Templates
- Style Sheets (CSS)
- XSL-FO
- etc.
Portal Design Artifacts (Layout)
- Page (ties Theme, Layout, and portlet roster with URL) - Pages are organized into site structure
- Layout (Velocity Template)
- Theme (CSS, JavaScript, and JSP)
portlet roster is one of the gotchas as we do not want to couple the actual portlets with the CMS or management tools. We could look for a name/ID based approach to coupling the page managed, edited and previewed in alfresco with its runtime behavior in the portal. This is a concern we can address once we decide if portal page preview is a capability from with-in alfresco
Another thing that you want to consider once you have a CMS is what roles should be able to do with certain artifact types. For instance at the moment a theme and a layout are deployed as War files in Liferay. This is great because you can package a theme and someone else can deploy it in to their portal, very nice. The problem is because themes come with the technical baggage of J2EE packaging and deployment, it takes a developer to create a theme. I don't want developers involved for changes that can be made to CSS or inert templates, a designer should be able to make the change, preview and deploy it as part of an easy to use workflow.
Templating mechanism are very powerful these days, templates based on FreeMarker, Velocity, and JSP offer great capability and are often easier to use then XSL. This is great. One of the issues I have with templates based on these technologies (especially JSP) is that it's code, and its a developer artifact not a designer artifact. There is a coupling there that I would like to see broken at some point.
All of these artifacts should be managed in the CMS because they require the same kind of management as or similar to code, but are not in general code artifacts, nor are the developer role artifacts. They are closer to content artifacts and the roles responsible for content.
Liferay
