Today, when you build a website, you have lots of choices regarding open source containers/platforms/frameworks and libaries. Comparing them can easily end up getting flamed for comparing apples and oranges. Nevertheless, I dare doing so for Alfresco Surf and portals (as  in JSR-168/286). :)

Our first hands on portal experiences date back to 2004 when there was a lot of buzz going on, portals beeing praised as best thing since sliced bread. The main arguments  to build a website on top of a portal were personalization, content-aggregation and collaboration functionality – built in and standardized. Some products were shipping with various “common enterprise task” portlets and wizards to create a website quickly. Honestly, just as many other people, we were convinced portals will become a big success. Meanwhile (just as many others) our opinion about them has changed a bit :)

When we looked at Alfresco Surf and Web-Studio in 2007 (Details), we found part of its approach looking quite similiar to the one of a portal:

• WebScriptRequest/-Response pretty much look like their portlet counterparts (although Surf does not distinguish between action and render)
• Surf page-anatomy pretty much looks its portal counterpart
• Surf is aware of a user entity (personalization/security)
• With Web-Studio, you can create a Surf based website in a point and click fashion
• Content-aggregation is easily implemented using component webscripts and connectors

For us, that raised the question why Alfresco chose to “reinvent a wheel” which is already there ?

Looking further, we found quite a few areas where Surfs approach differs from portals

• With Surf, Web-Studio and Alfresco WCM, you have “full” web-content-management on top
• WebScripts are more general than portlets – then can execute in diffrent environments (i.e. servlet-/portlet container)
• Dynamic language support built in (serverside javascript) – development can be a breeze when you don’t have to restart the server all the time

Content-management can really cause headaches when you have a portal participating in the game (Our Experiences). Jeff Potts summarizes a few approaches integrating Alfresco (w/o Surf) with a portal in his blog.

Was problematic (web-)content-management support (in portal-context) a reason to create the Surf platform ?

We did not (and still do not) know.

What Alfresco offers today is at least a solid foundation for building personalized, collaborative and content-centric websites. Alfresco Share is a good proof (although it does not “really” cover web-content-mangement as in pages, templates, regions, components etc.). Regarding its features, it could well serve as a demo application of a portal vendor. :) Alfrescos website “point-and-click editing UI” (Web-Studio) is a little behind competition (although in some aspects even ahead), but that may change soon.

Where is the catch ?

Things can get a little cumbersome when you need to embed complex application functionality/behaviour such as form validation, processes/flow, conversations (as in conversion scope) and AJAX within a Surf based website. These are requirements perfectly tailored for stacks like grails or seam. Sure, it is not impossible doing this within a Surf based site, but I doubt Surf qualifies as a “natural choice” when you are faced with these kind of requirements.

How would one implement complex application functionality (i.e. a shop with order process) assuming you are given a Surf based site and you want to use a full-stack such as grails or seam ?

In general, I see two approaches. Make the website two applications – the “main” Surf based site and another one for the application and …

• … integrate the application using AJAX (i.e. using jquery forms).
• … integrate using the portal-style-cross-context approach

Of course  you can also try and make one “Surf + webapp-superstack” application, but going that route, you can easily end up resolving library conflicts. I’ve tried the first route using grails as the “webapp-superstack”. Surely not a golden-hammer solution, but good enough to address some issues quickly and easily.

So when it comes to complex applications, portals seem a little ahead of Alfresco Surf, as there is a wide variety of application frameworks/libaries available and “ready to use”.

PS: We don’t think portals are a failure in general. People involved with portals should have cared a little more about CMSs. We just think there is less reasonable use for portals than we thought there is in 2004. You should think twice before employing one. Are the features a portal offers really addressing your requirements ?

PPS: Portal + cms integration approaches sometimes remind me of this ad suggesting things somehow don’t fit.

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.

We implemented content-instance (webform generated XML) rendering using a custom helper class to get the XML. The webscript (server-side) javascript codes reads like this:

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:

${xml.title}

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.

Conclusion

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. ;)

Vorgeschichte

Als IT-Dienstleister mit Schwerpunkt im Bereich Web und Content-Management müssen wir eine eigene, ausdrucksstarke und optisch ansprechende Website haben. In diesem Punkt waren Sandra und ich uns seit sehr langer Zeit einig. Einig waren wir uns ebenfalls, dass unsere Website „irgendwie anders“ sein soll. „Typisch“ für unsere Branche sind Sitemaps wie: Vision, Leistungen, Kontakt, Referenzen, Produkte, Karriere, Impressum in einem klassischen Layout.

