Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
Competitive CMS Products
Features
- It's more of a platform than a portal server, it includes an IoC container (pico container), JSR-170 repository, JSR-168 portlet container which utilises Java Server Faces (JSF) which is under JSR-127, so it certainly standards compliant!
- Includes an Eclipse Plugin to aid the development and deployment of portlets
- Has an Express and Enterprise edition, enterprise adds EJB capabilities (so requires an EJB capable appserver i.e. JBoss or JOnAS) and jBPM workflow
- The portlet container is based on JSF so it obviously supports that, it also has it's own MVC framework as well bridges for Struts and Cocoon
- Their demo includes a JSR-170 browser portlet and quite an impressive admin console (feature wise, UI needs work)
- Supported on a wide variety of app servers
- They have the notion of navigation portlets which are updatable via 'JSR-168 API extensions', it is configurable as a breadcrumb view, horizontal menu, vertical menu or sitemap
- They have an example of it's use as a 'Visited Pages' portlet
- Events can be broadcast for other portlets to listen to (inter-portlet communication), this is an interesting approach we could use and is apparently being recommended for future portlet specifications
- You can change the layout of the portlets for each user at runtime
- Groovy is integrated, you can setup groovy scripts to be event listeners so you could send an email when a new user gets added for example
- The look and feel can be changed by deploying new skins so should be fairly easy to customise to our look and feel
- Has a single sign on mechanism to enable seamless login to all the applications behind the portlets
- Has support for WSRP too but I didn't look into this aspect any further
- The generic JSF portlet example Kev used for JBoss deploys but does not run properly, I suspect it is to do with the fact that they already have a JSF bridge that should be used. This raises a good point though; we may have some integration work to do with those portals that already have JSF bridges if we use JSF ourselves!
Use & Impressions
- The user interface of the 'place' you are put by default is old and clunky although it is customisable
- Seems a little sluggish
- They don't have any big names users of the system
- There are spelling mistakes in the documentation as well as the code (Andy found in the repository code)
- HTML returned is only what is displayed but there is a large amount of whitespace, to refresh the whole page is re-rendered
- To get portlets to display you have to login as a user, create a category, add the portlets you want to the category, add the roles that can see the portlet and then finally actually add the portlet to the layout.
- For me the next time I logged in the portlet had gone and I had to re-add it but I'm sure that is configurable somewhere...I would hope!
Code Review
- Uses the naught .* for imports
- Not one comment, not even JavaDoc comments
- logging statements are not surrounded with logger.isDebugEnabled() checks
- Mixed spaces and tab characters
- Although it's a Sun coding standard they use the { on the end of the line approach i.e. public void method() { which makes the code look compressed and therefore harder to read, particularly with the lack of comments
- Classes are a reasonable size but because maven is used to build the packaging consists of *lots* of little projects
- A full testing framework has been implemented which raises the quality perception
Conclusion
The eXo platform certainly has a lot of features and looks to be a powerful portal environment, but that for me is the downside to it as a development tool, it's too heavyweight to use for development purposes, even though it has an Eclipse plugin to help with development and deployment it's only really useful to get you started, once the portlet is deployed you still have to manually add it to the UI. However, it is certainly a portal server we could deploy to as it's 168 implementation seems to be fine.
The one thing we can take from it is their notion of event based inter-portlet communication, this decouples the portlets from each other and is an approach that may make it into a future portlet specification.
