I’m pleased to announce the arrival of a number of significant improvements to the UI framework in Alfresco Share. It will be part of the next Alfresco 4.2 Community and Enterprise releases and is available now in HEAD SVN to try out. Rather than trying to explain all of the details in a single blog post I’m going to start by just going over the concepts of what we’re trying to achieve. Over the coming weeks I’ll be posting more information explaining how it all works and how you’ll be able to make use of it.
Our ultimate aim is to provide a library of widgets that can be easily assembled into a web application for accessing an Alfresco repository. We didn’t want to replace Share but we needed a way to migrate away from the original implementation (based around the Surf paradigms of Templates, Components and WebScripts) towards something faster to develop and easier to customize.
This is summary of what we wanted to achieve:
Those of you that have been following the changes in Share from version 4.0 to 4.2 (Community) will have noticed significant enhancements to the Surf framework and the deliberate refactoring of logic from the FreeMarker template into the JavaScript controller of the Share WebScripts. We’ve also focused on improving page load performance by reducing HTTP requests by:
All of these features are leveraged in the improvements and we believe it will make it easier to produce faster, more reliable pages and in less time for the Alfresco Share and the Alfresco in the Cloud web applications. The improvements build on top of Dojo and provide (with the greatest of respect to the Dojo developers) a couple of significant enhancements…
The first enhancement is a zero build approach. Surf is able to dynamically analyse the JSON model that defines the page being rendered and resolve all JavaScript dependencies that are then compressed and written into a single JavaScript resource that simulates a built Dojo layer. Surf caches all the dependency relationships as it finds them so it never traverses a dependency path a second time. It also caches the individual layers it generates so although the very first page rendered after server start up may take a few seconds to render, subsequent page rendering will be incredibly fast.
When you render a web you are normally expected to take care of the styling via separately referenced CSS files (for example you might import a theme style sheet for the framework that you are using). We’re taking a different approach.
Each widget can optionally define its own CSS resources (including the ability to specify different resources for different media types). If that widget is used on a page then Surf will automatically include those CSS resources within a single aggregated CSS resource loaded on the page. The same principle is applied to localization files so the use of a widget ensures that its NLS properties automatically built into a JavaScript resource loaded on the page. Widgets can scope their message bundles to ensure that there are no collisions and the core message handling function is smart enough to work through all of the message scopes in a widgets ancestry to ensure that the most specific message is displayed.
At Alfresco we believe in using the right tool for the job. Although Share was originally built using YUI2 we have also introduced JQuery plugins and we have no intention of restricting Share to just Dojo. The framework is designed to easily support widgets provided by other libraries and by design we can easily swap out Dojo widgets for those provided by other libraries. We have also provided a mechanism for wrapping our existing YUI2 centric widgets to that they can be referenced in the JSON model for the page. If you go to the Calendar of any Site you’ll see YUI2, JQuery and Dojo all playing nicely together.
One of Share’s greatest strengths is its ability to be easily customized. This is something that we’ve taken great efforts to enhance over the last few releases and is essential that we continue to support. The last significant improvement we made was to make it easier to customize the client-side widgets that are instantiated on each page by customizing the JavaScript controller of a Component WebScript. We’re continuing to support this paradigm but instead of customizing a single coarse-grained widget it is now possible to customize the numerous fine-grained widgets that comprise a page or Component. Widgets can be reconfigured, added or removed easily and because the widgets are decoupled (such that they don’t rely on the existence of other widgets) making changes won’t cause any errors.
At the moment we’ve only used these new capabilities to build a header bar to accompany the “Light” theme that arrived in 4.2 Community. However this is the first step along a longer path towards making Alfresco Share better than ever. Our library of widgets currently only consists of the handful required to construct our header (but already allow you to build your own header or customize the default one without writing a line of JavaScript, CSS or HTML) but as we add new capabilities to Share this widget library will continue to grow. As I promised at DevCon 2012 – we’re not going to discard all the hard work we’ve done over the last 5 years, hopefully this shows our commitment in respect of that goal.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.