There have been a few recent updates to the Spring Surf extensibility capabilities that I’ve been blogging about recently which I thought I should capture in a quick roundup post. These features are currently available in the Alfresco Community 4.0c release.
Improved i18n localization handling
In the original implementation of the i18n extension handling there was a limitation in that it was necessary to explicitly provide extensions for the locale that was ultimately resolved. This meant that there was no graceful degradation of the specificity of locale (e.g. from “en_GB” to “en” to the default properties file). This has now been updated so that all matching locale files will be merged from least to most specific so that extensions can provide a combination of i18n properties files which will all be merged into the WebScript properties file with the most specific overrides “winning”. This update should make it simpler to provide i18n overrides – especially where different region locales might be used to access the same application (e.g. “en_US” and “en_GB”).
Module Auto-Deploy Changes
Originally there were only two ways for modules to be deployed - they would either ALL be deployed automatically or would each need to be manually deployed. It is now possible for a module to request to be automatically deployed if allowed which broadens the choices to the following:
To configure Spring Surf applications to support this new option you should use the following configuration:
…and to make a module request to be automatically deployed, add the following as a child element of <module>
<auto-deploy>true</auto-deploy>
Additional Dependencies
One feature that was already available in the earlier 4.0 Community releases (but not blogged about) was the ability for modules to request for additional JavaScript and CSS dependency resources to be imported. This works in the same way as i18n, JavaScript controller and FreeMarker template customizations in that you need to specify a target package and if a WebScript declared at that package is executed on a request then those additional dependencies will be added as imports to the <head> element of the page.
A module that adds additional dependencies might look like this:
An additional dependency can only be added once even if multiple modules are evaluated successfully that request them.
Updated Module Deployment Error Handling
There have been some updates to the module deployment code to provide better handling of errors. One of the main problems that can occur when deploying modules is that different authentication mechanisms are used for WebScript and remote client calls. This means you might be authenticated to access a WebScript (i.e. the module deployment script) but not to actually persist changes to the remote client. The end result would be that modules might be deployed in application memory but would not survive a server restart. There are now clearer error messages to indicate that this is happening and could occur for other reasons (for example the Alfresco repository might be down). You might also notices that on server start-up some errors are shown in the log indicating that module settings could not be saved - this isn't actually a problem (previously persisted changes won't be effected), but is something that we're hoping to resolve. In the meantime it should at least be clearer when using the deployment WebScript when problems have occurred.
Improved i18n localization handling
In the original implementation of the i18n extension handling there was a limitation in that it was necessary to explicitly provide extensions for the locale that was ultimately resolved. This meant that there was no graceful degradation of the specificity of locale (e.g. from “en_GB” to “en” to the default properties file). This has now been updated so that all matching locale files will be merged from least to most specific so that extensions can provide a combination of i18n properties files which will all be merged into the WebScript properties file with the most specific overrides “winning”. This update should make it simpler to provide i18n overrides – especially where different region locales might be used to access the same application (e.g. “en_US” and “en_GB”).
Module Auto-Deploy Changes
Originally there were only two ways for modules to be deployed - they would either ALL be deployed automatically or would each need to be manually deployed. It is now possible for a module to request to be automatically deployed if allowed which broadens the choices to the following:
- Automatically deploy all modules
- Only automatically deploy any modules that request it
- All modules must be manually deployed.
To configure Spring Surf applications to support this new option you should use the following configuration:
<module-deployment>
<mode>manual</mode>
<enable-auto-deploy-modules>true</enable-auto-deploy-modules>
</module-deployment>…and to make a module request to be automatically deployed, add the following as a child element of <module>
<auto-deploy>true</auto-deploy>
Additional Dependencies
One feature that was already available in the earlier 4.0 Community releases (but not blogged about) was the ability for modules to request for additional JavaScript and CSS dependency resources to be imported. This works in the same way as i18n, JavaScript controller and FreeMarker template customizations in that you need to specify a target package and if a WebScript declared at that package is executed on a request then those additional dependencies will be added as imports to the <head> element of the page.
A module that adds additional dependencies might look like this:
<module>
<id>Add dependencies</id>
<customizations>
<customization>
<targetPackageRoot>org.acme</targetPackageRoot>
<dependencies>
<css>/res/demo/dependencies/styles.css</css>
<js>/res/demo/dependencies/script.js</js>
</dependencies>
</customization>
</customizations>
</module>An additional dependency can only be added once even if multiple modules are evaluated successfully that request them.
Updated Module Deployment Error Handling
There have been some updates to the module deployment code to provide better handling of errors. One of the main problems that can occur when deploying modules is that different authentication mechanisms are used for WebScript and remote client calls. This means you might be authenticated to access a WebScript (i.e. the module deployment script) but not to actually persist changes to the remote client. The end result would be that modules might be deployed in application memory but would not survive a server restart. There are now clearer error messages to indicate that this is happening and could occur for other reasons (for example the Alfresco repository might be down). You might also notices that on server start-up some errors are shown in the log indicating that module settings could not be saved - this isn't actually a problem (previously persisted changes won't be effected), but is something that we're hoping to resolve. In the meantime it should at least be clearer when using the deployment WebScript when problems have occurred.
18 Comments
We use cookies on this site to enhance your user experience
By using this site, you are agreeing to allow us to collect and use cookies as outlined in Alfresco’s Cookie Statement and Terms of Use (and you have a legitimate interest in Alfresco and our products, authorizing us to contact you in such methods). If you are not ok with these terms, please do not use this website.