It needs to work such that the same piece of JavaScript can be utilised without modification for any decision tree tool we build on the site, with a very simply-defined markup structure,

So I’ve been self-administering repeated doses of headdesk/facepalm over the last couple of days, but I came back today after a Friday lunch (you know what I mean) and found a solution. It’s not pretty, with at least two nested ‘for’ loops, but it works.

I’ve created a JSFiddle of it, so you can take a look at it, modify it, laugh at it, etc.
Open it in JSFiddle or see it embedded below:

We have a complex XML file with many different node types, etc. supplied by a third party via a URL reference.
There’s an initial dump, and then an incremental update every couple of weeks, with additions, deletions and updates.

What I’d like to be able to do is to drive a symfony app with this data.

Some thoughts so far

I’m a symfony noob.

Getting the data

I could manually transform the XML into YAML to create the schema and the initial data load, and then build the app. But I don’t want to have to do this manually for the regular updates. Ideally, I’d like to use the symfony ORM to handle all the transactions, rather than a completely separate (outside symfony) script.

… and some images

The XML also contains URIs for remotely hosted images, and I’d like to be able to automagically pull these down to the local app file system and rewrite the references.

Anything that will help us to get started in the right direction would be greatly appreciated.

Well, up until recently, I’d always just called on an old friend, .clearfix, and he’d sorted it out for me. I met .clearfix three or four years ago, and hardly a project has gone by since where I haven’t required his services. You know, I didn’t really ask him how he did it; he’d just quietly go about his job as I directed him, much like Michael Clayton, but without the gambling problem.

But yesterday, when I asked him to help out a colleague for me, little did I know I’d given him his last assignment.

Something happened early this morning – completely coincidentally. A little bird (or rather a tweet) came by and told me that, despite the fact Blueprint CSS uses .clearfix, .clearfix was no longer the way to go. And to be honest, it was almost a relief; the reason I’d never really asked .clearfix how he did his work was that deep down I knew that he was really a hack, and that if I just turned a blind (or ignorant) eye, then I could just pretend like everything was okay and we could all just carry on getting work done.

.clearfix is indeed inelegant, and really is a hack. And would you believe that the alternative solution is not so tricky…
Using overflow: auto; (or overflow: hidden;) on the container with a width will sort it all out for you.
Rather than explain it all here, I’ll just link to a few articles that have already put further effort into describing this:

• PPK’s Clearing floats
• Alex Walker’s Simple Clearing of Floats
• nclud’s Mind The Gap: clearfix is clearly broken

So, farewell, .clearfix, you’ve served us well.
…and thank you, MB, for the enlightenment.

So is it that they are written in aspx which makes them bloated?.

Well, I guess that’s what I’m kinda implying.

Building in the .NET framework with the Visual Studio IDE tends to mean that lots of components and snippets are provided for you. So by default you get things like having all your page content wrapped in a <form> element and you get the lovely __VIEWSTATE hidden input field and stuff like that.

I think that there can be a tendency amongst back-end developers, i.e. .NET, Java developers, to produce something that works well technically, and then take the PSDs that the designer gave them and put them on the front, so you’ve got something that looks like it’s supposed to, and works kinda like it’s supposed to, but with the interface between the front- and back-ends being very ugly, slow, and inefficient. Of course this has an often considerable negative effect for the end user.

While this may be a generalisation, I’ve experienced it first-hand, with developers who struggle to understand, or at least show some care, about good clean lightweight, semantic front-end code that performs well in the browser.
When you’re developing with .NET in an IDE like Visual Studio, you have to put in a bit more effort to get that good code.

Developing in .NET doesn’t necessarily produce bloated code, but I think if you took a look at the average .NET (.aspx) site, I think you’ll find greater code-bloat than in your average hand-crafted-in-TextMate code.

But lately, I’ve come across a few sites that have made me cringe; a colleague pointed out a couple of Swiss ones: migros.ch, and gate24.ch, and I came across the new upandgo.co.nz site on newsites.co.nz.

Let’s look at some stats, with vodafone.co.nz (my old gig) thrown into the mix:

The first three sites are ASPX sites, with bloated, invalid, (W3C) table-based markup, and what appears to be no performance tuning whatsoever. Sure, they are visually heavier than vodafone.co.nz, but being visually heavier doesn’t necessarily equate to looking better, and more often the end-user benefits of the visual components are offset by the performance overhead they introduce.

So, if you’re a web developer and you don’t use, or know of, Firebug and YSlow, stop what you’re doing right now and get familiar with them. Chris Pederick’s Web Developer toolbar for Firefox is also invaluable.

Learn about ETags, far future Expires headers, gzip, script placement, semantic markup, reducing the number of HTTP requests.

These are all vital factors in presenting a great website.
Figure out what you can do to make your site lighter, faster, and more search engine-friendly.

I must say, it’ll take a bit of getting used to.

A good friend of mine has, over the years, written a few applications that require graphing. He has written them as VB applications and when I’ve suggested he make them as web-apps, one of his fairly valid objections is that it would be tricky to create good-looking graphs with dynamic data.

Google’s Charting API

So just this morning, the Barnacle drew my attention to Google’s new Charting API (Read the Developers’ Guide). It takes some query string parameters and returns your chart as an image.

Check it out:

Now that’s pretty cool, isn’t it?
Although I think the data encoding, while clever, seems a little quirky.

Flot for jQuery

And so having spotted that this morning, I’m stumbling around the net this evening and discover Flot, a charting plug-in for jQuery. This is teh awesome; just check out the examples, especially the zoom!

So, while you’re waiting for other browsers to support SVG, here’s a veritable choice of quality charting goodness to satisfy the most particular of needs.

I’m not sure what happened to the page I linked to the other day; it seems to be down. [Edit: Here's the google cache of that page.]

There are a few good lessons that can be learned here:

• If you’re going to have any sort of site with user accounts, ongoing earnings, prizes, etc. and/or anything that can convert or relate to actual monetary value, then I’d recommend not using a standard open-source platform (i.e. Joomla). If there’s money involved, then you’ll quickly attract hackers.
• Don’t attempt to do any sort of worth-related calculations client-side, returning a response via a form POST. Any savvy geek will mess with the HTTP headers (using Charles, for example) and will get rich quick.
• Get your site a proper security audit from an outfit like security-assessment.com. It can cost a few grand, but for the sake of an embarrassing mess, I’d say it’s money well spent.

I’m interested to see what will ensue.

I must say, I wasn’t overly impressed with Mintshot’s shoddy layouts and presentation, but I never thought it would be so crappy underneath!!