Progressive-Coding.com

News: Weekly wroundup

The last week was rather quiet and while I'm still working on a major project about Rich Internet Technologies comparison, I didn't stumble over a particularly interesting part that would be worth mentioning here. Over the next days, I might release some of the documents that I wrote about RIA, such as the actual comparison methods, the result evaluation and the data types and storage methods used.

Since the launch of this site, one of the most popular resources is the Advanced Encryption Standard tutorial. While it might not be the most interesting subject and might not attract the broadest audience, I think that the quality of the tutorial is among the best you'll find on the Internet about AES. I am particularly pleased that Josh Davis used my tutorial as a starting point to implement JavaScript AES. He kindly contacted me and asked permission to use my tutorial and since everything on this page is released under the GNU Public License, he was free to use and modify the code as he pleased.

Finally, if you keep yourself updated in Rich Internet Technologies, you might be interested in hearing that SUN announced JavaFX. Especially JavaFX Script might become popular among the Java community, since Java is still a little too heavy to use for small web applications.

News: How to correctly use the power of widgets in Ajax

Over the last few weeks, my research on Rich Internet Applications was particularly focused on the increased accessibility that is provided through the use of expressive GUI widgets and how these widgets can be implemented in the different technologies, and more specifically Ajax. Before elaborating on that particular problem, it is important to first explain the basic concepts of what exactly is a widget and why it is useful in Computer Science.

According to the Wikipedia definition,

A widget is an interface element that a computer user interacts with. [...] Programmers use widgets to build graphical user interfaces.

This means that widgets are the interactive elements of a computer program, that serve as an interaction medium, a link, between the user and the program. The user is limited in his actions and intentions by the possible widgets that are at his disposal, restricting his expressiveness to the different values the widgets may have.

The standard HTML widgets

Since our particular interest lies within the domain of Internet applications, let's analyze what widgets are at our disposal, using the latest HTML 4.01 specifications provided by the W3C. There are basically three different categories of elements that can be used as widgets, which are the INPUT, the SELECT and the TEXTAREA elements. The INPUT element has an attribute called type that specifies the type of control to create, which can take the following values: text, password, checkbox, radio, submit, image, reset, button, hidden and file. While this list, dating back to December 1999, provides, from a Human Computer Interaction perspective, enough means of interaction within a web application for every basic operation, it is by no means impressive and definitely not worthy of being called Web 2.0. If we compare this list to the widget list on Wikipedia, which has over thirty different types of widgets, we immediately notice the need for better widgets, that provide additional interactive possibilities and better customization.

Accessibility guidelines

Unfortunately, creating new widgets isn't as easy as it might sound. Simply throwing together graphical elements with several event listener might be functional, but doesn't correspond to the modern accessibility criteria, explained in the Web Content Accessibility Guidelines 1.0. These guidelines explain how to make web content accessible to people with disabilities but also more available to all users, whatever user agent they are using. In the HTML techniques for Web Content Accessibility Guidelines 1.0, the most important sections concerning self-made widgets are the Forms and the Scripts section, which are directly applicable to our intention to code our own widgets. The Forms section basically describes all the features that an interactive widget should have to make it as accessible as possible, ranging from keyboard access to labeling form controls and providing a text equivalent for every non-text element. The most important section in the scripts section is that one should ensure that dynamic content is accessible or provide an alternative presentation. This is commonly referred to as graceful degradation, or the ensuring that pages are accessible with scripts turned off or in browsers that don't support scripts. One might argue that these guidelines date back to November 2000, when Rich Internet Applications were less common and that nowadays most users have scripting support turned on. Imagine what would happen to the whole Flash world if these guidelines had to respected à la lettre. I'm not saying that we should change the whole widget concept because of these guidelines but we shouldn't completely forget about them either. I think that Accessibility is a very important subject and that we should try to make the web as accessible as possible. A good example for widget design principles can be found in the dojo toolkit, in the Dojo Book chapter Dojo Widget Design principles. I strongly recommend everyone to read those principles and at least intent to adapt them as closely as possible.

Widgets 1.0 Draft

The Rich Web Clients Activity Working Group is currently working on the Widgets 1.0 Draft, that covers the packaging format, the manifest file and the scripting interfaces for working with widgets. They refer to widgets as "small client-side applications for displaying and updating remote data, packaged in a way to allow a single download and installation on a client machine. The describes widget object is based on Apple's Dashboard and is intended to provide a standardized interface to self-made widgets in the future.

Unfortunately, the Widgets 1.0 format is only a draft, a work in progress, and if you are familiar with the working speed of the W3C, it is safe to assume that this won't be applied in the near future, which means we are on our own. In the next chapter, I will cover the general concept of creating widgets in Ajax, based on my experience over the last few weeks, where I spend the major portion of my time with this particular problem. Before you even consider coding your own widgets, I ask you to please carefully consider if you're doing so to increase the functionality of your interface or only for the sake of the technological aspect. Design should always primarily focus on the user experience and never be guided by the implementation challenges or the technical aspects. If the interface doesn't gain any additional functionality, your web applications will get worse if you implement your own widget. Not only aren't you using any of the standardized widgets which are fully compliant to the accessibility guidelines, you're probably also reducing the number of potential users by keeping them from interacting with your widget in non-browser user agents.

Widgets in JavaScript

I'm not going to focus on JavaScript frameworks, that already provide widgets. If you are looking for working implementations where you only have to add some lines of code to your page, then I recommend that you use the framework of your choice, but if you want to truly understand the design and implementation challenge and maybe implement your very own widget, then please continue reading. As I explained in great detail in my tutorial about creating an Ajax rating widget, the starting point for a widget is a standard DOM element, that is modified in JavaScript. Any element can be used, but if we respect the Accessibility guidelines, we have to make sure that our web application is still functional if scripting support is disabled. If we use a div container and the user has JavaScript disabled, then he won't have any interaction possibility since he'll only be presented by an empty container. As long as you ensure that there is any of the standard interaction widgets, you can use whatever you like. A good choice would be to use one of the standard widgets that is as close to what you want to achieve with your own widget as possible. If your widget is intended to only provide two different options, don't use a text field as the fail-safe replacement, since the user will likely enter a non-conform value; rather use a select menu with two options or radio buttons. You can also wrap the standard widget with a div container and remove all the child nodes of the container before inserting your own. That way, you have a good starting point to insert your widget into and you can work in a very specific subtree of the HTML DOM tree without the risk to delete something that wasn't intended to be deleted.

I won't enter into the details on how to create your own widget, the rating widget tutorial should have covered that section enough. What I want to focus on is a more delicate subject, that wasn't much of a problem during the design of the rating widget. In fact, the rating widget is designed to be used as a stand-alone widget, that issues a request upon interaction and never has to interface with other parts of the web application. While this is the generally accepted behavior of a rating widget, most widgets are user to communicate a value from the user to the application. They provide several interactive features which are translated into a value that can be used by the program to determine what the user has entered. This can be a state as in the case of a checkbox, that can be check or not, or a numerical value, as in the case of a slider. The value of the standard widgets are used during form submission, where each successful control generates a (control name, current value) pair that is transmitted in the form data set. This is a serious problem that requires additional methods to make our widget functional. Even though are widget by itself is able to handle user interaction and store its value somewhere, it isn't recognized by the user agent as a form element and thus that value isn't transmitted to the processing agent.

Implementation methods

To deal with this situation, several methods exist, of which I want to explain two. The first one uses the default form submission process to transmit the values of our widget by hooking onto the form submit button and modifying the form DOM tree before submitting the form. For this to work, it is necessary to create for every self-made widget an hidden input field, that has the correct control name and whose value is the value we want to transmit. In this case, our widget is nothing but an interface to the underlying hidden input field and every interaction with the widget is automatically applied to the corresponding hidden element. With a little caution and imagination in the element naming process, it is even possible to apply the standard methods, such as document.getElementById('widgetId').value to our self-made widget, if we take care that the hidden element is called widgetId and not the widget we created (which could be called widgetId_interface). This was the first method I used when I was tasked to create a dynamically generated interface with custom widgets and although it took some time to get used to, the result was very convincing and I had no major problems getting it to work exactly the way I wanted. I have to admit that this method strongly might be a little unusual but it gets the job done. A more elaborate method, with a lot more options, is probably the second one.

