Hyland Connect

luissala · ‎05-10-2016

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 maintaing 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 heirachy (obviously).

When you manage content in one place like alfresco where you are also likely to mangage 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 Artificats

Transforms / Templates
Style Sheets (css)
XFO
etc

Portal Design Artifcats (Layout)

Page (Ties Theme, and Layout, and portlet roster with URL) - Pages are organized into site strutcture
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 managment 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 artifcat 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 dont 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 poweful 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 artifcat. There is a coupling there that I would like to see broken at some point.

All of these artifcats 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 artifcats. They are closer to content artifcats and the roles responsible for content.