I thought I didn’t like markup abstraction for templating; abstracting away from HTML leaves you with less control of your markup, and source code that looks quite different to what you get when you press View Source, so can be harder to debug – that was my thinking. But HAML has caught my interest (for now at least).
It gives you tersity for the common cases, but the power to make your markup how you like it when you don’t. It also looks quite readable by default because it uses a pythonic system of significant white space.
And it struck me that there are two possibilities in HAML of interest to the RDF-inclined web developer:
#me.-foaf-Person
.foaf-firstName Keith
.foaf-lastName Alexander That’s eRDF in HAML, though that just comes out as nested divs, so you’d probably want to use some different tags, and write it as:
#me.-foaf-Person
%span.foaf-name
%span.foaf-firstName Keith
%span.foaf-lastName Alexander
You can of course use variables as well as literals - anything after an = will be interpreted as ruby.
Now, HAML doesn’t do this of course, but I reckon it wouldn’t take too much tweaking to make it do so. Take a look at this example from the HAML docs:
# file: app/controllers/users_controller.rb def show @user = CrazyUser.find(15) end # file: app/views/users/show.haml %div[@user] # is compiled to:
Basically, you populate the @user variable with an object, and the templating engine takes the class type and the id of the object to create the html attributes of the div.
What I’m thinking is, similar to the eRDF-T system I’ve blogged about previously, you can have a controller that, on being passed the URL being requested by the user, uses that URL as a resource URI to retrieve data about from the triple store. The controller could then (using ActiveRDF for instance, since we’re using ruby already) create an object with that data – or methods to retrieve it on the fly – and assign it to a @resource variable.
You could then (after tweaking HAML) write templates something like: %div[@resource]
%h1 = @resource.dc::title Which’d render as:
How to make friends and influence people
To make dynamic web pages, you basically have to specify 3 things:
In MVC style web apps, you typically split the first task over two stages: querying the database in the model, anid assigning the data to variables in the controller. The second and third steps are spread over the controller and view: putting data into variables, and embedding the variables in the output format..
By using the approach above, you can specify all three in the one template. This might sound like a bad thing because separation of concerns is, after all, a good thing. But we aren\'t talking here about a mess of ad hoc SQL queries, tag soup, global variables, and print statements. And I\'m not sure that MVC is separating concerns in this case. It seems more like it\'s dragging out a process across extra stages that could be performed generically by a script exploiting sensible naming conventions (eg:the @resource object has dynamically added methods named after the rdf properties they access), rather than requiring rather predictable configuration by the programmer.
I think this could be an improvement over the eRDF-T approach because you still get semantic markup, you still only have to express those semantics once, but you get more flexibility when it comes to computed values (which are awkward to express as triples), the syntax is terser, and possibly more maintainable, and by decoupling the input semantics from the output semantics, it\'s easier to apply to non-html formats, and gives the template author more choice.
So does this make markup abstraction worthwhile?
eRDF Ruby HAML N3