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.