Wir würden das Thema „eigene Website“ angehen, sobald Zeit für dieses Projekt vorhanden ist – im Klartext: „Sobald die Projekte unserer Kunden es zulassen“. In diesem Zusammenhang würden wir das Thema „Branding“ und „Corporate Identitiy“ gleich mit „erschlagen“. Es ist sicherlich überflüssig an dieser Stelle zu erwähnen, dass nie Zeit „über“ war …

Bedingt durch die Kundenprojekte und unser „reales“ Leben wurde das Projekt immer wieder verschoben. Mit der Geburt unseres Sohnes entschieden wir uns, dass ich zwei Monate Elternzeit nehmen werde und mich in dieser Zeit intensiv um die Familie kümmere. Ich war mir unsicher, wie unsere Kunden auf meine Entscheidung reagieren und war sehr positiv überrascht, denn überall traf ich auf vollstes Verständnis und Rücksichtnahme.

Zu Beginn des zweiten Monats Elternzeit wurde uns klar, dass dieser Monat die vorerst einzige Möglichkeit sein wird mit dem Projekt „eigene Website“ nennenswerte Fortschritte zu machen. Mitte Februar 2009 ging es „endlich“ los. Gearbeitet haben wir meist abends / nachts nachdem der Kleine ins Bettchen gebracht wurde oder wenn er tagsüber schlief – was eher die Ausnahme bleiben sollte.

Konzeption

Vor der eigentlichen Konzeption prüften wir unsere Rahmenbedingungen. Unter anderem identifizierten wir dabei:

1. Zeit - wir müssen innerhalb eines Monats (zumindest „fast“) fertig werden, ansonsten stagniert das Projekt und muss gegenüber den Kundenprojekten zurückgestellt werden.
2. Redaktionelle Aufwände – müssen im späteren Betrieb „überschaubar“ bleiben.
3. Layout – Design ist nicht unsere Kernkompetenz, aber - die Site soll „irgendwie“ anders und für unser Empfinden „anmutig“ sein.
4. Technologie – wir wollen unseren Kunden zeigen : „We eat the food we sell“.
5. Über uns – „Selbstbeweihräucherung“ liegt uns nicht, Empfehlungen durch Kunden und Geschäftspartner sind uns wichtiger.

Durch die Rahmenbedingungen Zeit und Aufwände stellten wir uns anschließend die Frage: Was soll auf unserer Website dargestellt werden? Viel ist uns da nicht eingefallen. Inhalte wie Karriere und Produkte kamen für uns nicht in Frage und „hübsch aufbereitete“ Xing Profile und Google Maps für die „Anfahrt“ gab es schon.

Okay, im Sinne von (Ruby on) Rails – „Don’t repeat yourself“ gab es gute Gründe genau diese bestehenden Inhalte von Drittseiten zu nutzen. Wenn man vom „Branding/CI“ einmal absieht gab es auch keinen wirklichen Grund der dagegen sprach.

Soweit so gut, irgendwie muss unseren Besuchern auch kommuniziert werden womit wir uns grundsätzlich beschäftigen und was unsere Schwerpunkte sind. In diesem Zusammenhang kam uns die Grundidee vom Aal Prinzip (Andere arbeiten lassen) in den Sinn. Aktuell fachlich relevante Dinge wollten wir direkt von der „Quelle“ (Hersteller) einbinden. Auch wir beziehen einen Teil unseres Wissens via RSS und Twitter – warum diese Inhalte nicht direkt in unsere Site integrieren? Also baten wir jeden einzelnen Urheber um seine Zustimmung und somit Stand der Newsfeedkomponente nichts mehr im Wege.

Mit der Technologiewahl erlegten wir uns selbst „nicht ganz optimale“ Anforderungen auf. Insbesondere die Wahl von Alfresco Surf/WCM und Studio (Beta) trieb die Implementierungsaufwände in die Höhe und legte unsere Nerven des Öfteren blank. Aber die gewonnen Erkenntnisse aus der Arbeit mit diesen neuen Alfresco Komponenten sind zukünftig für eine gute Beratung bei Kundenprojekte wichtig.

„Social Media“ wurde im Laufe der vergangenen Monate und im Verlauf dieses Projektes immer mehr zu „unserem“ Thema. Blogging und Micro-Blogging via Twitter gehören mittlerweile zu unserem Alltag und die produzierten Inhalte somit auf unsere Website. Andere Dinge sind natürlich bereits angedacht, aber der Faktor Zeit steht leider momentan im Weg.

