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.

There are some major faults with my column-HTML posts below: "If I have seen further it is by standing on the shoulders of giants." -- Newton

Of course, the key part of the quote is that it is a wise move to find some giants and stand on their shoulders. In my case I stood around on tiptoe trying to see as far as possible because I couldn't immediately find a friendly giant to stand on. Thanks for everyone who commented and pointed out where the giants hang out.

So, in summary:

To put columns in any order, don't do the complex nesting stuff I recommended in this post, instead, use negative margins, as described here.

And secondly, don't use a zero pixel div with clear:both that I blogged here, use overlap:hidden in the outer div instead.

So basically, do it differently to the way I said :D

Thanks again everyone for the help.

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!

RIAs make this even harder, and most developers don't seem to bother at all. That's fine if your RIA is going to be used by employees or partners (i.e. people who know where to find it), but not if it will be public facing.

Fortunately, there's an easy way make your RIA search engine friendly.

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.

If you have a bunch of components in a Flex Canvas, and show/hide/animate them with states and transitions, the components can change z-order on you without warning. I had a pernicious problem today with something like:

<mx:Canvas> 
 <mx:Panel id='content'/> 
 <mx:Panel id='tool_palette'/> 
</mx:Canvas>

Where content started out behind tool_palette, but when the latter got hidden (using a RemoveChild node in a state), and reappeared (by transitioning back) it was shown behind the content panel. Clearly a problem.

The solution I found was to separate the objects into two canvases:

<mx:Canvas> 
 <mx:Canvas height="100%" width="100%"> 
  <mx:Panel id='content'/> 
 </mx:Canvas> 
 <mx:Canvas height="100%" width="100%"> 
  <mx:Panel id='tool_palette'/> 
 </mx:Canvas> 
</mx:Canvas>

which is a bit of a hack, but works. This is the first time I've missed old-flash's z-depth model.

Discovered today that if you try to programatically deselect the currently selected item in a ListBase subclass with selectedItem=null the change doesn't propagate to anything bound to {my_list.selectedItem}. In fact in my application it seems to permanently break the data binding.

Instead, to deselect a list item, do selectedIndex=-1, that seems to work.

So I've got something like:

 <mx:Button label="Clear" click="entries.selectedIndex=-1"/> 
 <mx:List id="entries" dataProvider="{my_data}"/> 
 <components:MyEntryDisplay entry="{entries.selectedItem}"/>

which is fine for me.

There are two issues. First is getting uploaded images into Flex. That's a topic for a future post (but basically you have to upload them to the server, then download them again).

The second is uploading a final image generated by Flex. And it turns out this is surprisingly easy.

The last link in the chain is getting Django to generate XML easily. I wrote a very simple xml generating module that might proove useful.

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