Lets, for a simple example, imagine building an ecommerce solution for selling antiques. The antiques we have in stock all belong to one or more categories of antiques. So far so simple: an Antique model with a many to many relationship with a Category model. For each antique we need to store various bits of information: information on its quality, provenance, and damage. But, crucially, the information we need to store for each antique depends on its categories. So for a piece of furniture our shop browsers will expect certain information, while collectors of miniature paintings will expect others.

We could solve this problem by allowing each antique to have any number of properties, and then enter all the relevant information ourselves each time we put a new antique in the system. This would work, but be very error prone: we might forget a salient piece of data. It is also laborious, in most cases there are sensible defaults for propoerties that we'd do well to use. And it begs the question what data type do we store data in? Some properties might be dates, others quality levels, yet others names.

So we could create a fiendishly complex model where categories define certain required parameters, defining their default value and data type, and some flexible parameter table holds the paramaters that are non-default for a particular antique, in such a way that any data can be input (or maybe different parameter tables for different data types). It works but it is very inelegant and laborious to code.

There's got to be a better way.

This kind of polymorphism belongs in object-oriented code, not relational database semantics. In my application (which has nothing to do with antiques but I can't say what it is without giving the client away), I represent categories as classes: the django model holds the name of a class, each category maps to one class. That class then defines the required data and the defaults and the validation methods, and so on (they inherit from a base class, so most of this is pretty easy).

# A sample category class, with the properties it expects, and their data types.
class FurnitureAntique (Category):
   scratches = ListOf(LocatedDefect)
   period = TimePeriod()
   primaryWood = Choice(WOOD_TYPES)

The classes so defined are held in a simple registry (a dictionary mapping name to class)

# Add the category class to the registry, so it can be retrieved by name later.
Cateogry.registerClass(FurnitureAntique)

And the django database model for a category allows you to easily get the corresponding class.

# The django model representing a category of antique
class AntiqueCategory (models.Model):
   categoryClass = models.CharField(maxlength=64)
   def getClass(self):
       # Retrieve the corresponding category class from the registry by name
       Category.getCategoryByName(self.categoryClass)

Then I have another django model for the antiques. This has a text field that holds pickled data for its properties. I have added a method to the django model that will unpickle the data, find the classes for the categories, create and return a new instance of the category class with the unpickled data (below I've shown this where each antique has one and only one category, in my app it is a many to many relation, and for instances that belong to more than one category the correctly uses multiple inheritance and an anonymous class).

class Antique (models.Model):
    pickle = models.TextField()
    category = models.ForeignKey(AntiqueCategory) # Using a many-to-one for clarity here.
 
    def getCateogryInstance(self):
        cls = category.getClass()
        data = pickle.loads(self.pickle)
        return cls(**data)

This allows me to store any number of well-validated properties in the antique table, corresponding to validation requirements in the category table, without having to have lots and lots of tables in the database.

The downside is that I can't use the databases optimised searching systems (such as indexes) to search the pickled properties. In my application this doesn't matter (it would be difficult to create a user interface that allowed the user to specify such a highly polymorphic search in any case), but in other domains this may be a killer for this approach.

Now in the example above I'm using a very simple set of class properties in the Category class to define what properties we expect. Rather than create a whole new set of validation building blocks, I suspect I can reuse the newforms fields from Django for this same purpose (with the addition of fields representing compound data). But I haven't got far trying this yet. In my application parameters are all of one type (an enumerated choice), so I haven't need this yet, but I'm keen to have a go at some point.

If you're joining from there and are interested in RIAs, please leave a comment or subscribe. I think it would be great to get together and discuss issues particular to RIAs and django!

If you do something like:

<div id='outer'>
   <div style='float:left'>Content One</div>
   <div style='float:left'>Content Two</div>
   <div style='float:left'>Content Three</div>
</div>

and want div#outer to encompass the three content divs, you find a browser incompatibility. IE7 does that I want - the enclosing div encloses its children. Other browsers do what the CSS standard says is the right thing: div#outer is one pixel high and the rest of the divs descend below it.

I want it to work on all browsers, however. After various playing around I discovered that:

<div id='outer'>
   <div style='float:left'>Content One</div>
   <div style='float:left'>Content Two</div>
   <div style='float:left'>Content Three</div>
   <div style='clear: both; height: 0'></div>
</div>

seems to work. [Interestingly, although I'm working exclusively in XHTML, using <div/> doesn't work - the XHTML spec recommends that you don't have empty tags like div (anything that normally contains content), but this isn't a normative part of the spec, so browsers should really support full XML syntax in this regard.]

The application of all this is that I can now apply a vertically tiled 1px high background image to div#outer, with column shading on it, and have the different height columns all appear to be full-height - something that is very difficult to do by making the floating divs actually the same height. It is a solution that avoids many of the accessibility and fragility problems of the "one true layout" approach.

Combining this with the previous blog post I can now get full-height columns in any order, which is what I needed.

This post is about how to create DIV column layouts where the columns are given in the HTML in any order, but are displayed correctly when rendered, allowing you to have SEO-friendly content first in the HTML page, even if it appears in the middle of your column layout.

<div>
  <div style="float: left; width: 180px">
    Column One Content
  </div>
  <div style="float: left; width: 500px">
    Column Two Content
  </div>
  <div style="float: left; width: 280px">
    Column Three Content
  </div>
</div>

(note that I'm doing these examples with fixed column widths in pixels. I normally prefer fixed-width in ems, but you could also use percentages for resizing. This approach doesn't allow you have some flexible size columns and others fixed width, however)

But column one (in many cases a navigation toolset) comes first. For SEO optimisation I want content to come first. This may be in a different column. In fact, I'd like to be able to put my column content into the HTML in any order, but have the layout work.

It turns out this is possible in most cases, by wrapping sets of columns in further div tags, and floating them as a whole. So, for example, if in a three column layout we want the middle column first in the HTML, then the right column, then the left, we'd do:

<div>
  <div style="float: right; width: 780px">
    <div style="float: left; width: 500px">
      Column Two Content
    </div>
    <div style="float: left; width: 280px">
      Column Three Content
    </div>
  </div>
  <div style="float: right; width: 180px">
    Column One Content
  </div>
</div>

In other words we group columns 2 and 3 together and right float the group, then add the leftmost column, also floating right. The logic is that a set of columns can be either left-to-right ordered (if each is floated left) or right-to-left ordered (if each is floated right). So with a combination of groups you can get most layouts.

Only most? Well yes. I wrote some software to calculate all possible permutations. For two columns you don't need to group at all, for three you can get all possible permutations this way. For four columns there are two permutations that are impossible. That number increases to 30 (out of 120) for five and by six, most (394 out of 720) orders are impossible. I would hazard a guess, however, that six columns isn't near the top of the average designer's toolbox.

So here's the meat. These tables show the order of columns on the left, and an abbreviated layout code on the right. The example from above is

2, 3, 1: (←2, ←3)→, 1→

We want the column two to appear first, then column three, then column one (hence 2,3,1 on the left). The code on the right tells us we need to put columns two and three, each floated left, into a div that is floated right, followed by column one on its own also floated right: exactly what we had in the HTML code above.

If you want the tables for higher numbers of columns let me know, and I'll email you them.

I thought I'd start this blog to note down things I've found out, numskull moments and the rare bit of insight.