Meine Affinität zu „Groovy/Grails/Agile Software Development“ bewog uns zu der Überlegung, ob und wenn ja, wie wir zu mindestens eine „Grails Kleinigkeit sinnvoll einbauen“ können.

Über die Rahmenbedingungen Layout und Technologie kamen wir zu Javascript/Ajax „Spielereien“ und der Flash Tag-Cloud. Bei der Umsetzung von „irgendwie anders“ entschieden wir uns zum Einen für „unkonventionelle Texte“, zum Anderen für eine „persönliche Note“ durch unsere privaten Fotos von St. Peter Ording.

Am Ende unserer Konzeptionsphase lag das einzige, nicht virtuelle Artefakt – eine Blatt Papier welches den skizzierten Draft einer Seite repräsentierte auf unserem Frühstückstisch. Dies ist heute natürlich nichts revolutionär Neues, aber diesen Anspruch hatten wir auch nie. Nun noch das Thema CI und Style Guide „abfrüstücken“ und der Implementierung unserer Website steht nichts mehr im Wege. Die Randbedingung Zeit führte uns zu den funktionalen und schlichten WordPress Vorlagen. Wir entschieden uns für das Theme „ocean mist“ als Ausgangspunkt für unseren Blog. Der finale Entwurf für das Logo und das Layout der Website kostetet Sandra noch einige Abende Zeit, aber mit dem Ergebnis sind wir heute beide zufrieden.

Implementierung

Wir begannen mit der Evaluation von Software für die einzelnen Bereiche. Im Wesentlichen arbeiteten wir uns durch Massen von Javascript Bibliotheken und Komponenten. Insbesondere im Zusammenspiel mit CSS wären wir ohne Firebug vermutlich wahnsinnig geworden. Aber selbst mit diesem tollen Tool war die Implementierungszeit für die Kompatibilität mit „Minderheiten-Browsern“ nicht unerheblich.

Ein „IFrame Konzept“ wurde nach langem Probieren verworfen weil IFrames einfach zu viele Probleme gemacht haben (z.B. Resizing und Frame-Breaker).

Verglichen mit den Javascript – / CSS Abenteuern war der Alfresco SURF Teil der reinste Spaziergang. WebForms wurden für die redaktionellen Inhalte erstellt und ein paar kleine Erweiterungen für SURF wurden geschrieben. Im Wesentlichen wollten wir die von den WebForms erzeugten XML Daten auf „natürliche“ Art und Weise im Freemarker View behandeln und keine Renditions nutzen. Fairer weise müssen wir sagen, dass wir hier schon Erfahrung mitgebracht haben. Die „blauen Flecken vom Ersten mal“ hatte wir uns bereits in einem anderen Projekt geholt. ;)

Lediglich zwei Dinge gefallen uns aktuell an unserer SURF Lösung noch nicht:

1. SURF erzeugt HttpSessions – das ist hinsichtlich SEO sicher nicht optimal
2. User friendly URLs – natürlich kann man custom PageMapper/LinkBuilder implementieren – so komfortabel, einfach und schnell wie Grails UrlMappings ist das aber nicht – bin ich hier zu verwöhnt? ;)

Bei nächster Gelegenheit werden wir diese Themen angehen. Auch wenn Letzteres bei uns kein Problem ist, weil wir ja nur eine Seite haben.

Ein paar kleinere „Problemchen“ gab es auch im Zusammenhang mit Alfresco Web Studio. Angesichts des Beta Stadiums des Produktes haben wir diese erwartet und waren auf einige Stolpersteine vorbereitet. Workarounds haben sich hier meist schnell gefunden, denn nach den Javascript / CSS Abenteuern war Andreas schon fast ein Guru auf diesen Gebiet. ;)

Man sieht es unserer Website wohl nicht an, aber das Ausformulieren der Inhalte hat sehr viel Zeit gekostet. Vor allem, weil wir die wichtigsten Dinge in einer „Seite“ unterkriegen wollten und immer genau auf den Punkt kommen mussten.

Nun ist Contentreich live! Wir haben einen riesigen Meilenstein geschafft. Viele Ideen und Verbesserungen sind bereits in Planung und werden bestimmt auch „bald“ umgesetzt.

Insgesamt sind wir heute „schon“ sehr zufrieden mit dem Ergebnis und hoffen, dass es auch anderen gefällt.