Today is Queen's Day in the Netherlands and this means that I have a day off from work. The good thing with public holidays of this kind is that you cannot really do anything else so you can focus on the things you wanted to do for a while. In fact what I did was updating the technical back-end of my blog. Most visible is that M$ Internet Explorer is now supported for the front-end. The other new features is that the entire system uses a real REST approach for client-server interactions, some CSS enhancements, a more nicely behaving XSLT Frontend and minor fixes in the Wiki engine.

CSS Enhancements

The last days I learned a lot about the smart concepts of CSS. Unfortunately, these tricks are hardly found in any CSS Book nor supported by all browsers. Namely Microsoft's Internet Explorer 7 shows too often the wrong behaviour when it has to handle CSS formatting. Despite all the quirks I updated a rich part of the dialog handling of the front-end.

XSLT Front-end improvements

The XSLT front-end was the main problem why the M$ Internet Explorer did not work previously. The blog uses a loose widget-binding approach. This means that the widgets are not hard coded in the javascript as it is done by so many javascript widget libraries. Instead the front-end loads XSLT stylesheets from the server to render additional widgets on the user interface. This allows to reduce most of the user interface functions to a few lines of code.

To push this even further I wrote a javascript XSLT manager already some time ago. It hides all the browser specific code from the main application and offers some CSS manipulation functions. The XSLT manager keeps a central repository of the application's widget stylesheets. Each stylesheet in this repository is named, so the application can perform some command by referring to the name of the stylesheet.

In order to support M$ Internet Explorer, I rewrote the XSLT manager almost completely. The code became cleaner and is now easier to extend (e.g to support Opera, or Konquerer). Moreover, the XSLT manager will not load all stylesheets from the server when the XSLT manager is initialised, but loads each stylesheet only if it is actually requested by the application. That reduces the network traffic a bit and keeps the server statistics clean.

Finally, I adapted the application code, so it passes server specific configuration parameters to the widget's XSLT. This feature of XSLT 1.0 is so cool that I always wonder why I don't use it more often.

REST Client-server Interaction

This blog is implemented as a web-service. There are two main approaches to deal with web-services on the World-wide Web. The most commonly known approach is SOAP. It is quite powerful, but has some limitations. First, it makes almost no use of HTTP's commands for invoking remote procedure calls (RPC) on the server. That way SOAP is not limited to HTTP as a transfer protocol, but can be used on a variety of network protocols. The second limitation is that SOAP handles only XML information. This makes it difficult to transfer other formats to these services, unless one encodes this data into the XML structure. This comes with the price that binary data will increase in its size when it is transfered in a SOAP envelope. The second approach is REST and does not have these limitations. However, it comes with the price that REST is strictly bound to HTTP.

The previous incarnation of this blogging system was based on REST-like RPC. I simply encoded all operations as URLs and did not use of the HTTP commands too much. Unfortunately, that approach made the system very complex to extend. Therefore, I decided to write a more REST conform client server interaction layer. All the information in the system is now well defined by URLs and all RPCs are triggered by HTTP commands. So far, the blogging system understands three functions:

• store triggered by HTTP POST or HTTP PUT
• get triggered by HTTP GET
• delete triggered by HTTP DELETE

I had to utilize HTTP POST and HTTP PUT for the store function, because all current web-browsers deny AJAX applications to have access to files that user wants to upload to the server. The rest is pretty straight forward.

I was quite surprised that the transition from the old to the new approach went without any problems, because I rewrote the entire RPC invocation code. But the new code is much more simple than the previous solution.

Server Configuration

The last step turned out to be very important. For the initial installation I spent hours on resetting all the configuration parameters for the production server. I did not want to go through the same problem over and over with each update of the system. Thus, I put all the configuration information into external configuration files (for the server that is the apache configuration file). That makes future transitions from the development server to the production server much easier.