RuHL presentation
For all of you that wanted so badly to attend the Atlanta Ruby User group meeting last night, but just could not make it, here are the slides from my talk on RuHL. RuHL is an HTML based template engine that thinks code in views is bad, presenters are good and testing your views should be easy.
Comments
Bleh! Seeing all that html drove us to haml in the first place. Why would I want to go back to that?
You wouldn’t. Code is still there. It’s just not Ruby. It’s something else. A swamp thing syntax muddled in with HTML (lipstick on a pig).
The abstraction, the abreaction! Horrid!
RuHL (like most projects) has been created to solve a problem. If you don’t understand it, then you must not have the problem. Instead of being intelligent and recognizing that fact, make childish remarks as if you’re going to be forced to use it against your will. These comments remind me of a child’s complaints to having to eat their vegetables or brush their teeth.
If you have constructive/insightful comments, I’d love to hear them. (‘FaIL’ was cute though.)
I would recommend adding (XML) namespaces.
Have a look at http://en.wikipedia.org/wiki/Template_Attribute_Language
Thanks baz. That thought came up early on in the project, but just faded as core features were being fleshed out. I agree it would be a good addition and could simplify the syntax. Thanks for brining it up, I’ll add a ticket on lighthouse so it doesn’t fall out of focus again.
How is this an improvement over HAML?
The initial idea that sparked RuHL was an improvement to Haml (simple iterators), but that quickly changed to a challenge to see if I could keep the HTML format and have all the same dynamic capabilities. After building up the project to support the major dynamic functions, RuHL was tested out on a project at work. What we found were other benefits.
Being that it stayed HTML, designers could take more part in the project without developer assistance. Designers didn’t have to have the app running to work on the views (no rendering required). As the template text can stay (RuHL replaces tag content), designers can redesign the site easily as most of their original comp is probably still there. We also found that not allowing code in the view meant helpers (or presenters) came into play a lot more. For us, testing these are much easier than traditional view testing. This turned out to be a major driving force behind sticking with RuHL (a nice surprise). View testing for RuHL involves checking the location and content of the data-ruhl attributes. Views are not rendered to test, just parsed with Nokogiri (there are helpers included in the library).
Not a lot of room here to go into more detail, but I do have a blog post in the works to describe the environment that we have and how we are architecting for company efficiency, not just developer efficiency. When you have teams dedicated to functions that shouldn’t require dev team assistance, make it so that’s the way it works.
So, as it turns out, RuHL is not intended to replace or improve Haml. Haml’s purpose/benefits are different than RuHL’s.
This looks like a TAL dialect. Have you looked at TAL (used by Zope, but there are also a variety of ports / re-implementations for other stacks and languages)?
Post a comment