fishin widow

First expe­ri­ence (2007)

It was in 2007 when we had a first closer look at Alfresco (v2.1 Com­mu­nity) and decided to try it out for web con­tent man­age­ment. At that time, we already had a few years of WCM expe­ri­ence – mostly based on the Vignette sys­tem includ­ing dynamic por­tal. At first glance, it seemed alfresco and Vignette have some con­cepts in com­mon. Vignette back­ground helped us get­ting started with alfresco and also raised a few ques­tions “How does alfresco do this ?”. Excited about alfresco bee­ing a “real” open source ECM, we tried to build a web­site using it and fol­lowed tuto­ri­als and var­i­ous infor­ma­tion on the web. Quite soon, we found that alfresco WCM was just not yet ready for prime time. The tech­ni­cal foun­da­tion looked solid, but its usage was not “nat­ural” at all. We wanted a ready to use website-model includ­ing page, tem­plate, nav­i­ga­tion, region and com­po­nent objects (speak­ing in Vignette ter­mi­nol­ogy). Besides we wanted  in-context edit­ing of content-instances (Vignette term, i.e. a news item on a page). All alfresco had to offer in this regard were XSD based web­forms and ren­di­tions. We stopped here and decided to try again at a later time.

Sec­ond expe­ri­ence (2008/2009)

At the end of 2008 I was asked to join a proof of con­cept project for alfresco as a WCM. The cus­tomer was will­ing to make a few com­pro­mises here and there, but there also were quite few “hard” require­ments to ful­fill. The most chal­leng­ing one was the por­tal (as in JSR-286/portlet 2.0) which had to be used for enduser pre­sen­ta­tion of the con­tent. I had never seen (and won­der if that will ever be the case) a por­tal in har­mony with a CMS – even if both prod­ucts come from the same ven­dor. Some web­site model objects, such as pages, tem­plates, regions and nav­i­ga­tion can really cause great headaches once you decide both sys­tems should be aware of them. Peo­ple are hyp­ing the alfresco + lif­eray combo. I have not yet had a close look at this, but I doubt this combo has a “decent” inte­gra­tion approach regard­ing web­site objects.

Alfresco Surf (which is/has) a ready to use website-model was ready to use so the ques­tion 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, nav­i­ga­tion etc.)
• Alfresco Web­Stu­dio (although beta and hence a bit buggy) offered a very seduc­tive UI for edit­ing web­site objects

As both sys­tems now were aware of pages, nav­i­ga­tion and so on, we had to deal two mod­els now. The solu­tion which was worked out dur­ing the poc was of course far from per­fect. “Content-portlets” retrieved their con­tent ask­ing an alfresco Surf appli­ca­tion for “the con­tent on that page and that region”. URIs had to be cre­ated or rewrit­ten so they fit in the por­tal con­text. The nav­i­ga­tion (por­tal and Surf) was no 1:1 match, so we had to cre­ate a spe­cial “navigation-portlet” (just as in Vignette).

Web­Stu­dio helped a lot build­ing a Surf based web­site, but we still had to work with the “usual” web-client. The main usage was edit­ing web­form based content-instances. To be hon­est, I never really liked the idea of gen­er­at­ing con­tent pre­sen­ta­tion (i.e. HTML) using (web­form) ren­di­tions – espe­cially when you have lots of content-instances and change pre­sen­ta­tion fre­quently dur­ing devel­op­ment. The web­form ren­di­tion approach also does not fit very well with Surf where you usu­ally also deal with presentation.

We imple­mented content-instance (web­form gen­er­ated XML) ren­der­ing using a cus­tom helper class to get the XML. The web­script (server-side) javascript codes reads like this:

model.xml = contentInstanceHelper.getContentXml(context , source.downloadURI);

In the (freemarker) view, we access xml ele­ment val­ues (thanks to freemark­ers NodeList­Model under the hoods) just as jav­abean properties:

${xml.title}

The sec­ond thing required to get this behav­iour was extend­ing the default Pre­sen­ta­tion­Script­Proces­sor (over­rid­ing unwrapValue).

This code works inde­pen­dent of the envi­ron­ment (Webstudio/production)

Once you got started using Web­Stu­dio, you quickly want to do things not sup­ported out of the box. On the very top of my wish­list was (and still is) content-instance edit­ing while you edit com­po­nents. We only imple­mented content-instance selec­tion (“ren­der that XML data”) for our (cus­tom) com­po­nents as the alfresco peo­ple were already work­ing on the forms ser­vice which seems to address this miss­ing feature.

In the end, the cus­tomer was con­vinced by the poc and decided to imple­ment the “real” project using alfresco WCM. I con­tin­ued sup­port­ing them.

Equipped with the alfresco WCM lessons learned, we imple­mented our own site just as described here. One thing that came up here (again) was the fact that Surf (ootb) uses the HttpSes­sion while ren­der­ing. That is not always what you want – espe­cially when you build a pub­lic web­site and have SEO issues in mind, so we changed that.

Mean­while, I waded through thou­sands of lines of alfresco code and sub­mit­ted var­i­ous JIRA issues and patches.

Even though there were (and still are) a few rough edges, this sec­ond expe­ri­ence felt a quan­tum leap ahead of the first one.

Con­clu­sion

You can build a content/editorial dri­ven web­site based on the full alfresco stack (includ­ing Surf that is) today. Regard­ing con­ve­nience you still have to make some sac­ri­fices. But that should hope­fully change very soon. One major (dif­fi­cult) issue left is ref­er­en­tial integrity of (web)form gen­er­ated con­tent (s. post­ing in com­mu­nity).

Today, there is quite some buzz going on regard­ing alfresco dru­pal inte­gra­tion based on CMIS (Details can be found at ecmarchitect.com).  Sure, dru­pal is mature, but Surf looks far more nat­ural. Now that alfresco has finally achieved  a major mile­stone imple­ment­ing DoD 5015.02 (record-management), I hope the WCM fea­tures listed on their Roadmap will make their way under my x-mas tree so our third expe­ri­ence will feel like another quan­tum leap. Can’t stand wait­ing to get hands on. ;)