I assume that a lot of people that recently started with JavaScript, make the mistake and compare it to something like PHP, that resides in a different layer than the HTML markup and where the interaction only goes in one direction. They might think that a JavaScript function, upon invocation, generates something which is then displayed on the web site. While this is correct, JavaScript offers a lot more possibilities and contrary to PHP, objects you create aren't deleted when the JavaScript code has ended but it is possible to access them again at a later stage. Additionally, JavaScript is a very powerful object-based language, which is explained in great detail in a tutorial on sitepoint. One of the problems you have to face when you dynamically generate JavaScript objects is to actually find them again at a later stage, based on a numerical or string value that you received as argument. To solve this problem, a common solution is to create an object, a factory, that is able to store all the created objects in an associative array, or a map, as some might call it. As soon as you create an object that you want to keep for later usage, you stick it into the map, using its identifier as key for the map. This allows us to structure the entire code in a perfect object-oriented approach. First, we define a common interface that every widget we'll create has to respect. It should contain simple functions like getter/setter for the id, the name or the value and functions that define its behavior and visual appearance. This time, when the user submits the form, we don't have to rely on hidden elements to transmit our values but we can iterate over the map of created elements and generate the correct (name, value) pair for every widget we created. As each widget is internally represented by its object, the widget this time serves as visual interface to its underlying object and not to an hidden input field. For those of you that are familiar with dojo, might recognize the difference between dojo.byId, which is nothing else than a short version of document.getElementById and dojo.widget.byId, which is a lookup in the object map and returns the widget object, not the DOM element. This method is far superior to the first one, but also a little more complex to implement. The object-oriented approach has clear benefits and allow for a more modular approach, that is scalable and robust.

Conclusion

Writing and designing self-made widgets is a lot of work and requires careful thinking. More than once, you feel like you just reinvented the wheel and that you should better rely on available frameworks and widget engines. Of course, there are also reasons for writing a custom widget engine oneself, like dissatisfaction of the large overhead of some frameworks or the complexity and missing ease of use. Finally, it should be noted that several groups are currently trying to provide better widget frameworks, such as the the dojo dijit project.

News: New RSS feed

I would like to inform you that I added a new RSS feed to this website, that contains the 10 latest news and tutorials. Even though RSS is a very common way to distribute news around the Internet, I never got around to integrate it into my site, since I don't use any finished CMS but like to program everything myself.
For those of you interested, I followed a guide that I found on devshed, it was easy enough to go through it very fast but unfortunately contained several mistakes in the code. If you think about added an RSS feed to your site as well, have a look at that tutorial and you'll end up with one in no time.

Tutorial: Creating an AJAX Rating Widget

Introduction
Getting started with the HTML markup
Adding dynamic behaviour
Connect the widget to the server with different frameworks
Conclusion

Introduction

Frequent visitors of ajax enabled websites, like ajaxian, have all witnessed them already: ajax rating widgets. They are flashy, animated, you can use them to rate the content (usually without refreshing the page) and if you could, you'd present them to your parents and marry them. Compared to the classic rating system, as on IMDb, they incite people to click them, reducing the effective rating process to only one click.
In this tutorial, I want to show you how to create the JavaScript framework to display the animated rating widget and how to connect it to your server backend by using some of the most common Ajax frameworks out there. I clearly separate the page creation from the JavaScript functions and the rating backend, to allow the script to be as flexible as possible and to be easy integrable into your existing website.
This tutorial is not meant to present you with a finished script (even though you could simply copy&paste the end result into your website and make it work without any problems), but rather to explain the design and implementation process that would enable you to create your own widgets if you'd need to.

Getting started with the HTML markup

The first thing we're going to do is to create the div containers where we'll put our rating widget inside. This simple task already requires careful planning, as it will greatly influence the rest of our script. The problem is that the div containers need to be clearly identifiable by the JavaScript, to transform the static content into our dynamic rating widget and yet, they need to be distinguishable if you'd happen to have several rating widgets on the same page. If you read the quirksmode W3C DOM tables, you'll notice that only have two functions we can use to access the elements within our webpage, getElementById() and getElementsByTagName(). I decided to use the second function, getElementsByTagName() to read all the div containers in my webpage, and then check on the className to identify my rating widgets. This is why we'll give our rating widgets all the same class, namely "rating". To distinguish our widgets, we'll also give them a unique id, which is made of a common prefix "rating_" and a number that could serve as ID in the database backend. The same class name also provides us a nice markup hook to apply our CSS to.
Finally, we need to store the value of the current ratings somewhere, without complicating the server-side code generation too much. I decided to simply store the value of the rating inside the container. The finished div container for a rating widget will then look like the following:

<div class="rating" id="rating_1">3.5</div>

It is most important that there are no line breaks in this code, as this will complicate the DOM tree unnecessarily. If you are uncertain about what I just said, please read the W3Schools HTML DOM Tutorial for further reference, since we are going to access the DOM directly from within our JavaScript.
As you can see, the div container is pretty easy to generate in the server-side scripting language, requiring most of the time only one line:

printf("<div class=\"rating\" id=\"rating_%s\">%s</div>", ratingId, rating);

Following the guideline that we strictly want to separate content from design and behaviour, this is all we have to do in our HTML code. The next chapter describes how to transform each div container into a fully functional rating widget.

Adding dynamic behaviour

