Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2012 > March

Twitter Dashlets 2.5 Released

Posted by wabson Employee Mar 8, 2012
If you've tried Share Extras's Twitter add-ons recently then you might know that the Twitter Dashlets add-on for Alfresco 4 bundles up two similarly-named add-ons that I released last year.

Using the dashlets that the add-on provides, you can follow a particular user or Twitter list, or follow the results of a Twitter search, direct from your Share Dashboard. Great for monitoring the results of a social media campaign related to a particular site, or just topics that are important to you.

But the dashlet that I'm now using the most is the Twitter Timeline dashlet that allows you to easily connect to Twitter's authenticated resources via OAuth, which I showed at last year's Alfresco DevCon.

Release 2.5 tidies up a number of bugs but more importantly now provides a consistent experience across all three dashlets, in a couple of areas.

You can view a short video of the updated dashlets or submit feedback on the Share Extras site.

Authenticated access

The Reply, Retweet and Favorite actions were always present on the Twitter Timeline dashlet but now also appear  on the other dashlets too, if you have previously connected your Share user  account to a Twitter profile.

Twitter dashlet actions

This has the added benefit that you will be able to view the  protected tweets of any users you follow in the Twitter Feed dashlet,  since requests will always be authenticated whenever you are connected.


All three dashlets will periodically poll for new Tweets, and the notifications have been made more compact and added into the dashlet title bar

Twitter Timeline notifications

To load the new tweets, just click the green notification icon.

More options for Search results

The Twitter Search dashlet now allows you to choose between recent tweets, 'top' tweets as rated by Twitter, or a mix of the two.


In my last blog post I described the new DependencyHandler service that has recently been added to Spring Surf.  Whilst its primary purpose was for appending checksums to JavaScript and CSS dependency requests to ensure that browsers did not use stale cached data, it does have another interesting capability.


Enhancing the performance of web applications has become increasingly important as they have become increasingly complex.  Ultimately most of these performance enhancements boil down to either reducing the amount of data required to render a page or reducing the number of HTTP requests required to download that data. Minifying text based resources and the use of GZIP on the server are obvious examples of reducing bandwidth and whilst minifying images is not an option (beyond regular compression) you can reduce the number of HTTP requests required by using CSS sprites. This is all well and good if you’re starting a new web application from scratch and can make sure you adhere to all the best practices from the start,  it’s not always so easy to retroactively apply these practices to a mature project. Share makes good use of minification but there is scope to improve the number of HTTP requests made for resources.


One of the big advantages of Share is how easily it can be customized to satisfy requirements but the disadvantage of this is that we need to do our best to support all the various customizations that exist out in the wild. So whilst we could spend a long time converting all of our individual images into one giant CSS sprite there’s a very good chance we could break a lot of other developers customizations.


Another option that is available is to actually embed the data for each image into the CSS files that reference them. Whilst not wanting to get involved in the various discussions about which approach is better, based on our requirements it is clearly the better choice for us.



Configuration and Example

Surf can now automatically produce CSS data images by simply adding the following line to its configuration file (for Share this is located at this can be found in the “webapps/share/WEB-INF/surf.xml”)







Providing that checksum dependencies are also enabled then all images reference by CSS files will be embedded as data within those CSS files. This offers the additional benefit on top of the reduced number of HTTP requests in that when an image changes, the CSS checksum will change so it will not be possible for the browser to use stale cached images. The DependencyHandler service defers some of this work to a dedicated 'CssDataImage' service which can be overridden in the Spring application context if required. All images are cached for the life-cycle of the server so that performance is not impeded when requesting the same image multiple times.


The following screenshot shows the Chrome Web Developer Tools displaying some images from a page in Share with CSS data images enabled:




