However, the film feels like a cast and crew reunion with Indy as the guest of honour, swept along in the action rather than being the dynamic pivotal character. After the ‘fridge’ scene, Indy was never in any believable danger and the minimal romance aspects of the plot didn’t allow Harrison Ford a chance to fully deliver his famous wise-guy charm.

Overall though definitely worth a watch. Real value for money in terms of sheer entertainment.

However, there normally comes a point when the client wants to do something a bit different. Lets say that rather than maintaining a simple list of FAQs with Collections, they want to create a knowledge base of articles. Up to this point clients have had to re-purpose a set list of properties for each 'Collection Item'. The fields were: publish date, title, summary, thumbnail and link. Thanks to a bit of ingenuity on the part of our developers, these properties were sufficiently generic to be useful in a range of scenarios from making a randomly rotating banner to an events list to a simple photo gallery with albums. I was surprised how flexible something so statically defined could be. That said, the fields weren't all used all the time and since the labels were generic, sometimes it has hard for the client to relate which form fields affected the final output on the website. In short we needed something more scalable and user-friendly. We needed 'custom' Collections where the form fields could be configured for each type of content the client required. We needed a way to model content.

It so happened that the way in which I'd designed the database earlier abstracted the notion of a schema for Collection Items away in favour of storing name/value pairs to facilitate versioning. In fact the static properties discussed above (title, summary etc.) were only enforced as hard-coded items in PHP. Good so far but I needed a way of mapping some sort of structure to the data on its way into the database as well as on its way out.

XML was the answer. For each 'Collection' of content added to the site, a collection type is used to provide a 'content schema' for the data. The basic idea is to have a single XML file that carries just enough information to build a form, validate the user input (and filter it if necessary) and then store the data entered.

A sample collection type is shown below:

As you can see the XML schema is fairly simple. Each collection type gets a node with a unique identifier by way of the 'guid' attribute. This GUID gets stored in the database along with the name and description node values for each Collection and the GUID is used in an XPath query to retrieve the schema from this document at runtime.

The property nodes define the actual form fields that appear when the user adds/edits Collection Items. There are various property types which relate to the interface elements used when the form is rendered. Other attributes on each property node relate to how the data should be validated and filtered (such as have the entered text made uppercase or hyperlinks made clickable). Some more attributes specify default values that should be used, whether values should match another field, be unique etc.

The settings node in the XML document is used when the Collection records are viewed in the Content Management System. The attribute values are used to determine which properties are displayed in a datagrid and which can be searched.

And so, the XML simply defines a form to be rendered but also, the fact that we have a record of the structure of the stored content means that we can use this to publish content from the database into HTML (by means of templating), XML (by using the 'id' attribute of each property node as the tag names) and even to an SQLite database. Since SQLite supports only a few simple data types I was able to simply map the property types (taking into account their validation rules) and create an SQLite database for each Collection on the fly. This proved to be an ideal solution for reasons I've mentioned before.

So modeling simple content with XML is a very useful way to make your Content Management System flexible and because the content model is not stored recursively in your database, getting at the schema is simple and quick. If you're planning a CMS then I'd strongly recommend this approach

General Programming

• Aptana - PHP and Subversion integration, Dreamweaver "Ctrl+U" upload goodness.
• Beyond Compare - Compare folders, zip files, FTP sites. Integrates well with Tortoise SVN and Tortoise CVS.
• Notepad++ - Excellent file support, the right balance of being lightweight and feature rich for a text editor.
• Tortoise SVN - Windows Explorer integration, very easy to use and unobtrusive Subversion client.
• Enhanced Windows Console - A recent find but looks very useful.

Design Tools

• Color Cop - Simple, no-nonsense colour picking.
• @icon sushi - A really good little .ICO file editor

Flash Development

• FlashDevelop - Nice integration with open-source Flash compilers etc. Better than the ActionScript editor in Flash IDE anyday.
• ServiceCapture - Nice tool for debugging AMF, JSON and SOAP. Acts as a proxy for your browser and so can also be used to throttle bandwidth for testing.
• .sol Editor - A Flash Shared Object file parser and editor. Very handy indeed.

Network Tools

• WinSCP - Good SCP Client for remote file administration.
• FileZilla - Simple, lightweight and efficient FTP Client. A handy connection manager interface. Regularly updated.
• PuTTY - Command line console for remote server administration.

Database Design & Management

• fabFORCE DBDesigner - Great (but slightly buggy) tool for sketching out DB schemas visually. Will create/update/reverse-engineer databases.
• SQLite2008 Pro Enterprise Manager - Powerful tool for managing SQLite databases. I've found myself using this a lot lately.

.NET Programming

• SharpDevelop - Very lightweight compared to VS.NET. Perfect for the odd bit of ASP.NET 2.0 development.
• UltiDev Cassini Web Server - A No-frills (embeddable) web server for .NET written in .NET. A great development alternative to IIS.

As part of my work for Golley Slater Digital I've been architecting a PHP5-based CMS that uses the 'Push' model where content authored on a private 'admin' server is published to a public 'live' server to be viewed by end-users. Essentially, the CMS stores content in MySQL, writing it out as a hierarchy of static HTML (well PHP really) pages when the user elects to publish. These static pages, along with the other assets are 'pushed' live using RSync which copies them from one server to the other.

In addition to regular page content, there are other types of content such as 'Collections' that are used in the CMS and that need to be copied to the live server. A Collection is a list of structured data types, Collection Items, that are managed independently from page content. Collection Items have their own approval workflow, go-live dates etc. and can be bound to pages through the admin UI. Typically, Collections are used for News, Events, FAQ's etc. but really any content type that can be modeled with a simple structure is a candidate.

Now up to last month I had stored published Collection Items in XML which was parsed at runtime on the live site (The XML would get conveniently pushed live with RSync along with the pages). With PHP 5's improved XML support this was a reasonably performant solution and provided a basic storage mechanism for the structured data. But what if I had thousands of items in a Collection and wanted to perform a complex search to display the results over a few pages? Hmmmm. It was achievable with XML but was going to get tricky with XPath expressions and server resources would definitely suffer when parsing the XML and sorting arrays of data. I needed another way.

Enter SQLite! This database engine is embedded into PHP5, and was the answer to my woes. SQLite databases require no setup, passwords and are nothing more than regular files so they play very nicely with the RSync deployment scheme I use. On top of that since the vast majority of SQL can be used to query SQLite databases, searching and paging of results was going to be a breeze. So I made a change to the CMS that saw published collection items going into a local database rather than the XML.

Using SQLite means that the CMS can effectively queue-up content ahead of a display date and expire content at some point in the future. What's even better is that the published sites are still standalone in nature and do not need any knowledge of the CMS which created them.

O.k. so using SQLite is nothing groundbreaking but the application of it in this context made me stop thinking of a database as something at the bottom of a technology stack and as an portable and intelligent file format that can be shared between applications. Revelation!

If you're planning a CMS then I recommend you look at SQLite for creating hybrid static/dynamic pages. It certainly opened some doors for me.

Disclaimer: Yes, I used the word 'performant' in this post.  Apparently it's not a word but I like it. So Sue me.