Recently, I was approached by Packt publishing if I would be interested in reviewing the Alfresco 3 Cookbook – quick answers to common problems. I like to cook, so I agreed. In short; I expected to cook, stirr and fry, but got a thorough guided tour through the ingredients and the kitchen.
The Cookbook is a great book if you’re a starter on Alfresco. I see many people start out with Alfresco and get overwhelmed with the possibilities. – This is their book.
Alfresco provides a lot of functionality, and some feature can be realized on more than one way. If one knows the limitations, one can make the right design decisions. Certain choices allow one way of working, but can block another. In my opinion the book lacks some reflection on the subject matter. Some examples:
- Full text search is mentioned, but I would love some more detail. For each content item, Lucene indexes a maximum number of terms. If one stores big documents, this can be a point of attention (with a penalty on performance?) (lucene.indexer.maxFieldLength).
- The concept of a Tag Scope is explained very briefly, but I had a different understanding than the explanation on the Wiki. From the Wiki I learned a tag scope is defined by setting an Aspect, but this was not mentioned at all in the Cookbook.
- In the chapter about WebScript a Freemarker templates is described. The feature of JSON encoding (jsonUtils.encodeJSONString) is not mentioned at all, although it should be used at every template in my opinion, since most of the time one cannot control the content of many attributes.
- The same for Freemarker and defaults. Having a default value in a string prevents having a null-object to apply a method onto (and fail, since Freemarker is allergic to undefined variables)
- What are downsides from working in the interface only? Instantiating space templates containing Rules can be a bad idea from a management perspective since there become many definitions of the same. Policies and behaviours can be an alternative, or defining the logic at another level in the Spaces structure. These are design decisions that can make or break a project.
- Rules can be a pain when having a test, acceptance and production environment. How to migrate from one environment to the other, especially when the repository is fully stuffed? At what point are policies and behaviours better friends?
- Workflow can be used to automate stuff. But ‘too much’ code in a workflow is a bad idea. What are alternatives? Should you use adding/removing aspects or property values as a trigger? Should you build custom Script objects implementing the business logic?