Extensibilty Updates Roundup

cancel
Showing results for 
Search instead for 
Did you mean: 

Extensibilty Updates Roundup

Intermediate II
0 18 1,958
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:



  1. Automatically deploy all modules


  2. Only automatically deploy any modules that request it


  3. All modules must be manually deployed.


This new option was introduced to support the forthcoming Records Management module and the Cloud offering. By default Alfresco remains configured in manual mode but the Records Management module will be able to override the default configuration to switch to “enable-auto-deploy” mode when it is AMPed in.



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
Active Member
Dave, I love your blogs, but the width of the text is fixed. Could you make it to automatically extend or wrap around to the size of the window? It's around 1,000 pixels wide.
Active Member
Thank you!
Active Member
[...] d’Alfresco Share 4.0 lorsque j’ai pris connaissance du post de David Draper : Extensibilty Updates Roundup, où le sujet est traité. Tout est déjà dit sur la partie déploiement automatique, reste que [...]
Active Member
Hi David,

Could you please clarify in which file the new xml snippet (containing enable-auto-deploy-modules) should be placed? In the custom slingshot xml context file?
Active Member
Well, I guess that xml snippet mentioned above goes into the share-config-custom.xml...
Active Member
Great to see the improvements still rolling in! But when you say

'An additional dependency can only be added once even if multiple modules are evaluated successfully that request them'

Do you mean only one set of dependencies can ever be added to a target package, or that a dependent asset can only ever be added once, even if multiple modules try to add it?

Cheers,
Will.
Intermediate II
@Erik.... it can go into the 'slingshot-custom-config.xml' file (and technically it can go into any configuration file that is declared in the 'webframework.configsource' bean, if nested within:


<config evaluator="string-compare" condition="WebFramework">
    <web-framework>
    </web-framework>
</config>


@Will...  it just means that no matter how many modules request a dependency it will only be requested once for the page (i.e. you won't have lots of script elements importing the same file, etc)
Active Member
Great, that's what I hoped, thanks
Active Member
Dave, many thanks for all these great tutorials. Just finished playing with all of them and is really impressed how flexible Share is now. Special thanks for enable-auto-deploy option. We use jars to package extensions, so can I add this XML block to META-INF/share-config-custom.xml and after it jar with Share customizations becomes completely 'self-activating'.
Intermediate II
Thanks for the feedback Alexey, it's very much appreciated. I'm glad you like the updates - and we're not done yet, either! Smiley Happy
Active Member
@ddraper, btw, when I use auto-deployed modules I see in catalina.out for each of them: 'Could not save module deployment for: %modulename%'. Everything works, but this message is logged as error. Did I miss smth with configuration? Or is logger just wrong with loglevel for this message? :-)
Intermediate II
@Alexey... the message is a genuine error but at start-up this is nothing to worry about. Under the covers the the Share application asks the Repository application for the details of any modules that were previously applied (this get request can be done without authentication) then Share looks its current configuration settings and attempts to apply back any changes (for example, if it has been reconfigured into auto-deployment mode or new auto-start modules have been made available). At this stage Share does not have any authority (because the request isn't associated with any user) to persist these changes and the error message is generated.

This isn't actually a problem as Share cannot 'undo' any previously persisted data, and even if switched into automatic deployment (or new auto-deploy modules) are available then the same modules will still be deployed with each restart (until an Admin actually persists some other changes).

So the error message isn't anything to worry about - we don't want to get rid of it as it is useful in other circumstances - but is something we would like to improve in the future.
Active Member
A cool feature to load extra deps!
I tried this with targetPackageRoot org.alfresco to load some js on nearly all pages, but this is not the case.
Also an error message is logged with 'sourceTargetPackageRoot is required'.

Any pointes on the syntax maybe? thx.



   Add dependencies
  
     
         org.alfresco
        
            /res/demo/dependencies/styles.css
            /res/demo/dependencies/script.js
        
     
  
Intermediate II
@Lothar A 'sourcePackageRoot' element is required for customizations although isn't actually required for dependencies. I think this has now been fixed - what version of Alfresco are you working from?

You should be able to work around this problem simply by adding an empty 'sourcePackageRoot' element at the same level as the 'targetPackageRoot' element.

Let me know if this doesn't work,

Thanks,
Dave
Active Member
Version in use is 40dCE. I tried this with some different sourcePageRoot values (same value, different value), but the dependend js are not included. A debug session showed that everything is correctly parsed in the corresponding model objects. However I did not yet debugged down to the controller who evaluates the modules.

As a workaround I could a subcomponent to the global scoped header region.
Active Member
Hi all,

hi Lothar i have the same problem, i need modify only javascript ( client side ) of search result page.  how you solved it?

i declared only new dependencies in my xml file.

Thanks a lot.
Active Member
Hello Dave,



thanks a lot for this blog, just one question:



Is it possible to extend webscript files, like: *.get.config.xml using Surf extensibility approach or another nice way?



Very good example is this config file:

site-webscripts/org/alfresco/components/preview/web-preview.get.config.xml



Currently it's only possible to change it by copying and modifying the original file to web-extension/site-webscripts/org/alfresco/components/preview/web-preview.get.config.xml), but it means lot of code duplication and merge conflicts by the next version update.





Thanks in advance



Best regards

Vitali
Intermediate II
@Vitali - there are no plans to add support for providing extensibility to WebScript *.config.xml files. This is primarily because the configuration provided by them can only ultimately be used by the controller to build a model and it is easy to extend the controller to modify the model. Also, we're trying moving away from using *.config.xml files now for future WebScript devlopment in Share.



Regards,

Dave