Hmm…I guess I am supposed to working on the movie project. However, during Christmas I had the usual technical discussions with my brother and I got all excited about Enterprise Content Management again. I decided to show him some new features in Alfresco 2.9 Community edition (still in development though). Since I don’t work full time configuring *nix-systems I tend to forget some of the things and got some help from him. After that I was all inspired to try to set up a demo system for the NGO RFSL that I am working for. I believe that almost every organisation need some improvements in information management and RFSL is of course no difference.
We rely heavily on email and their is a file server that some uses. Wouldn’t it be great if we could have central repository where we can store all our content in a smarter way. That includes support for metadata, versioning, permission, language versions and workflow for our most common tasks.
So I decided to dive into Alfresco once more and not just try to master configuration on Mac OS X Server but also doing real customizations on the content model and the user interface.
I first started reading the excellent guide provided by the people at ECM Architect which gave me a good start. However, rather soon I discovered that some of the stuff that I previously done in Documentum Application Builder (DAB) was not covered. So I had to resort to the Alfresco wiki and their forums to find the answers.
Unlike using DAB development for Alfresco is done by editing XML-files that resides in /tomcat/shared/classes/alfresco/extension where both the content model files resides, the configuration to the web client and finally a text file with mappings between attributes and the text that should be visible in the labels.
When all these things have been edited and saved the next thing is to restart Alfresco’s tomcat server and keep a close look at the alfresco.log file where all potential error are shown. It usually ends up being a Java trace segment but often with references to line numbers so it is a bit easier to find the errors.
What I was trying to achieve was the same things that I have done in Documentum a month ago. Creating a content model with one base type which I can then inherit attributes from. However, finding the proper structure of that is not easy. My first idea was to have a “rfsl:doc”-type as the base one and then inherit “rfsl:video” and “rfsl:audio” from them. However, since aspects provide a really good and flexible way of handling attributes it is not easy to decide which attributes that should be in the type and which should be in the aspect. It is also important to bear in mind that having content types for like presentations (which could be in both PowerPoint, PDF, Impress and Keynote-format) is one way of creating easy filtering of content. That means having a “rfsl:pres” type but if that will have more or less exactly the same attributes as “rfsl:doc” it boils down to just a filtering issue and the question is if it is worth it. Will users understand how to select which content type to use?
Another important thing for me was to have drop-down menues with values instead of empty fields. In Documentmum that is called Value Assistance and is merely a text string which has nothing to do with the actual content model. Instead the value assistance is to be seem as a template to create entries in the repository. That means that it is possible to remove stuff from value assistance while the value is still in the repository.
In Alfresco this is handled through constraints in the actual content model. Those triggers the values described in the constraints list forming a drop-down menu in the web client interface. However, the values are constraints which means that there are validations going on. So if you have removed or changed spelling of something in the constraints you will get and error when you try to display a content object with the previous value in the repository.
Constraints should come first in the content model file and looks like this:
This particular constraint is used in an attribute called “rfsl:documentkind”. Remember that the reference in the constraints section must be exactly the same as the name of the attribute.
Another big headache was to organize the attributes in the web client interface. Again in DAB there is something called “display configurations” which refers to different Documentum clients being used in the installation. In them you just reorder the attributes as you like and insert line dividers as you see fit. For Alfresco this done in the file called “web-client-config-custom.xml”.
The order in the file determine the order they are shown in the web client and if you want a separator it can be created using:
And in context it could look like this if we wanted a separator in the beginning: