Gavin Cornwell

Following my previous post we deliberated about which direction to take, home grown scripts or 3rd party JavaScript libraries. The conclusion is a mixture of both.

A JavaScript library is definitely the way to go for things like Animation effects, rich controls and wrapping the XMLHttpRequest object. Sure, you can do this yourself but someone else has already resolved the cross-browser issues, tested in terms of performance and stability and the library probably has several people constantly improving it. For these scenarios the slight overhead of an extra HTTP request is worth it, but only if the library is modular so you are only including the code you need!

However, for some scenarios, like very simple DOM manipulation, a full featured library can not really be justified. For example, where we only need to parse the XML results from an AJAX request we use the browser’s standard DOM APIs within our own simple library. Conversely, for the more involved functionality we hand over to a 3rd party library i.e. YUI for it’s tree control and Dojo for it’s widget framework, for example.

I think YUI will be our choice of library though whenever possible due it’s modularity. It’s very easy to include just the bits you need and just as easy to determine what they are. As Joe Walker says in the comments of my previous post Dojo does have a “requires” mechanism to just include the bits you need but for this to work you have to include the whole source tree for Dojo as part of your web application (although this may not be an issue for some people). Having someone host the source files is one solution or building your own dojo release is another, but when I tried building my own it didn’t work particulary well, maybe using a tool would have helped? Either way I think it’s a lot simpler to include a single JS file on your page.

Another important factor when choosing a JavaScript library, in my opinion, is the code quality. A common complaint of Dojo is that its API is hard to follow and it lacks decent documentation. The complete opposite is said about YUI, its API is very intuitive and very well documented (useful for those inevitable journies into the source code!).

We’ve only used YUI in a couple of places so far but I’m certain our usage is going to increase in the next few releases.

I spent some time earlier this year investigating some of the more popular JavaScript libraries around. Since the research a number of new libraries have appeared, including the Yahoo UI toolkit and Google’s Web Toolkit. They all have one thing in common, they offer a lot of functionality, but is that a good thing? Together with the functionality required is a lot of excess baggage. For any given scenario (typically a page of an application) only a small subset of a libraries code will be called, so would it not be better to “roll your own” script for each use case?

Personally, I think it depends on the library, if it’s divided up sensibly so that logical areas can be included as and when needed, more advantages are probably gained taking this approach, as a certain amount of testing and cross browser compatability bug fixing has already occurred. Conversely, if all you need is a single AJAX call and a simple animation effect the overhead of downloading a heavyweight library could be a disadvantage.

I’ve recently noticed an increasing trend towards the smaller, leaner approach so I’m interested in hearing what other people’s thoughts are, JavaScript libraries, a friend or foe?

It’s finally arrived!

The first phase of the web client’s AJAX support was checked in over the weekend. A wiki page also exists explaining the parts of the framework.

Please bear in mind this is work in progress so APIs, features and approaches may change without warning!

As always, comments are always welcome.

One of the focuses for the 1.3 release was ease of customisation. These features built on the configuration extension mechanism we added in 1.2.

As mentioned in my previous post a new dialog and wizard framework has been added in 1.3. A majority of the wizards in the web client have been converted to the new framework, this makes it a lot easier to customise the wizards, for example, to add a new action into the Rule Wizard no longer requires changes to the Alfresco files. There are several other example customisations in the wiki.

The Property Sheet has also been significantly enhanced in 1.3. All the components used to represent the properties are now generated using the Component Generator Framework, this allows custom components to be plugged in for properties and associations and the defualt implementations to be replaced. The “show-in-edit-mode” and “show-in-view-mode” atrributes now allow properties to be hidden and properties now adhere to their declaration in the model. For example, if the property is mandatory the OK button will be disabled until it is populated or if a property has constraints (a new 1.3 repository feature) they are enforced i.e. the property has to be in a certain range.

There are loads of other new features in the 1.3 release, check them out!

Up until 1.3 customizing the web client has involved editing our JSP files and in some cases our backing bean implementations. This prevents the upgrade process from being an easy pain free one!

A majority of the screens in web client can be categorized as either dialogs or wizards. In 1.3 we are therefore introducing a configuration driven dialog and wizard framework. This means that eventually more or less every page in the application could be switched for a custom implementation using the overriding features of our config service. Likewise, any page in a wizard could be switched or new pages added in a simple manner.

Unfortunately, to get this flexibility some incompatible changes are being made that will result in some manual migration effort if changes have been made to any of our backing bean classes.

We’re in the process of writing the documentation for the new framework so keep checking the wiki for updates.

To help us help you we would like to get some feedback on the types of customizations you have performed on Alfresco, this will help us channel our energy into the right migration documentation and to guage which areas of the application to make easier to customize sooner rather than later (we may not get time to convert everything in the 1.3 timeframe).

If you live on the ‘bleeding edge’, SVN has the first version of the dialog and wizard framework checked in, the Advanced Space Wizard and Create Space Dialog have also been converted to the new way of doing things.

We’d love to hear your feedback either as comments to this blog entry or preferably on the forums.