Alfresco: The first lessons learned

The last couple of weeks I have learned some lessons the hard way.

1. When doing changes to faces-config(-custom).xml, put it in a jar-file.
This is stated in Developing an Alfresco Module, but it’s very easy to forget because so many places one can read about extending Alfresco using faces-config-custom.xml.

There are two options for making changes to faces-config:
– Add a faces-config-custom.xml in the AMP.
In an IDE it would typically ble places in web/WEB-INF/faces-config-custom.xml. When deploying the amp to Alfresco, it doesn’t overwrite the WEB-INF/faces-config-custom.xml on the server as one would expect, it’s as if the changes were never made. In reality Alfresco does some magic, and the changes are available in alfresco, but not in any extensions you have made. So if you try to create a managed bean and access it from within alfresco jsp-files, life is good. But in most cases, extending Alfresco is the best way to go and then the managed bean is suddenly not available. Therefore the next choice is the best way.

– Add faces-config.xml to the jar-file.
Yes, no need for a faces-config-custom.xml here, and the declarations are available all over alfresco, including any third-party extensions. Inside the jar the file is located at META-INF/faces-config.xml.

Alfresco is simply a bit touchy when dealing with faces-config files.

2. Use (unique) IDs on faces components no matter what
I came up in the situation that I had one jsp that only contained two lines:
<%@ taglib uri="/WEB-INF/repo.tld" prefix="r" %>
<r:webScript scriptUrl="/service/mwsearch" />

With just two lines to maintain, one would think it would be difficult to make mistakes… Wrong! It doesn’t matter that even the taglib documentation state that id isn’t required, because it’s simply not true. ID’s are required unless you want erratic behaviour – IllegalStateExceptions (like seen below) that occurs at random, but will definitly stop the show:

javax.faces.FacesException: java.lang.IllegalStateException: Client-id : _idJsp13 is duplicated in the faces tree. Component : browse:_idJsp13, path: {Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId: /jsp/browse/browse.jsp][Class: javax.faces.component.html.HtmlForm,Id: browse][Class: org.alfresco.web.ui.common.component.UIPanel,Id: spaces-panel][Class: org.alfresco.web.ui.common.component.data.UIRichList,Id: spacesList][Class: org.alfresco.web.ui.common.component.data.UIColumn,Id: col1][Class: org.alfresco.web.ui.common.component.UIActionLink,Id: col1-act1][Class: javax.faces.component.UIParameter,Id: _idJsp13]}

3. Any files in the AMP will override files in the Data Dictionary
I had a webscript where I needed to make an url configurable. Now, configurations can be added in a modulename.get.config.xml as stated in the documentation. I removed the file from my AMP, and added the file in Alfresco DM –> Company Home –> Data Dictionary –> Web Scripts Extentions –> Modulefolder –> modulename.get.config.xml. And voila, my Freemarker templates caught on the config changes after a restart of Alfresco.

Hopefully this will have saved at least one person from hours of frustration.

Haridasi

About Haridasi

integrity - the state of being whole, entire, or undiminished.
This entry was posted in Technology and tagged . Bookmark the permalink.

One Response to Alfresco: The first lessons learned

  1. Pingback: Helene » Blog Archive » How to create an Alfresco Module Package (AMP)

Leave a Reply

Your email address will not be published. Required fields are marked *