Life is grand

Two punkish lads, one named Hampton Catlin, drinking Stella giving a talk on HAML; a new templating engine for Rails views.

HTML Markup Abstraction Layer. But that doesn’t matter, it just sounds cool as Hampton says.

Like most of us Hampton loves Rails but thinks RHTML is, well, just PHP warmed over.

HAML has principals. The first rule of HAML is… it has to be beautiful. Like the rest of Rails. The second one is XHTML is repetitive and prone to errors. The other two are irrelevant.

So, an example. Before:

<div><p>Hello, World</p></div>

After:

%div
  %p Hello, world

Like YAML it is double-spaced though this will be made flexible eventually.

HAML is like a Haiku, says Hampton.

Scarily, there are no blocks; No loops, no conditions. The simple answer is a list_of helper. Not sure about conditions and control structures yet. I’ll have to give it a shot later.

Ah, the Stella is for his nerves. Brilliant.

One of the best things about HAML is it indents properly. Thank god. RHTML is terrible at that.

Get the plugion at unspace.ca/discover/haml.

An interesting idea overall and it seems to work in most cases.

One thing I have learnt in this conference is that Windows laptops seem to connect better to busy Wifi networks than Macs. Bloody annoying.

(code and slides)
Dan Webb’s Unobtrusive Ajax With Rails talk proved so popular yesterday that it is being redone in the main hall during lunch today.

Unobtrusive Ajax (or JavaScript really) is all about removing all those inline onclick=”return myFunc(an_id)” bits of code from your HTML and into your JS. Separating behaviour and mark-up. Attaching behaviour to your class definitions e.g. class=”productbutton”.

At the very least this makes your pages smaller (think of a 1000 item list which has onclicks inline vs. attached via a class in a separate JS.)

At the most it is the idea of the class assigned to HTML elements.

A big theme is graceful degredation for when JS is not available.

A good point is around a href=”#” which semantically and functionally doesn’t make sense. I am an offender here but aim to change.

button_to is a little known Rails helper that generates a button in a form. This is for when you should be using buttons and not links e.g. for delete links. Remember, links should not have side effects (if for no other practical reason than avoiding pre-fetch technologies like the Google Toolbar that will wipe your records.)

To get started with UJS checkout the Rails plugin at ujs4rails.com.

A good talk and as Dan says, it isn’t rocket science. It has obvious benefits even if you don’t care about semantics. Hopefully Rails takes the ideas into the trunk.

Check out the new interface for PXN8. It is a big improvement from the current look which was on an already powerful system.

Trying to get a diagram together that explains the bits of a modern Ajax driven web client to fellow techy co-workers.

So you have the data Object Layer (JSOL), the Control Layer (JSCL), the Display Layer (JSDL), the data Fetch and Post layers (JSFL and JSPL) and then the UI and XmlHttpRequest object. That is all client side communicating through a managed (JSFL, JSPL) XmlHttpRequest pipe with the web services on the server.

Effectively it is a MVC (Model View Controller) architecture but on the client side, in the browser.

A user may hit a button on the client which the JSCL picks up. It checks the JSOL to see if the required data is there, lets say it is not. So it then tells the JSFL to fetch the required data which goes through to the web services and then responds back up to the JSCL which updates the JSOL. The JSCL then fires the correct view in the JSDL which gets the data out of the JSOL and sticks it into the UI via the DOM.

If it is a data change then the JSCL will update the JSOL and tell the JSPL what data to update on the server.

Some of the principles of the architecture are:

1. Only the JSCL interacts with the JSOL. The JSCL will update data when either fetched from the server or changed through the UI. It will send data to the UI via the JSDL and to the server via the JSPL.
2. The JSPL and JSFL have their requests managed by the JSXM which unifies such tasks as batching and caching.
3. The JSDL consists of views which when filled with data are inserted into the UI’s DOM. The JSDL doesn’t have any logic in it, just templates really. The JSCL does the logic.

I am wired up thanks to an Ajax presentation I gave to the lads at The TSSG earlier. I am not used to giving them and still get nervous up in front of 30 Irish engineers. It seemed to go OK. You can download the PowerPoint presentation here (1.8Mb PPT).