Whilst preparing for a Tech Talk Live presentation on customizing Alfresco Share I realised that there was another extensibility capability that I’d not actually blogged about. This was a feature that had been requested internally and will be available in Alfresco Enterprise 4.0.2 and is in the latest Community source code on SVN.
If you look in the “webapps/share/WEB-INF/classes/alfresco” folder of your web server hosting Alfresco then you’ll notice a number of files ending “-config.xml” (i.e. “share-config.xml”). These files contain configuration that is loaded into a Spring bean when Alfresco starts and is accessed by Share code to dictate many different aspects of its behaviour. This is purely static configuration in and changes to the files will only be applied with a server restart.
However, it is now possible to dynamically control the configuration through the use of extension modules. A module configuration file now supports the element which allows you to change the configuration without restarting the server by deploying and un-deploying modules or to use evaluations to determine when specific configuration is applied.
Let’s say that you want to use the Flash uploader for some sites and the new HTML5 uploader for others. The Flash uploader is normally only used when Flash is enabled in the “share-document-library-config.xml” file.
However if we create a module with the following configuration:
<id>Site Conditional Flash Upload</id>
<description>Applies config based on site id</description>
<config evaluator='string-compare' condition='DocumentLibrary' replace='true'>
We are able to disable the Flash uploader for the site called “noflash”. The evaluator used is available “out-of-the-box” and for further information on evaluators read this post. The element contains a copy of the configuration taken from the “share-document-library-config.xml” file but changes the default <adobe-flash-enabled> value from “true” to “false”.
The configuration is only applied when the module is deployed and the user is uploading to the Document Library in the “noflash” site (see the screenshots below).
It is important to note that the same rules of statically extending configuration apply here, i.e. that it is not an augment capability. Note that I have had to include the <in-memory-limit> element even though it has not changed, because otherwise it will be lost. If the “replace” attribute were removed from the <config> element then the result would be that two <adobe-flash-enabled> elements will be included in the configuration and it would almost be guaranteed that only the original statically defined element would be used.