At the moment, the result is not very exciting and definitely not what we want to achieve. The next step is to add our JavaScript code to transform the plain div container into our dynamic rating widget. To do so, we first have to add our JavaScript file to the HTML header and then hook our initialization function to a window event. This is not a simple task and there are many different ways to achieve the same result. In his blog entry, Peter Michaux explains the window.onload problem and presents several techniques to overcome some of the problems. Advanced Ajax frameworks usually include special events that have the same result, such as dojo's dojo.addOnLoad() or mootools window.onDomReady().
In the first version of the code (the one that doesn't use any specific Ajax framework), I decide to simply hook my JavaScript function to the window.onload event:

window.onload = init_rating;

This line will simply call the function init_rating() when the page is fully loaded, parsed and rendered, which is also one of the problems of this method, in case your page happens to be very image heavy.
Our next step is to write the init_rating() function, which will do the following:

Find all the containers that represent a rating
Read the rating value contained within the div container
Remove the rating value text
Create and add the images to the rating widget
Add the animation effects

Find all the rating containers

Remember when I said that it was important to think about how to design the div container markup so we could use it in our JavaScript code? This is the place where our design will influence the complexity of the code and fortunately, we can simplify the code a lot. First, we use getElementsByTagName() to read all the div containers in our page into an array, then we loop over the array and use getAttribute to read the class name of the div container and finally, we filter all the elements out that don't have the class name we gave to our rating containers:

var ratings = document.getElementsByTagName('div');
for (var i = 0; i < ratings.length; i++)
{
    if (ratings[i].className != 'rating')
        continue;
        
    // rest of our code
}

The "continue" keyword in our JavaScript code, just like in most other programming languages, continues with the next iteration of the loop and prevents the execution of the rest of the code during that iteration.

Read the rating value

Now that we have all the rating containers, we can start by reading the rating value written as text inside the div container. To read that value, we access the first child node of the div container, which is a TextNode, and access its nodeValue, which returns the text CDATA in case of text nodes. This is done by the following line:

var rating = ratings[i].firstChild.nodeValue;

You probably remember when I said earlier that it is important not to insert unnecessary line breaks in the HTML markup of the div container. Line breaks are also stored in TextNodes, modifying the text content from the desired "4" to a more complex "\n 4" (taking 4 as example rating). It is still possible to convert that into a number but why introduce unnecessary complications if we simply think ahead and take care of the line breaks during HTML generation.

Remove the rating value

Even though we just read the rating value, we still have the TextNode inside our div container. Of course, we need to remove that node first before we can start adding the images to the container. This is done using the removeChild() DOM function:

ratings[i].removeChild(ratings[i].firstChild);

Add the images to the widget

Finally, we have to create and add the images to our rating widget. I decided to use 4 different stars images (), which represent the "on", "off", "half" and "over" states. The "on" state represents a fully coloured star and is used if the rating exceeds that star value. The "off" state represents a grey star and is used if the rating is inferior to that star's value. The "half" state adds the possibility to have decimal ratings but limiting the value of ".5" only. The "over" state is used when the mouse moves over the star, adding the flashy animation effect.
The first thing we need to do is to add a simple error check mechanism: we need to test if the rating value we read is within the allowed limits of our widget. To do so, we define a constant value called "NUMBER_OF_STARS", which defines the upper bound of our widget. We then test if the rating is contained within the limits:

var NUMBER_OF_STARS = 10;

if (rating > NUMBER_OF_STARS || rating < 0)
            continue;

There is no graceful way to recover from that error, so I simply decided to continue with the next rating container and prevent that error from happening within the server backend.
Now, we need to loop over the number of stars that are displayed and check what the image graphic will be that is displayed on the star. Using the HTML DOM function createElement(), we initialize a new image and progressively add the respective values to that element. Of course, the first thing we are interested in is the displayed image: we could either test the rating against the current iteration value or we could decrement the rating value during each iteration and test against 1, 0.5 and 0. I decided to decrement the rating during each iteration, which presents me with three simple cases to test: if the rating is greater than or equal than 1, the star is "on", if the rating is exactly 0.5, the star is "half" otherwise, the star is "off". This results in the following code:

for (var j = 0; j < NUMBER_OF_STARS; j++)
{
    var star = document.createElement('img');
    if (rating >= 1)
    {
        star.setAttribute('src', './images/stars/rating_on.gif');
        rating--;
    }
    else if(rating == 0.5)
    {
        star.setAttribute('src', './images/stars/rating_half.gif');
        rating = 0;
    }
    else
    {
        star.setAttribute('src', './images/stars/rating_off.gif');
    }
    ratings[i].appendChild(star);
}

The last line appends the newly created image to the div container. If you run this code, you should already see the stars with the correct states.
Now, before adding the graphical effects, we need to reason a little about what is required to animate the correct rating widget. A rating widget is distinguished by its ID, which is a number and represented in the widget id, as explained in the HTML markup chapter. Every method that is applied onto our stars, need to have several information, like the widget id and the star id, which requires us to extract the widget id and save it somewhere. Since the widget is is stored inside the div container id, it is possible to extract that number from the id:

var widgetId = ratings[i].getAttribute('id').substr(7);

I use the substr() method to cut off the first 7 characters representing "rating_" and leaving only the number.
Now that we have the widgetId, we can add the animation effects, using the onMouseOver and onMouseOut events:

var widgetId = ratings[i].getAttribute('id').substr(7);
star.setAttribute('id', 'star_'+widgetId+'_'+j);
star.onmouseover = new Function("evt", "displayHover("+widgetId+", "+j+");");
star.onmouseout = new Function("evt", "displayNormal("+widgetId+", "+j+");");

As you can see, I don't hoop onto the onClick event just yet, since I plan to do so using the specific functions of the Ajax frameworks. In order to prepare for those functions, I save the widgetId and the star number already in the image id, which I can use later to extract those values again.
Finally, there is one last thing to consider, which is important for the animation effect to work later on. The displayHover() function will replace the image sources with the "over" state graphic and we will lose the current state information of the star. To remember its state before the effect happens, we save its state in the class name, allowing us to read the class name and displaying the correct image again, as soon as the mouse leaves the widget. This results in this final function:

var NUMBER_OF_STARS = 10;

function init_rating()
{
    var ratings = document.getElementsByTagName('div');
    for (var i = 0; i < ratings.length; i++)
    {
        if (ratings[i].className != 'rating')
            continue;
            
        var rating = ratings[i].firstChild.nodeValue;
        ratings[i].removeChild(ratings[i].firstChild);
        if (rating > NUMBER_OF_STARS || rating < 0)
            continue;
        for (var j = 0; j < NUMBER_OF_STARS; j++)
        {
            var star = document.createElement('img');
            if (rating >= 1)
            {
                star.setAttribute('src', './images/stars/rating_on.gif');
                star.className = 'on';
                rating--;
            }
            else if(rating == 0.5)
            {
                star.setAttribute('src', './images/stars/rating_half.gif');
                star.className = 'half';
                rating = 0;
            }
            else
            {
                star.setAttribute('src', './images/stars/rating_off.gif');
                star.className = 'off';
            }
            var widgetId = ratings[i].getAttribute('id').substr(7);
            star.setAttribute('id', 'star_'+widgetId+'_'+j);
            star.onmouseover = new Function("evt", "displayHover("+widgetId+", "+j+");");
            star.onmouseout = new Function("evt", "displayNormal("+widgetId+", "+j+");");
            ratings[i].appendChild(star);
        } 
    }
}

Add the animation effects

To finish the display of our rating widgets, we only need to complete the two function displayHover() and displayNormal(). This shouldn't be too much of a problem. Both functions receive as argument the widgetId and the star number, making it very easy to access the necessary elements in our DOM tree.
The displayHover() function has to iterate over all the stars within the correct rating widget up to the current star the mouse is over and change their graphics to the "over" state:

function displayHover(ratingId, star)
{
    for (var i = 0; i <= star; i++)
    {
        var star = document.getElementById('star_'+ratingId+'_'+i)
        star.setAttribute('src', './images/stars/rating_over.gif');
    }
}

As you can see, I don't have to use the troublesome childNodes in the DOM navigation but I can immediately use the star id that already contains the widgetId and the star number.
The displayNormal() function is similar to the displayHover() function with the only difference that the newly displayed image is dependent on the saved state inside the class name:

function displayNormal(ratingId, star)
{
    for (var i = 0; i <= star; i++)
    {
        var status = document.getElementById('star_'+ratingId+'_'+i).className;
        var star = document.getElementById('star_'+ratingId+'_'+i);
        star.setAttribute('src', './images/stars/rating_'+status+'.gif');
    }
}

Conclusion

Our current JavaScript allows us to transform specially marked div containers into animated rating widgets that we can use in specialized Ajax frameworks to link to our server backend. The HTML markup is completely separated from the JavaScript code, which will leave the user with a not very stylish but still visual display of the current rating in case JavaScript is disabled. I've put together a ZIP file with the current result, containing an HTML file, a CSS file, the JavaScript file and the images.

Connect the widget to the server with different frameworks

Please make sure to delete the "window.onload=init_rating;" line in the "script.js" file if you downloaded the .zip file, since we're using the specialized framework onload event.
The examples below are only an illustration of how this given task is achievable with a variety of different JavaScript frameworks. It should not be used as a reference about what framework is superior since not every framework follows the same route and has the same objectives. Before jumping to conclusion, you should read more sources and also hear every site. There are good reasons for dojo not having the $ operator and some interesting points can be found here (in the comments). When you need to decide which framework to chose, base your decision on your specific task and the framework you're most comfortable with.

The PHP backend

Since we want to focus fully on the clientside frontend, we'll just use the most simple PHP script that reads the values it receives through the GET method and outputs a message in plaintext back to the client. Nothing fancy, nothing useful and totally outside of the scope of this tutorial:

<?php
  header('Content-type: text/plain');
  print "Thank you for rating the content ".$_GET['ratingID']." with the value ".$_GET['value'];
?>

You'll probably notice that the lowest value a user can rate is 0, since our stars are numerated from 0 to NUMBER_OF_STARS-1. It is up to you to change your PHP scripts to take that into account and increment the received value adequately.

Using the Dojo framework

The first framework I want to demonstrate is the Dojo 0.4.2 javascript toolkit. Dojo uses a powerful library system, making it possible to only load (and download) the necessary packages for your application to work. Before you can use dojo, you have to download and install dojo, which basically comes down to unzipping the archive (in .tar.gzip format) and placing it in the correct folder, in my case "./js/dojo". To use dojo in your JavaScript, you have to link to the dojo.js file that contains the framework to load additional packages. A more detailed tutorial can be found in the Dojo Book.
Before we're starting with the scripting, make sure that your header looks like the following, where script.js is the code described in chapter 3:

<script src="js/script.js" type="text/javascript"></script>
<script src="js/dojo/dojo.js" type="text/javascript"></script>

Dojo uses an Event System that makes it possible to listen to certain user actions and react accordingly. The event system is contained within "dojo.event.*" that we have to load before using it. Since Dojo overwrites the window load and unload events, it also provides a special event called dojo.addOnLoad() that we can use to add function calls to the window load event. This means we have to remove the window.onLoad event that we previously used and use the new method to call our function. Additionally, we need to add an event listener to every rating widget within our website.
To add an event listener, dojo provides a method called dojo.event.connect() that takes the object to listen to, the event and the callback function (the function that is executed when the event happens). Since we need such an event listener to every star in every rating widget, we have to use the same approach as earlier to read out all the div containers representing rating widgets and then iterate over all the childs and add the event listener:

function dojoInit()
{
    init_rating();
    var ratings = document.getElementsByTagName('div');
    for (var i = 0; i < ratings.length; i++)
    {
        if (ratings[i].getAttribute('class') != 'rating')
            continue;
        
        for (var j = 0; j < ratings[i].childNodes.length; j++)
        {
            dojo.event.connect(ratings[i].childNodes[j], 'onclick', 'submitRating');
        }
    }
}
dojo.addOnLoad(dojoInit);

As you can see, I used the dojo.addOnLoad() method to call the dojoInit() function when the site has fully loaded. The first thing I do in dojoInit() is to call our init_rating() function that does everything described in chapter 3. Afterwards, I read all the div containers in the page, filter them using their class name and finally iterate over all the children, using the DOM property childNodes[] and add the dojo event listener to them, having them call submitRating() when someone clicks on them.
As you can see, we have no possibility to specify the arguments to the submitRating() method. By default, dojo provides one argument, which is an Event Object, that we can use to identify the object that was clicked. The "target" property of the Event Object is a pointer to the clicked object within the DOM tree and we'll use it to read its id, where we earlier stored the widgetId and the star number. The id has the format "star_widgetId_number" and we can use several consecutive substr() calls to read the values:

function submitRating(evt)
{
    var tmp = evt.target.getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
}

Now that we have the two values, all that is left to do is to create an asynchronous call to the submitRating.php script using the dojo io package. This package provides a powerful tool to send and receive asynchronous server calls using the XMLHttpRequest object. I won't enter to much into the details of how the I/O package works but we'll use the dojo io bind method that takes several arguments, among which the url, the callback handler and then content are the most important. The url is the location of our server-side script, the callback handler is the function that is called when a new event occurs (more specifically when the onreadystate event of the XHR object occurs) and the content are the GET arguments sent to the server. The code should look like this:

function submitRating(evt)
{
    var tmp = evt.target.getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
    dojo.io.bind({
               url: './php/submitRating.php',
               handler: function(type, data, evt)
                  {
                    if (type == 'error')
                      alert('Error submitting the rating!');
                    else
                      alert(data);
                  },
               content: {'ratingID': widgetId, 'value':starNbr}
            });
}

As you can see, I used an anonymous function as callback handler, that takes the dojo predefined three arguments type, data and evt of which type and data are the most important. The "type" argument is used to check if something went wrong during the request (you could also register an error handler using the "error" argument of the dojo.io.bind() method) and "data" contains the received content from the server-side script, in this case the plaintext message.
The entire code, using the dojo 0.4.2 framework, should look like the following:

<script type="text/javascript">
dojo.require("dojo.event.*");
dojo.require("dojo.io.*");

function submitRating(evt)
{
    var tmp = evt.target.getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
    dojo.io.bind({
               url: './php/submitRating.php',
               handler: function(type, data, evt)
                  {
                    if (type == 'error')
                      alert('Error submitting the rating!');
                    else
                      alert(data);
                  },
               content: {'ratingID': widgetId, 'value':starNbr}
            });
}

function dojoInit()
{
    init_rating();
    var ratings = document.getElementsByTagName('div');
    for (var i = 0; i < ratings.length; i++)
    {
        if (ratings[i].getAttribute('class') != 'rating')
            continue;
        
        for (var j = 0; j < ratings[i].childNodes.length; j++)
        {
            dojo.event.connect(ratings[i].childNodes[j], 'onclick', 'submitRating');
        }
    }
}
dojo.addOnLoad(dojoInit);
</script>

Using the mootools framework

mootools is a compact, modular, Object-Oriented JavaScript framework that I used initially because of its powerful Accordion widget. The small size, the customized download and the nice effects makes it a good choice for intermediate programmers that want something small that "just works".
Before we can even think about using mootools though, we need to assemble all the important parts in the download section of the page. This can be a little confusing for beginners, since a missing package keeps your script from running correctly (if at all). It is of course possible to just select everything (for which there exists a shortcut, simply enter "javascript:Download.all();" in your browser's location bar and press Enter) but that increases unnecessarily the code size. Remember that every visitor to your site has to download the JavaScript file so try to keep it as small as possible.
The required parts for our script to work are: "Element", "Event", "Dom", "Window.Base" and "Ajax". The "Element" package allows us to add function callbacks to element events and we'll use it to hook onto the onClick event of our stars. The "Event" package is provides cross-browser methods to manage events and although we only use the target property of our events, I consider this to be a good idea. The "Dom" package allows us to select the div containers using their css class. The "Window.Base" package contains window events, such as the onDomReady event that we'll use to call our initialization function instead of window.onload(). Finally, the "Ajax" package extends the XMLHttpRequest wrapper package XHR with additional methods and functionalities and provides a cross-browser method to send Ajax requests.
Before we'll start with the JavaScript code, we have to add the mootools library to our website. This is simply done by writing:

<script src="js/mootools/mootools.js" type="text/javascript"></script>

The structure of the program will strongly resemble to the dojo code. The things that do change are the initialization call, the access to the rating widgets, the event listener and the Ajax request. As already mentioned, the "Window.Base" package provides us with a method called window.onDomReady() that takes as argument the function to call when the DOM is ready, which means when the document tree has loaded, not waiting for images (which is a good thing). The use of that method is shown here:

window.onDomReady(mooInit);

The mooInit() function does the same thing as the dojoInit() function; it finds all the stars within our page and adds an event listener to the onClick event. To access the rating widgets, we can use the $$ operator, that allows us to access elements by their CSS class name, to get all the rating widgets and the getChildren() method to get an array of all the stars images. To iterate over the array, mootools provides a method called each that is located in the Array package. each expects as argument a function and passes a reference to the current element as argument to the function. The "Element" package provides us with the method addEvent() which attaches an event listener to a DOM element:

function mooInit()
{
    init_rating();
	$$(".rating").getChildren().each(function(star) {
	    star.addEvent('click', submitRating);
    });
}

As you can see, I defined an anonymous function that has one argument called star. This function is called once for every item in the array returned by getChildren(). Please notice that the addEvent() is a method of the DOM element, contrary to dojo where the DOM element is an argument. Now, all that is left to do is to create the callback function submitRating(evt) and to send the Ajax request. mootools provides a specialized package called "Event" that provides a cross-browser compatible way of using events. The first thing we need to do within our function is to initialize an Event object. This is done by passing the standard event argument as argument to the Event object. Then we can use the Event object's target property and don't worry about the underlying implementation.
In order to send an Ajax request, mootools provides a special package called Ajax.js. The object constructor takes two arguments, the url and the options. Among all the possible options, only two are useful for our purpose, the method and the onComplete event handler. For our rating widget, we'll specify that the method will be "get" and the event handler will be once again an anonymous function that simply alerts the returned message. To send the request, the Ajax object has the request() method. Contrary to the dojo framework, that provided an option where we could specify the get arguments and values, mootools provides no special tool to specify those values. We are required to construct the respective url ourselves. To facilitate this task, mootools provides a method called Object.toQueryString() that takes key/pair values and transform it into the corresponding url. The code to send the Ajax request should look like the following:

function submitRating(evt)
{
    var tmp = new Event(evt).target.getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
    var queryString = Object.toQueryString({'ratingID': widgetId, 'value': starNbr});
    var myAjax = new Ajax('./php/submitRating?'+queryString, {
        method: 'get',
        onComplete: function(result)
            {
                alert(result);
            }
        }).request();
}

The entire code, using the mootools 1.00 release version, should look like the following:

<script src="js/mootools/mootools.js" type="text/javascript"></script>
<script type="text/javascript">


function submitRating(evt)
{
    var tmp = new Event(evt).target.getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
    var queryString = Object.toQueryString({'ratingID': widgetId, 'value': starNbr});
    var myAjax = new Ajax('./php/submitRating?'+queryString, {
        method: 'get',
        onComplete: function(result)
            {
                alert(result);
            }
        }).request();
}


function mooInit()
{
    init_rating();
	$$(".rating").getChildren().each(function(star) {
	    star.addEvent('click', submitRating);
    });
}

window.onDomReady(mooInit);
</script>

Using the jQuery framework

The jQuery library is designed to change the way that you write JavaScript and oh boy, they don't exaggerate. jQuery might not have the fanciest widgets or the the most beautiful effects ever but you can do some really cool stuff with it. But first things first, before we can do anything with it, we need to add the JavaScript file to our website. This is done by first downloading the latest jQuery release and then add it to the code, using:

<script src="js/jquery/jquery.js" type="text/javascript"></script>

Once again, we have to deal with the same problems as usual, which is add the initializer to the windows.onload event, add an event listener to the click event of every star in every rating widget and finally send the Ajax request.
To add a function call to the window.onload event, jQuery offers its own method which is called $(document).ready(). Basically, this uses already one of the most powerful features of jQuery, which is the Selector. It is a combination of CSS 1-3, XPath and some custom modification and allows you virtually to access every element within your page. In this simple example, we use the selector to access the document element and attach a function to the ready event:

$(document).ready(jqueryInit);

The next problem would be to add an event listener to each star image in every rating widget. While mootools offered us the possibility to use the $$ operator to access all the div containers that had the "rating" class, jQuery offers us a little more. Not only can we use the Selector to access the div containers by their class name, we can also use the XPath expression to access their children of type "img". If that's not enough, the bind() method, that is used to add an event listener to an element event, can be used on collection of objections (instead of iterating over all the objects of a collection and using the method on each object individually). Not convinced? Here's the code:

function jqueryInit()
{
    init_rating();
    $('div.rating/img').bind('click', submitRating);
}

There's another thing worth mentioning: the exact same thing could maybe be possible with the other frameworks I presented but honestly, I couldn't find it in their documentation. jQuery not only offers a good JavaScript framework, but also a great documentation that made it very easy to find all those things.
Finally, all that is left is to send the Ajax request. This is done by using the $.get() function, which is basically an higher-level abstraction of their low-level Ajax implementation. The function has three argument, the url, the parameters and the callback function:

function submitRating(evt)
{
    var tmp = evt.target.getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
    $.get("./php/submitRating.php",
       { ratingID: widgetId, value: starNbr},
       function(data){
         alert(data);
       }
     );
}

The entire code, using the jQuery 1.1.2 library, should look like the following:

<script src="js/jquery/jquery.js" type="text/javascript"></script>
<script type="text/javascript">

function submitRating(evt)
{
    var tmp = evt.target.getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
    $.get("./php/submitRating.php",
       { ratingID: widgetId, value: starNbr},
       function(data){
         alert(data);
       }
     );
}

function jqueryInit()
{
    init_rating();
    $('div.rating/img').bind('click', submitRating);
}

$(document).ready(jqueryInit);
</script>

Using the prototype framework

Next on our list is the prototype framework, that aims to ease development of dynamic web applications. Even though I've never used prototype before, the prototype API has a great documentation since mid-January and if you know what you're looking for, you should have no problems finding it (apart from the window.onload event that was hidden in an example somewhere deep within).
I am using the 1.5.0 version and, as usual, the very first thing to do is to add the script to your header:

<script src="js/prototype/prototype.js" type="text/javascript"></script>

If you read through the other framework examples, you should know by now that we have three simple tasks to complete: hook an initialization function to the window.onload event, add a "click" event listener to each star in every rating widget and send the Ajax request. The Event manager in prototype uses a method called observe() that registers a callback function to an element event. To hook onto the onload event, we need to observe the "window" element and register the "load" event:

Event.observe(window, 'load', prototypeInit);

In order to register an event handler for every star in each rating widget, prototype provides several utility methods, such as the $() method to return an element based on its id or the $$() method that returns elements based on their CSS class. In their Enumerable package, prototype has several methods that work on collections of values. One of these methods is the each() method that basically iterates over every element of a collection and returns the element, similar to foreach() operations in programming languages such as PHP. Using the each() method, our prototypeInit() function looks like the following:

function prototypeInit()
{
    init_rating();
    $$('.rating').each(function(n){
                        n.immediateDescendants().each(function(c){
                            Event.observe(c, 'click', submitRating);
                        });
                    });
}

As you can see, I use the $$() method to get an Enumeration of div containers (the rating widgets), then use each() to iterate over each div container. The parameter "n" is the Enumerable, a reference to the current object in the iteration. It is not possible to apply each to the standard "childNodes" property of a DOM element, so you have to use the method immediateDescendants() to get a collection of star images. Finally, we apply each() on that collection to iterate over each star image and use observe to register an event handler to it.
For our submitRating event, prototype provides a cross-browser way of accessing event information, that are explained in the Event package. We only have to initialize a new Event object and pass our event as argument.
Finally, to send the Ajax request, we'll use the Ajax.Request() method that takes two arguments, the url and the options. The only Ajax Options that interest us are the "method", the "parameters" as well as the "onSuccess" handler. Please note that there are several existing callback handlers, such as onComplete, onFailure, onException and many more, but for the sake of simplicity, we'll only use the onSuccess handler and discard the rest:

function submitRating(evt)
{
    var tmp = Event.element(evt).getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
    new Ajax.Request('./php/submitRating', {
      method: 'get',
      parameters: {ratingID: widgetId, value: starNbr},
      onSuccess: function(transport) {
          alert(transport.responseText);
      }
    });
}

The entire code, using the prototype 1.5.0 framework, should look like the following:

<script src="js/prototype/prototype.js" type="text/javascript"></script>
<script type="text/javascript">

function submitRating(evt)
{
    var tmp = Event.element(evt).getAttribute('id').substr(5);
    var widgetId = tmp.substr(0, tmp.indexOf('_'));
    var starNbr = tmp.substr(tmp.indexOf('_')+1);
    new Ajax.Request('./php/submitRating', {
      method: 'get',
      parameters: {ratingID: widgetId, value: starNbr},
      onSuccess: function(transport) {
          alert(transport.responseText);
      }
    });
}

function prototypeInit()
{
    init_rating();
    $$('.rating').each(function(n){
                        n.immediateDescendants().each(function(c){
                            Event.observe(c, 'click', submitRating);
                        });
                    });
}

Event.observe(window, 'load', prototypeInit);
</script>

Conclusion

You can download a fully functional finished script, using the jQuery framework, from here.
I hope that you learned something new and that by now, you should have a fully functional Ajax rating widget. Once again, I'd like to specify that my intention is to show you an approach to coding with Ajax and less to provide you with a finished script. I hope I could show you how I separated the steps into different tasks and how each task was solved, using several different JavaScript frameworks. If you have anything to add, feel free to drop me a note and I'll make sure to include any necessary changes into this tutorial.

News: Rating Widget Tutorial Update

I received a lot of feedback when this tutorial was published on Ajaxian and was informed that several things weren't Internet Explorer compatible. I went back and changed several lines of code and updated the tutorial and the zip archive. Basically, IE doesn't seem to like when you try to access an elements class name using the getAttribute() method. Additionally, I had to change the onmouseover/onmouseout event handlers to have them work correctly.
Another reader informed me that he had problems using the downloaded zip archive with the frameworks. This is because the downloaded script.js still contains the window.onload event handler that needs to be removed and replaced with the respective framework onload event handler. I added a mention to the tutorial that should explain this problem.

I would like to thank everyone that took the time to send me constructive feedback about my tutorial, such as framework development teams that informed me how I could optimize even further several lines of code. I've put up an ZIP archive with the finished script, using the jQuery framework. You should be able to unpack and use it without any modifications.

News: Creating an Ajax Rating Widget

As some of you might have noticed already, I've put up a new tutorial about Creating an Ajax Rating Widget. The tutorial describes in great detail the implementation steps from the simple HTML markup to the use of an JavaScript framework to connect the widget to a server backend. For those of you that are already familiar with a certain framework, I ported the code to several different frameworks and explain the differences and similarities between them.
The tutorial was recently published on Ajaxian and if you are satisfied with the tutorial, you can vote for it here.

Tutorial: Creating a CSS Design from Scratch

Introduction
Analyze, identify and structure
Creating the global layout
Designing the header
Designing the sidebars
Designing the center part
Conclusion

Introduction

For years, the easiest way to convert a design, that you or a fellow designer carefully composed in Photoshop, was to cut it in several rectangular parts, wrap a table around, spanning columns and rows as you pleased and you're done. Nowadays, this has become a "little" more complicated, as web standardists enter the scene and tell you what you should do. Don't understand me wrong, this is a good thing and I'm a full supporter of most of the standards and ideas that are promoted from organizations like the W3C. Unfortunately, it takes a lot of practice, trial and error and experience to do things the correct way; if there is a correct way.

I want to show you , using as reference a website that I recently visited and had the pleasure to look at the html code, how it is possible to draw a clean line between content & design, just the way it is intended. The objective is to convert the old design, using non-standard HTML, evil hacks and overly complicated CSS into a fully cross-browser compatible, structured design that is easily extendable and modifiable. The end result can be seen here.

Analyze, identify and structure

The first step in the design process is to look at the design and identify the main components. Imagine a castle made of different logo blocks: your task is to analyze the castle, identify the different parts and use the correct logo blocks to be able to build that castle. This is probably the hardest part of the entire process and requires careful planing. You have to break the design into separate pieces, as if you'd cut the image with a knife into small regions, each region representing a new element in the design.
Fortunately, it is very easy to identify the structure of this design: one horizontal header, and a three column layout for the body. Several other things you could notice is that the website width is 100%, the two sidebars are of fixed with and each represent element within the sidebars is independent from each other and could be loaded dynamically as modules.
I wouldn't worry at this stage about how to design the elements, our current goal is to identify and structure. Another important concept is to identify parts that share common properties. Even though the sidebars have 6 different boxes, you probably noticed that they have several things in common (like the way the background is designed, the position of the title, the icon left of the title, the width and the position of the content). Generally, if you are able to regroup several objects, you can design them using the class attribute, otherwise, if they are unique, it is best to assign them a unique identifier id and reference them directly in CSS.

The class attribute, assigns one or more class names to an element; the element may be said to belong to these classes. A class name may be shared by several element instances.

Creating the global layout

Let's start our design process by creating the basic layout for our website. We do this by adding elements to our HTML code and position them according to our desired result with CSS. A rule of thumb is that everything related to the visual aspect of our website is left to CSS and HTML represents only the content. If we want to add an element to our website, we add a new DIV container, which is nothing else than a generic language/style container and imposes no other presentational idiom on the content. A div container is nothing else than a box, that can be modified using a CSS stylesheet, the div is accessed by the mean of his class and/or id. This being said, the structure of our HTML document will look like this, if we only add the header and the three columns.

<body>
    <div id="header">header</div>
    <div id="wrapper">
        <div id="container">
            <div id="center">center</div>
            <div id="leftSidebar">left</div>
            <div id="rightSidebar">right</div>
        </div>
    </div>
</body>

You probably notice that I put a div contained called "wrapper" around three of the containers. I did this for several reasons: first of all, they can be considered as one global element, compared to the header file, which is the content of our website. If we cut the image in parts with our knife, the first horizontal cut under the header would create two parts, the header and the page body. The wrapper container represents just that. The need for yet another container becomes clear in a second, when I discuss the problems with a multi-column design.
Another reason is that the wrapper allows us to apply a CSS stylesheet to all three of the elements at the same time, which is very important for what we want to achieve now: a three-column liquid layout. This is probably the most argumented and discussed subject in the world of web design and there is no generally accepted way of doing this. I copied my implementation from A List Apart, which is a great resource for everything website-related. Author Alan Pearce explains in great detail how he arrived to his CSS design and how to use it in an own design; which is exactly what we're going to do now:

body {
background-color:#2f2f2f;
margin:0;
padding:0
}

#header {
height:141px;
background-color: red;
}

#wrapper {
font-family:Tahoma, arial, verdana, courier;
padding:0 200px
}