The main limitation as far as Share is concerned is that we haven’t used CSS styles throughout the application. There are still some uses of the <img> HTML element which won’t be affected. However, at the end of the day there will be less HTTP requests than before so hopefully performance should be improved as a result. The only other limitation is that CSS data images are not supported by Internet Explorer versions 6 and 7 (but then if you're still using either of those then this will be the least of your performance concerns!)  so Surf will check the user-agent data though and not perform the conversion for those browsers.


More Reading

More information on CSS Data Images can be found here:

Please note: The following features are at the time of writing only available in the Alfresco Community source code and have not as yet been included in any release.


One of the problems that has affected upgrades of Alfresco in the past is that the end-users’ browsers may end up using cached copies of JavaScript and  CSS files that have been updated during the upgrade.  Spring Surf now has introduced a new service called the “DependencyHandler” which has been created to solve this specific problem. It does this by appending a unique checksum to the end of each requested JavaScript and CSS dependency where the checksum is generated from the contents of the file and so will change whenever the file content is changed. The checksum associated with the file is cached for the lifecycle of the web server meaning that it does not need to be generated for each request and Surf performance has actually been enhanced by this mechanism because Surf also caches the location from which the dependency is retrieved (Surf can retrieve dependencies from a number of different locations, e.g. JAR files, class path, file system, remote location, etc.).

Configuration and Usage

By default the capability is disabled in Surf but will be enabled in future releases of Alfresco Share. To enable is you simply need to set the following line within the Surf configuration (this can be found in the “webapps/share/WEB-INF/surf.xml”):






In order to make use of the dependency handler you will need to use  the <@script>, <@link> and <@checksumResource> FreeMarker directives in your  TemplateInstance and WebScript files, e.g.

<@script src='${url.context}/res/yui/yahoo/yahoo.js'></@script>

<@link rel='stylesheet' type='text/css' href='${url.context}/res/css/base.css' />

<@checksumResource src='${url.context}/res/css/ipad.css'/>

(Those examples are taken from the resources.get.html.ftl file  where the ${url.context} is a FreeMarker variable set to the application  context, e.g. “share”)

  • <@script> generates JavaScript script import declarations.

  • <@link> rolls up multiple CSS requests into a style declaration using a separate '@import' statement for each usage of <@link>.

  • <@checksumResource> generates just the URL (i.e. without being specific to CSS or JavaScript and can therefore be used with images or even WebScript requests. One additional feature of the <@checksumResource> directive is that you can specify the attribute 'parameter' which makes the checksum appear as the value of a request parameter of the supplied name (rather than as part of the file name itself).

Debug and Production Suffices

The DependencyHandler is capable of dealing with production (minified) and debug versions of files and actually handles these better than before. The Spring application context configuration for the bean allows you to specify the different file suffices that can be used for both production and debug versions and the DependencyHandler will work through the options until it finds a file. This means that Surf will always be able to fall back to the debug version of the code if a minified version does not exist. By default the debug suffices are:

  • “” (i.e. no suffix)

  • “_src”

  • “-debug”

And the production suffices are:

  • “-min”

  • “-minified”

  • “” (i.e. no suffix)

You can change these suffices by overriding the definition for the “dependency.handler” bean in the Spring application context in case you want to add, remove or re-order the default entries.


The following screenshot shows the Chrome Developer Tools window displaying the JavaScript resources loaded for a page in Alfresco Share - note that each request is appended with a checksum value (apart from 'tiny_mce.js' which handles its dynamic dependencies in its own way).

Current Limitations

The current limitation of this solution is that it only works with static requests from the page and not dynamic requests made from a script – although many JavaScript libraries provide their own solution to this problem (e.g. TinyMCE) however it is something to be aware of.
Please Note: This post refers to recent updates to the Alfresco Community source – at the time of writing these features are NOT available in any current Alfresco release.

We’ve added a new capability to the Spring Surf extensibility that allows modules to make dynamic changes to the configuration service. Alfresco Share uses the Surf configuration service extensively to control its behaviour (check out all the files ending with the suffix “-config.xml” in the “shareWEB-INFclassesalfresco” directory) and up until now it’s only been possible to make changes to this configuration between server restarts.

To make a module provide additional (or replace existing) configuration you simply need to add the configuration within a  element in the module configuration (apologies for the overuse of the word “configuration” there!)

Here is an example module that replaces the Document Library configuration for Flash enablement for any site with the name “noflash” (the section in green is the important part - I'm using the 'out-of-the-box' site evaluator to only apply the module to sites with the name 'noflash' that were created using any preset).





         <description>Applies config based on site id</description>

         <evaluator type='site.module.evaluator'>







            <config evaluator='string-compare' condition='DocumentLibrary' replace='true'>










The original configuration can be found in the file “shareWEB-INFclassesalfrescoshare-documentlibrary-config.xml”. The screenshots show the resulting upload dialog when accessed from the Document Library of two different sites, one called “flash” and the other “noflash” (after the module has been applied obviously - see earlier posts for more information on this)

Screenshot of Share showing the Flash uploader

Screenshot of Share showing the HTML5 uploader

It’s important to note that when replacing configuration that you will need to preserve any existing configuration from the original that you don’t want to lose. For example – I’ve kept the “in-memory-limit” setting because it would otherwise have been lost as part of the replace.

Equally if you don’t specify the “replace” attribute as true then you will only ADD additional configuration and it’s possible that your configuration change won’t be observed because it won’t be the first element found – i.e. if  the “replace” attribute was not set in my configuration the end result would be:





…and when the Document Library code accessed the configuration it would detect Flash as enabled as the first “adobe-flash-enabled” element would be returned. If you’re familiar with overriding configuration in Alfresco through static files on the “web-extension” path then this shouldn’t be a surprise to you as the behaviour is identical – however, I thought it would be worth mentioning in case it takes people by surprise.

Filter Blog

By date: By tag: