I implemented a simple Alfresco web client customization over the weekend. At Optaros, we’ve got two Alfresco repositories–one in North America and one in Europe. Alfresco doesn’t yet offer federated repositories, but we needed some way to make it easier for folks to jump between the two, and give at least a rough feeling of there being one repository, not two.

So, I added a new section to the “Shelf”. The shelf is a little piece of collapsible real estate in the Alfresco web client UI that contains things like recently viewed spaces (i.e., folders) and bookmarks. The new Shelf Item I added is called “Repositories”. It is essentially a list of links that point to all of the Alfresco repositories in your environment. Users can then click the repository name to open the home space for that repository.

Obviously, it doesn’t implement single sign-on, but at least people can jump between the repositories quickly. And, we should be able to leverage the config in the future to do things like federated search.

This type of customization is a decent way to learn about Alfresco UI customization because it is pretty constrained in scope and yet involves a good cross-section of Alfresco UI config elements like components, tag libs, the configuration service, and actions.

I originally wanted to extend the Alfresco JSPs, but as it turns out, the shelf is implemented in a “parts” JSP that is included in just about every other JSP. The maintenance pain of overriding the config for every out-of-the-box JSP is worse than the potential pain of simply overwriting their JSP with my customized JSP so I chose the latter path. Still, everything else follows their customization model.

According to the forum and this JIRA post, they are aware of the problem that those explicitly-included JSP files cause. No word on when it will be fixed.

I’ll write up the details for how I did the customization and post them here when I get a chance.