#container {
float:left;
width:100%;
border-left:200px solid #2f2f2f;
border-right:200px solid #2f2f2f;
margin-left:-200px;
margin-right:-200px;
display:inline
}

#leftSidebar {
background-color: blue;
float:left;
width:200px;
margin-left:-200px;
position:relative
}

#center {
background-color: yellow;
float:left;
width:100%;
margin-right:-100%
}

#rightSidebar {
background-color: white;
float:right;
width:200px;
margin-right:-200px;
position:relative
}

A few things you should note is that I added a margin and padding value for the body element, which essentially takes away the default margin between the browser borders and the content and which makes it possible to have our design fill up the entire width of the screen as well as go up till the very top of the window. I also added distinctive colors to each of the elements, to identify potential problems and check if everything shows up correctly. If you did everything as described, you should end up with something like this, which is a very good start to continue the rest of the design from.

Designing the header

Since we have already our header container, the only thing left to do is to enter the header content (the logo title and slogan) and to design the header visually. Since the logo title and the slogan are unique within the website, I decide to give them a unique id. The line beneath the logo title could be done with an image, but to stay true to the nature of CSS, I decide to draw the line using the bottom-border of the logo title.
The HTML code once again only contains the content and the entire look is done within the CSS code:

<div id="header">
    <div id="logo">
        <div id="logo_title">
            Queatrix's.com
        </div>
        <div id="logo_slogan">
            program blog and archive.
        </div>
    </div>
