Make it sparkle with Ajax

Mark Newton Read more October 7, 2009

I get a lot of email from readers who are frustrated at the difficulty of implementing Ajax in their latest web application projects. Even sizable companies seem to be avoiding adding Ajax functionality for the time being, and when I speak to them about future developments they all claim they’re “looking into Ajax”, but not too much else is forthcoming. One of the reasons for this hesitancy is an apparent lack of good design and debugging tools for Ajax. As is often the case with newly emerging technologies, the development process can be slow and clumsy – let’s face it, even debugging JavaScript, which has been around for years, is still a non-trivial exercise. You’re often forced to resort to adding “alert” boxes that pop up to show variable values in an attempt to see why things aren’t working the way they should. One way to ease the development cycle is to use pre-built libraries of functions that you can call from your own code, the benefit being that the library code has often been optimised to work with all the browsers and most of the bugs have been ironed out. The drawback to using libraries is that they can be large and their code convoluted, which can lead to slower page-load times.

Another thing to ponder when considering using Ajax is just how and where it will benefit your users most in your web application – not all areas can benefit equally from Ajax, even though some can be transformed by a little thought and a few snippets of code. Most of us trawl the internet looking for help with such tasks, but I often find having a good book on the subject can help enormously. One such book I can recommend is Adding Ajax from O’Reilly, which covers the use of many of the Ajax libraries such as Prototype, Script.aculo.us, Rico, Dojo, jQuery, MochKit, YahooUI, mooTools and moo.fx, Sarissa and WZ_jsGraphics. The book also covers writing your own Ajax effects without the use of libraries, and it’s a very valuable aid to have by your side (or even to read on holiday while dreaming of the cool web application you’re going to build when you get back).

If you want to add some alternative Ajax functionality to your website, you couldn’t do much better than to look at all the samples at http://miniajax.com, which are really very good and generally easy to implement. It will certainly give you plenty of ideas, but please don’t make the mistake many people made with animated GIFs in the early days of the web and overdo it.

Spry and Spry again

One Ajax library that I haven’t mentioned yet (and nor does the O’Reilly book) is called Spry, from Adobe. The documentation is good and it isn’t too difficult to use this library, but it’s a case of adding code manually, or rather it was until now. The latest version of Dreamweaver, called CS3 in line with the other Adobe products, now has support for the Spry Framework among several other new features.

In fact, it’s worth taking a quick look at a couple of the new features in Dreamweaver, which for my money make this upgrade worth the cost. First, as just mentioned, is its support for Ajax in the form of the Spry Framework: to use these features, simply click on the Spry tool bar and a dialog opens into which you enter the details – and that’s about it, your first piece of Ajax!

So what features does the Spry Framework give you? First, there’s a simple collapsible panel that enables page content to be hidden and expanded again whenever the user clicks the panel’s top bar. This content is still on the page, so you’re not saving anything in page file size, but it’s an interesting way to cram a lot of content into a smaller area of the browser window. The Accordion object is a slightly more complex version of this component, which allows multiple collapsible areas.
Then there are the inevitable Tabbed panels objects, and Vertical and Horizontal Menu objects that allow you to build dynamic drop-downs in a simple way. These are greatly preferable to some other menu builders, which, while flexible and functional, often generate code that’s impossible to understand or edit outside the builder program, giving rise to integration problems if other people need to edit the content later on.

The next set of four Spry objects are validation objects for forms, used to make sure the user has entered data correctly onto a web form. Obviously, this validation should be done server side, after the user clicks Submit and the next page is called from the server, but it can give a much better user experience if some validation is done before the next page is called, which is known as client-side validation. This gives the user immediate feedback about a wrong or missing entry, without which they’d have to wait for the “round trip” time of the server fetching the next page. These Spry validation controls allow only very basic validation at the “is the textbox empty” level, with no tests for valid data (such as testing for well-formed email addresses or numeric values within range). It’s important to still do the server-side validation after the Submit button has been clicked, because the user’s browser may have JavaScript disabled, in which case the client-side Ajax validation code wouldn’t run.

The final set of Spry objects included with Dreamweaver CS3 works on sets of data and consists of the usual datagrids, connection objects and data repeater areas: these work well, giving client-side sorting and refreshing of data grids without needing the whole page to be redrawn. A point worth noting here is that these objects expect to work with XML datasets, and all the examples provided hold their data in a series of XML files, which isn’t really a very convincing demonstration. Let’s face it, if you were designing a website with dynamic content, there’d be a database somewhere and it’s that content you’d want to display. So if you wanted to use these Spry objects, you’d either have to create a web service to query your database and return an XML data feed, or else perhaps use a newish addition to the syntax of SQL Server that converts any query so as to return an XML data stream. If you want the query “SELECT * FROM MYTABLE” to return an XML data stream, then all you need to do is change its syntax to “SELECT * FROM MYTABLE FOR XML AUTO” – it’s as simple as that.

Dreamweaver CS3

Now we come to perhaps the best and most worthwhile feature of Dreamweaver CS3. I’ve complained in the past about how useless Dreamweaver has become for designing and testing websites with complicated CSS designs. The problem has lain in the rendering of the HTML/CSS in Design View, which is handled by Macromedia’s (as it was them back then) custom browser object. This object would easily be confused by many perfectly valid CSS designs, making Dreamweaver almost useless not only for creating such designs, but also adding content later on.

Often I’d end up using Dreamweaver just as an expensive text editor, while checking my design in a separate browser pointed at the relevant file. I’m delighted to report that this latest version has been improved beyond measure, now making Dreamweaver once again my CSS design tool of choice, after having tried many others on both Windows and Mac platforms.

Obviously, final testing of any site still needs to be done with the various popular browsers to make sure all is well, and to ease this task I’ve recently upgraded my main development box to an Apple Mac Pro with a 750GB hard disk, 4GB of RAM and two dual-core processors. With the simple addition of Parallels software (web ID: 92176), I can run Mac OS X and Windows simultaneously. And rather than Windows running in its own window on the Mac desktop, when you use Parallels’ Coherence mode the two operating systems share the same desktop, with the file system and Clipboard also shared between them, so it really feels like two operating systems rolled into one. Finally, on a single box I can simultaneously have all the major browsers open to test a CSS design, which has transformed the way I work. However, I hope I’m not turning into one of those boring Apple evangelist types (I can be boring enough in Windows) and still use Windows for most of my development. Basically, I use whatever OS program is best for the job, which in my opinion is the way it should be.
Stylish extensions

It’s the designing of the stylesheets for a website that usually takes up most of the time: get them right and all the content seems to just flow into your site; get them wrong and you’ll be trying to patch things up for months afterwards. Getting a stylesheet to work correctly in all browsers can sometimes be tricky – you need to consider all sorts of stuff like whether the web page should scale with the browser window or be a fixed size, and how your design will handle the user’s browser being set to a larger or smaller size than the default. These are just a couple of the questions you need to ask yourself and try to resolve at this stage of the design, so any help in this department is always welcome.

So when I heard of a Dreamweaver extension called CSS Sculptor by WebAssist (www.webassist.com), for creating and editing CSS files, which has Eric Meyer’s name on it, it sparked my interest. Meyer is a well-respected CSS expert, so to have a tool that would produce CSS sheets he was happy with must be a good starting point for any design. The interface is a little clunky when it applies a change in styles, but its preview seems to be accurate. I’d have preferred the ability to resize the dialog box, so that I could more easily see the effect of my changes without having to preview in a browser window, but that’s a very small criticism. The stylesheets that it produces are neat and easy to understand, with optional comments. What I particularly liked was that CSS Sculptor prompts you to style all the standard sort of things like the

,

tags as well as the link styles, and a particularly nice touch is that it will automatically produce a stylesheet for when the web page is printed out, so you can decide which areas are to be printed and which are not. The extension is available from www.pcpro.co.uk/links/158webapps2, and at £75.74 it represents very good value given the time it can save you.

Content mis-management?

While heavyweight tools such as Dreamweaver are great for designing and maintaining websites, they’re often far too complex a solution for end users who just want to update the content of their site. With this in mind, and a particular client’s request, I set out to investigate some of the many CMS (Content Management System) packages and web-based in-line HTML editors on the market.

There are many open-source offerings as well as commercial products, and I spent many, sometimes frustrating, weeks investigating and installing loads of them, but I still feel I’ve only scratched the surface. Most of them, in my opinion, suffer from the problem that to be flexible they end up being too complex – most users want an easy way to edit their web content without having to learn another complex tool. The other failing of CMSes is that they don’t show the full web page in their editing view, so the user has to know that to put some text into that left-hand area of the page you need to edit an area called “LH_Content” or similar.

Someone on the blogs summed it up quite succinctly when they said that most CMSes were in effect database management systems, as all the content is held in a database and “poured” into web page templates. There are, of course, many benefits to this method, but it seems to me that many CMSes have lost the original vision of making content editing easy, and have become too concerned with extra features.
HTML without HTML

I’ll be returning to this topic in a later column, but for now let’s look at one very important part of such systems, which is the control that allows a user to enter HTML objects easily without having to write HTML code, via a wysiwyg environment with multiple toolbars containing buttons. These controls are known as HTML in-line editors and they sit “over” a “Textarea” on a web form, so that when the form is submitted the contents of the text area are sent with the rest of the form control contents, usually to a database. The quality of these in-line editors varies considerably, as do their features. At first glance, they all seem very similar, but as you start to use them you soon discover their limitations. I looked at some open-source ones and was particularly impressed with Xinha (http://xinha.webfactional.com/wiki) and, of course, with one of the market leaders that’s been around for some time with the rather risqué name of FCKeditor (www.fckeditor.net).

This time, though, my client wanted to be able to copy and paste Excel data while retaining its formatting, a task that most of these HTML in-line editors couldn’t handle in a satisfactory way. I also wanted to be able to programmatically control a lot of the configurable items, and it needed to support editing only in editable areas of templates, so that the end user couldn’t mess up the page layout. In the end, I bit the bullet and bought the rather excellent Rich Editor from www.richarea.com, paying $199 for the full licence, rebrandable version, although prices start from as little as $49. A deciding factor in my choice was the excellent support offered by way of email and forums, something that’s at the top of my list of priorities. It’s very frustrating, and can be expensive, too, to hit a serious problem in the middle of development and take ages to get a solution for it. This control is available in PHP, ASP and .NET versions, and it should be on your list to look at if you’re shopping for such tools. Now I’m off to write that world-beating CMS: after all, I have a couple of hours spare this week!