First experience (2007)
It was in 2007 when we had a first closer look at Alfresco (v2.1 Community) and decided to try it out for web content management. At that time, we already had a few years of WCM experience – mostly based on the Vignette system including dynamic portal. At first glance, it seemed alfresco and Vignette have some concepts in common. Vignette background helped us getting started with alfresco and also raised a few questions „How does alfresco do this ?“. Excited about alfresco beeing a „real“ open source ECM, we tried to build a website using it and followed tutorials and various information on the web. Quite soon, we found that alfresco WCM was just not yet ready for prime time. The technical foundation looked solid, but its usage was not „natural“ at all. We wanted a ready to use website-model including page, template, navigation, region and component objects (speaking in Vignette terminology). Besides we wanted in-context editing of content-instances (Vignette term, i.e. a news item on a page). All alfresco had to offer in this regard were XSD based webforms and renditions. We stopped here and decided to try again at a later time.
Second experience (2008/2009)
At the end of 2008 I was asked to join a proof of concept project for alfresco as a WCM. The customer was willing to make a few compromises here and there, but there also were quite few „hard“ requirements to fulfill. The most challenging one was the portal (as in JSR-286/portlet 2.0) which had to be used for enduser presentation of the content. I had never seen (and wonder if that will ever be the case) a portal in harmony with a CMS – even if both products come from the same vendor. Some website model objects, such as pages, templates, regions and navigation can really cause great headaches once you decide both systems should be aware of them. People are hyping the alfresco + liferay combo. I have not yet had a close look at this, but I doubt this combo has a „decent“ integration approach regarding website objects.
Alfresco Surf (which is/has) a ready to use website-model was ready to use so the question was raised whether we should make use of it or not. We decided to built on top of it for two reasons:
- We wanted the CMS to be „website-aware“ (as in pages, navigation etc.)
- Alfresco WebStudio (although beta and hence a bit buggy) offered a very seductive UI for editing website objects
As both systems now were aware of pages, navigation and so on, we had to deal two models now. The solution which was worked out during the poc was of course far from perfect. „Content-portlets“ retrieved their content asking an alfresco Surf application for „the content on that page and that region“. URIs had to be created or rewritten so they fit in the portal context. The navigation (portal and Surf) was no 1:1 match, so we had to create a special „navigation-portlet“ (just as in Vignette).
WebStudio helped a lot building a Surf based website, but we still had to work with the „usual“ web-client. The main usage was editing webform based content-instances. To be honest, I never really liked the idea of generating content presentation (i.e. HTML) using (webform) renditions – especially when you have lots of content-instances and change presentation frequently during development. The webform rendition approach also does not fit very well with Surf where you usually also deal with presentation.
model.xml = contentInstanceHelper.getContentXml(context , source.downloadURI);
In the (freemarker) view, we access xml element values (thanks to freemarkers NodeListModel under the hoods) just as javabean properties:
The second thing required to get this behaviour was extending the default PresentationScriptProcessor (overriding unwrapValue).
This code works independent of the environment (Webstudio/production)
Once you got started using WebStudio, you quickly want to do things not supported out of the box. On the very top of my wishlist was (and still is) content-instance editing while you edit components. We only implemented content-instance selection („render that XML data“) for our (custom) components as the alfresco people were already working on the forms service which seems to address this missing feature.
In the end, the customer was convinced by the poc and decided to implement the „real“ project using alfresco WCM. I continued supporting them.
Equipped with the alfresco WCM lessons learned, we implemented our own site just as described here. One thing that came up here (again) was the fact that Surf (ootb) uses the HttpSession while rendering. That is not always what you want – especially when you build a public website and have SEO issues in mind, so we changed that.
Meanwhile, I waded through thousands of lines of alfresco code and submitted various JIRA issues and patches.
Even though there were (and still are) a few rough edges, this second experience felt a quantum leap ahead of the first one.
You can build a content/editorial driven website based on the full alfresco stack (including Surf that is) today. Regarding convenience you still have to make some sacrifices. But that should hopefully change very soon. One major (difficult) issue left is referential integrity of (web)form generated content (s. posting in community).
Today, there is quite some buzz going on regarding alfresco drupal integration based on CMIS (Details can be found at ecmarchitect.com). Sure, drupal is mature, but Surf looks far more natural. Now that alfresco has finally achieved a major milestone implementing DoD 5015.02 (record-management), I hope the WCM features listed on their Roadmap will make their way under my x-mas tree so our third experience will feel like another quantum leap. Can’t stand waiting to get hands on. ;)