</div>

Let's start with the header background. If you give it a close look, you'll notice that the background is made up of repeatable, regular, diagonal stripes. Everything which is repeatable and regular is good, since it makes it possible to cut a very specific part out of the image and repeat it horizontally over the whole width, which saves not only space as the image is smaller, but the site will load faster (less image data to transfer) and the design is resolution independent. To cut the needed part out from the image, I usually start in the lower left corner and select as many pixels to the right until the texture starts to repeat itself (five pixels in this case). Notice that the background has a vertical gradient and a much darker part at the bottom, which makes it impossible to repeat vertically, otherwise we could have cut a small rectangle of only 5x5 pixels and repeated in every direction to fill the entire div container. If you perform the cut correctly, you should end up with an 5x141 pixel image.
The CSS code for the text is pretty standard, the only thing to note is the use of the bottom-border to simulate the horizontal line underneath the title logo:


#header {
height:141px;
background:url(../images/header_bg.png) repeat-x 0 0
}

#logo {
color:#fff;
padding:30px 0 0 50px
}

#logo_title {
font-family:georgia, tahoma, arial narrow, arial;
font-size:26px;
font-weight:400;
text-transform:uppercase;
letter-spacing:2px;
border-bottom:1px solid #7ea3ac;
width:160px
}

#logo_slogan {
font-size:10px;
font-family:tahoma, arial
}

If you followed the instructions carefully, you should now have the following result.

Designing the sidebars

Now that we're done with the header, we'll focus on the sidebars. The left and right sidebar can be treated equally, as their content is independent of their position within the side. Each sidebar is made up of different modules and as you might guess, each module is a div container. The modules share common properties, which is best represented using a class, since one CSS definition of the class will automatically be applied to every member of that class. However, each module also has its very own properties, like the background color. To do this, not only do I define a class for the sidebar modules, but I also give each sidebar its very own id, that can be used to modify its look without changing the other modules.
To save some space, I only post the HTML code from the left sidebar, the right sidebar modules are done in exactly the same way:

<div id="leftSidebar">
    <div id="categories" class="sidebar_item">
        <div class="sidebar_title">
            Categories
        </div>
        <ul>
            <li>
                <a href="http://cboard.cprogramming.com/" target="_blank">link test</a>
            </li>
            <li>Games
            </li>
        </ul>
    </div>
    <div id="resources" class="sidebar_item">
        <div class="sidebar_title">
            Other Resources
        </div>
        <ul>
            <li>Tools
            </li>
            <li>Games
            </li>
        </ul>
    </div>
    <div id="foo" class="sidebar_item">
        <div class="sidebar_title">
            Foo
        </div>
        <ul>
            <li>Tools
            </li>
            <li>Games
            </li>
        </ul>
    </div>
</div>

Once again, there is no markup that would change the visual aspect of modules. Please note that each module has an id and a class. The class defines the shared attributes like width, minimal height, font attributes and positions while the id specifies the particular aspects like background. Since two modules can share the same background color, it would have been possible to define a class "orange_background" and add that class to each module that has an orange background.
The CSS code for the class sidebar_item can be found here:

.sidebar_item {
float:left;
width:100%;
min-height: 160px;
margin:1px 0 0;
padding:0
}

Now, let's start designing the modules themselves. Since the background has no defined elements apart from the vertical gradient, it is possible to only use an image of one pixel width and repeat that image horizontally. Since the module is of unknown height, we have to limit the gradient to a certain height, or else we'd stretch the image which would result in a horrible quality. Fortunately, the gradient results in a constant color value at a certain height, so all we have to do is cut out a region whose height is big enough to hold the gradient, and then we simply fill the background of the container with the same color than the color value at the bottom of the image.
This might sound a little complicated but in fact, it's only one simple CSS line:

#categories {
background:#e67701 url(../images/orange_gradient_bg.png) repeat-x 0 0
}

That one line defines that the color fill value is #e67701, that a background image is uses (of size 1x160), that it should be repeated horizontally and that it's fixed at the top left corner.
Since it is possible in CSS to regroup several id definitions, the complete code for the six different modules looks like this:

#categories,#search {
background:#e67701 url(../images/orange_gradient_bg.png) repeat-x 0 0
}

#resources,#meta {
background:#2b6475 url(../images/blue_gradient_bg.png) repeat-x 0 0
}

#archives,#foo {
background:#6d8a0c url(../images/green_gradient_bg.png) repeat-x 0 0
}

The next step is to place the module title together with the image. I recommend you that, whenever an image is used that gives no additional meaning to the content and is only for decorative purpose, to set is as a background image. Simply set the image as background with CSS, position it to the left (in this case), don't repeat it and then add a padding-left to your container the width of your image:

.sidebar_title {
background:url(../images/sidebar_title_logo.gif) no-repeat 0 0;
height:30px;
font-size:13px;
color:#493800;
font-weight:700;
letter-spacing:normal;
margin:20px 0 0 35px;
padding:4px 0 0 40px
}

Finally, all that is left to do is to design the list inside the module. First, we remove the usual list style (since we plan on using our own) and do the same trick as with the module title. The little white arrow is set as li background, positioned to the left and the text is padded to the right accordingly. The line underneath the list text is once again only a CSS border-bottom, with the desired style:

li {
list-style:none;
background:url(../images/list_item.gif) no-repeat 0 5px;
border-bottom:1px dotted #b2c56f;
color:#fff;
font-size:11px;
width:100px;
padding:0 0 5px 7px
}

The search module has to be treated separately, since it has its own icon and the form needs to line up nicely. I added search_title to the class list of the module title container and simply redefined the background image. Finally, I modified the padding inside the search form, gave the text input a nicer look and positioned it relative to the image:

<div id="search" class="sidebar_item">
    <div class="sidebar_title search_title">
        Search
    </div>
    <form method="get" id="searchform" action="search.php" name="searchform">
        <input type="text" name="searchinput" id="searchinput" value="">
        <input type="image" src="./images/go.gif" value="submit">
    </form>
</div>

.search_title {
background:url(../images/search_bg.gif) no-repeat 0 0
}

#searchform {
padding:20px 0 0 10px
}

#searchinput {
font-size:12px;
color:#483221;
font-family:Tahoma, arial, verdana, courier;
width:109px;
height:21px;
border:#483221 solid 1px;
vertical-align:top;
margin:0 5px
}

Designing the center part

Apart from the current website, I didn't have much information about the design concept of the center section, which is why I kept this part pretty simple. First, I added a class which I called center_item, which basically is a container for one item in the center part, be it news or whatever is shown there. To make the center part align nicely with the two sidebars, I added a margin at the top of the same size than the darker region in the background image of the side modules. Finally, I padded the content, modified the font face, size and color and set the alignment to justify:

.center_item {
border-top:8px solid #2f2f2f;
text-align:justify;
color:#fff;
font-family:tahoma, arial narrow, arial;
font-size:12px;
padding:10px 40px
}

Conclusion

I hope I was able to show you how convenient it is to strictly separate the content from the actual design. By carefully structuring and naming the content according to its function within the page, the true power from CSS can be applied. This makes it possible in the future to change the design without changing the HTML code.
Apart from the fluid three-column CSS design, there were no major problems that had to be overcome, since the design was pretty simple. If you have any questions, feel free to drop me a note using the Contact Form.

Tutorial: Collaborative editing

HTML version not available, please use the PDF version

Tutorial: Block Cipher Modes of operation

Introduction to modes of operation
The Initialization Vector (IV)
Message padding
Electronic codebook (ECB)
Cipher-block Chaining(CBC)
Cipher feedback (CFB)
Output feedback (OFB)
Putting it all together

Introduction to modes of operation

If you followed this tutorial up to this point, you should know by now that block ciphers operate on blocks of fixed size, in this case 128 bits. Although it might happen that we need to encode a message of exactly 128 bits, we want our plaintext to be of any length. As you can see, encrypting the same plaintext under the same key always produces the same output, we need a mode of operation to provide confidentiality for messages of arbitrary length.
In this final chapter, we will learn about three modes of operation, namely CBC, OFB and CFB.

The Initialization Vector (IV)

Every block cipher mode of operation requires an initialization vector (commonly called IV), which serves as basis block to start the process and at the same time introduces randomization in the process. There is no need for the IV to be secret (in most cases), but as you will seen soon enough, it might cause a leak of information if it is reused with the same key. Just remember that the IV is a initial block of the same size than our block cipher block (128 bits for AES).

Message padding

Because a block cipher works on blocks of a fixed size, but messages come in a variety of lengths, some modes (mainly CBC) require that the final block be padded before encryption. As you can read in this article, many padding schemes exist. The simplest (which we will implement) is to add null bytes to the plaintext to bring its length to a multiple of the block size. Slightly more complex is the original DES method, which is to add a single one bit, followed by enough zero bits to fill out the block. If the message ends on a block boundary, a whole padding block will be added.

Electronic codebook (ECB)

The simplest (and also the least secure) encryption mode is the electronic codebook (also called ECB). The input message is simply divided into blocks of the required size and each block is encrypted separately. The disadvantage is evident: identical plaintext blocks are encrypted into identitcal ciphertext blocks (since the secret key stays the same during the entire process). I strongly recommend to not use this mode at all, I'm only showing this for information purpose only.

As you can see on these images (taken from this Wikipedia article), you can see that ECB is fairly simple to implement and even more simple to misuse for malicious purpose. An even more stunning example is the encryption of this image under ECB. Since identical input pattern result in the same output pattern, it is possible to recognize the source image, even under its encrypted version:

Cipher-block chaining (CBC)

In CBC mode, the input message is once again divided into blocks and each block is XORed to the previous ciphertext block (the output of the previous encrytion) before being encrypted. As you can see, we require a ciphertext block to XOR the first message block to, which will be our IV. In CBC mode, each ciphertext block is dependent on all plaintext blocks processed up to that point.

CBC is the most commonly used mode of operation but its main drawback is that the message must be padded to a multiple of the cipher block size, and therefor is being replaced by synchronous stream-ciphers such as CFB or OFB.
Before we start implementing the CBC mode, let us first define a structure that we'll use to select the appropriate mode as well as the prototype of our encryption function:

enum modeOfOperation{
    OFB,
    CFB,
    CBC
    };

void encrypt(FILE *in, FILE *out, enum modeOfOperation);

If at a later stage, you have several block ciphers implemented, you could change this prototype to have a pointer to a block cipher, which would then be used internally by the mode of operation.
I decided to use several blocks of 128 bits, that each serve its very own purpose:

plaintext: this corresponds to the 128 bit plaintext block that we encrypt during each iteration
input: input corresponds to what is being used as input for the block cipher (the AES input)
output: this corresponds to the output of our block cipher
ciphertext: this corresponds to the output of our mode of operation for this iteration

As you will see, we could manage with a less blocks but since each mode of operation has its own special structure, we can keep our code clean and structured by introducing a little overhead. I'm also using an additional variable that defines if we are currently in the first round of the mode (where we use the IV) or at a later stage.
In order to recover the exact plaintext, even using our padding scheme, I decided to first write the mode of operation in use as well as the exact input file size into the output file:

fseek(in,0,SEEK_END);
fileSize = ftell(in);
fseek(in,0,SEEK_SET);

/* add the file header */
fwrite(&mode, sizeof(mode), 1, out);
fwrite(&fileSize, sizeof(fileSize), 1, out);

Since we are working with binary files, I use fread() and fwrite() to process the two files. Our algorithm reads blocks of 16 bytes (saving the return value of fread() in case we read less than 16 bytes and we need to padd), we perform the padding if we need to, XOR the plaintext to either the IV or the output (in CBC, the output is equal to the ciphertext), apply our AES encryption and write the result to the file.

/* the non-expanded keySize */
enum keySize size = SIZE_32;

/* the AES input/output */
unsigned char plaintext[16] = {0};
unsigned char input[16] = {0};
unsigned char output[16] = {0};
unsigned char ciphertext[16] = {0};
unsigned char IV[16] = {0};

/* the AES key */
unsigned char key[32] = {0x0};

/* char firstRound */
char firstRound = 1;

size_t read;
int i;

while ((read = fread(plaintext, sizeof(unsigned char), 16, in)) > 0)
{
    /* padd with 0 bytes */
    if (read < 16)
    {
        for (i = read; i < 16; i++)
            plaintext[i] = 0;
    }

    for (i = 0; i < 16; i++)
    {
        input[i] = plaintext[i] ^ ((firstRound) ? IV[i] : ciphertext[i]);
    }
    firstRound = 0;
    aes_encrypt(input, ciphertext, key, size);
    /* always 16 bytes output because of the padding for CBC */
    fwrite(ciphertext, sizeof(unsigned char), 16, out);
}

As you can see, we don't need the output block this time, as the ciphertext is identical to the output. The CBC decryption is similar, except for the fact that we pay attention to the originalFileSize we recovered from the input file and in case we have less than 16 bytes left to decrypt, we write the remaining bytes instead of the 16 bytes we read from the file:

while ((read = fread(ciphertext, sizeof(unsigned char), 16, in)) > 0)
{
    aes_decrypt(ciphertext, output, key, size);
    for (i = 0; i < 16; i++)
    {
        plaintext[i] = ((firstRound) ? IV[i] : input[i]) ^ output[i];
    }
    firstRound = 0;
    if (originalFileSize < 16)
    {
        fwrite(plaintext, sizeof(unsigned char), originalFileSize, out);
    }
    else
    {
        fwrite(plaintext, sizeof(unsigned char), read, out);
        originalFileSize -= 16;
    }
    memcpy(input, ciphertext, 16*sizeof(unsigned char));
}

You probably noticed that I copied the content of the ciphertext into the input block. This is because ciphertext will be overwritten during the next iteration by the new ciphertext block, but we still need the ciphertext from the previous iteration to perform the XOR operation. In this case, I use input not as the input for the AES block cipher but for the XOR operation. Don't worry if you can't implement this code into a working example, I'll post the complete code at the end of this chapter.

Cipher feedback (CFB)

The cipher feedback (CFB) mode, a close relative of CBC, makes a block cipher into a self-synchronizing stream cipher. Operation is very similar; in particular, CFB decryption is almost identical to CBC decryption performed in reverse.

CFB shares two advantages over CBC mode with the stream cipher modes OFB and CTR: the block cipher is only ever used in the encrypting direction, and the message does not need to be padded to a multiple of the cipher block size. I personally think this mode of fairly easy to implement, so without any hesitation I show you the final code for encryption:

while ((read = fread(plaintext, sizeof(unsigned char), 16, in)) > 0)
{
    if (firstRound)
    {
        aes_encrypt(IV, output, key, size);
        firstRound = 0;
    }
    else
    {
        aes_encrypt(input, output, key, size);
    }
    for (i = 0; i < 16; i++)
    {
        ciphertext[i] = plaintext[i] ^ output[i];
    }
    fwrite(ciphertext, sizeof(unsigned char), read, out);
    memcpy(input, ciphertext, 16*sizeof(unsigned char));
}

In this case, you'll probably notice that I could have used the ciphertext immediately as input for the AES encryption, something that I found illogical for naming convention, so I simply copied the content from the ciphertext into the input. In case you're looking for optimal performance, feel free to change this.
The decryption is very similar to the encryption (it even uses the AES encryption) and here's the code:

while ((read = fread(ciphertext, sizeof(unsigned char), 16, in)) > 0)
{
    if (firstRound)
    {
        aes_encrypt(IV, output, key, size);
        firstRound = 0;
    }
    else
    {
        aes_encrypt(input, output, key, size);
    }
    for (i = 0; i < 16; i++)
    {
        plaintext[i] = output[i] ^ ciphertext[i];
    }
    fwrite(plaintext, sizeof(unsigned char), read, out);
    memcpy(input, ciphertext, 16*sizeof(unsigned char));
}

Output feedback (OFB)

If you read and understood the CFB mode, you shouldn't have any problems implementing the OFB mode. The only difference is that it uses the AES output before the XOR operation (and not like CFB after the XOR operation) as input for the next iteration.

Here's the code for the encryption:

while ((read = fread(plaintext, sizeof(unsigned char), 16, in)) > 0)
{
    if (firstRound)
    {
        aes_encrypt(IV, output, key, size);
        firstRound = 0;
    }
    else
    {
        aes_encrypt(input, output, key, size);
    }
    for (i = 0; i < 16; i++)
    {
        ciphertext[i] = plaintext[i] ^ output[i];
    }
    fwrite(ciphertext, sizeof(unsigned char), read, out);
    memcpy(input, output, 16*sizeof(unsigned char));
}

As you can see, the only difference to CFB mode is that I copy the content of output into input and not the content of ciphertext. Here's the code for the decryption:

while ((read = fread(ciphertext, sizeof(unsigned char), 16, in)) > 0)
{
   if (firstRound)
    {
        aes_encrypt(IV, output, key, size);
        firstRound = 0;
    }
    else
    {
        aes_encrypt(input, output, key, size);
    }
    for (i = 0; i < 16; i++)
    {
        plaintext[i] = output[i] ^ ciphertext[i];
    }
    fwrite(plaintext, sizeof(unsigned char), read, out);
    memcpy(input, output, 16*sizeof(unsigned char));
}

Putting it all together

Now that we have explained and implementing our three modes of operation, all that is left is to put them all together into one piece of code.
Encryption:

void encrypt(FILE *in, FILE *out, enum modeOfOperation mode)
{
    /* the non-expanded keySize */
    enum keySize size = SIZE_32;

    /* the AES input/output */
    unsigned char plaintext[16] = {0};
    unsigned char input[16] = {0};
    unsigned char output[16] = {0};
    unsigned char ciphertext[16] = {0};
    unsigned char IV[16] = {0};

    /* the AES key */
    unsigned char key[32] = {0x0};

    /* char firstRound */
    char firstRound = 1;

    long int fileSize;
    size_t read;
    int i;

    if (in != NULL)
    {
        fseek(in,0,SEEK_END);
        fileSize = ftell(in);
        fseek(in,0,SEEK_SET);

        /* add the file header */
        fwrite(&mode, sizeof(mode), 1, out);
        fwrite(&fileSize, sizeof(fileSize), 1, out);

        while ((read = fread(plaintext, sizeof(unsigned char), 16, in)) > 0)
        {

            if (mode == CFB)
            {
                if (firstRound)
                {
                    aes_encrypt(IV, output, key, size);
                    firstRound = 0;
                }
                else
                {
                    aes_encrypt(input, output, key, size);
                }
                for (i = 0; i < 16; i++)
                {
                    ciphertext[i] = plaintext[i] ^ output[i];
                }
                fwrite(ciphertext, sizeof(unsigned char), read, out);
                memcpy(input, ciphertext, 16*sizeof(unsigned char));
            }
            else if (mode == OFB)
            {
                if (firstRound)
                {
                    aes_encrypt(IV, output, key, size);
                    firstRound = 0;
                }
                else
                {
                    aes_encrypt(input, output, key, size);
                }
                for (i = 0; i < 16; i++)
                {
                    ciphertext[i] = plaintext[i] ^ output[i];
                }
                fwrite(ciphertext, sizeof(unsigned char), read, out);
                memcpy(input, output, 16*sizeof(unsigned char));
            }
            else if (mode == CBC)
            {
                /* padd with 0 bytes */
                if (read < 16)
                {
                    for (i = read; i < 16; i++)
                        plaintext[i] = 0;
                }

                for (i = 0; i < 16; i++)
                {
                    input[i] = plaintext[i] ^ ((firstRound) ? IV[i] : ciphertext[i]);
                }
                firstRound = 0;
                aes_encrypt(input, ciphertext, key, size);
                /* always 16 bytes because of the padding for CBC */
                fwrite(ciphertext, sizeof(unsigned char), 16, out);
            }

        }
    }
}

Decryption:

void decrypt(FILE *in, FILE *out)
{
    /* the non-expanded keySize */
    enum keySize size = SIZE_32;

    /* the AES input/output */
    unsigned char ciphertext[16] = {0};
    unsigned char input[16] = {0};
    unsigned char output[16] = {0};
    unsigned char plaintext[16] = {0};
    unsigned char IV[16] = {0};

    /* the AES key */
    unsigned char key[32] = {0x0};

    /* char firstRound */
    char firstRound = 1;

    enum modeOfOperation mode;

    long int originalFileSize = 0;
    size_t read;
    int i;

    if (in != NULL)
    {
        fread(&mode, sizeof(enum modeOfOperation), 1, in);
        fread(&originalFileSize, sizeof(originalFileSize), 1, in);

        while ((read = fread(ciphertext, sizeof(unsigned char), 16, in)) > 0)
        {
            if (mode == CFB)
            {
                if (firstRound)
                {
                    aes_encrypt(IV, output, key, size);
                    firstRound = 0;
                }
                else
                {
                    aes_encrypt(input, output, key, size);
                }
                for (i = 0; i < 16; i++)
                {
                    plaintext[i] = output[i] ^ ciphertext[i];
                }
                fwrite(plaintext, sizeof(unsigned char), read, out);
                memcpy(input, ciphertext, 16*sizeof(unsigned char));
            }
            else if (mode == OFB)
            {
                if (firstRound)
                {
                    aes_encrypt(IV, output, key, size);
                    firstRound = 0;
                }
                else
                {
                    aes_encrypt(input, output, key, size);
                }
                for (i = 0; i < 16; i++)
                {
                    plaintext[i] = output[i] ^ ciphertext[i];
                }
                fwrite(plaintext, sizeof(unsigned char), read, out);
                memcpy(input, output, 16*sizeof(unsigned char));
            }
            else if(mode == CBC)
            {
                aes_decrypt(ciphertext, output, key, size);
                for (i = 0; i < 16; i++)
                {
                    plaintext[i] = ((firstRound) ? IV[i] : input[i]) ^ output[i];
                }
                firstRound = 0;
                if (originalFileSize < 16)
                {
                    fwrite(plaintext, sizeof(unsigned char), originalFileSize, out);
                }
                else
                {
                    fwrite(plaintext, sizeof(unsigned char), read, out);
                    originalFileSize -= 16;
                }
                memcpy(input, ciphertext, 16*sizeof(unsigned char));
            }

        }
    }
}

Tutorial: Data Types and Structures

HTML version soon, please use PDF