Rails Mockup Driven Development with Lilu

Posted by Sebastien Auvray on Jul 05, 2007

Sections

Development,

Architecture & Design

Topics

Design ,

Ruby on Rails ,

Ruby

Tags

Templating ,

Rails

There was a debate 2 years ago about Rails and its lack of a built in templating language, and whether one should be introduced. Today there are more than 5 templating systems: ERB, HAML, Liquid, Amrita2.  All of them however mix Ruby or Ruby derivatives with HTML. Yurii Rashkovskii has now introduced a new templating system called Lilu.

Lilu is an approach (and tool) that allows to keep Rails views untouched without all that Erb soup inside.

Lilu aims to fully separate HTML from actual data being inserted in it (ala Tapestry for Java) making it easier to maintain and read for pure HTML coder.

Lilu is leaving you with pure HTML and lets you write instructions to update them with actual data.

Yurii Rashkovskii gave a presentation at Oslo's Ruby Tuesday about Lilu giving simple examples like this:

Static XHTML Mockup app/views/blog/post.html

<ul id="found_users">
  <li id="found_user">
    <h1>John Doe</h1> 
  </li>
</ul>
<h4 id="no_matching_users">No matching users found</h4>

With its given Lilu code  app/views/blog/post.lilu

if @users and !@users.empty?
  populate('#found_user').for(:each,@users) do |user|
    mapping 'h1' => user.name
  end
  remove('#no_matching_users')
else
  remove('#found_users')
end

DHH was skeptical about how a fully HTML/code decoupled templating system would handle complex productivity techniques like layouts or partials. But Lilu supports partials as well.

In the V is for Vexing presentation given at RailsConf07 Bruce William gave an overview of the main Rails templating solutions with their pros and cons. Lilu should be added to the list. The pros are a clear separation of the code & HTML allowing for easier HTML maintenance and collaboration with designers. The cons are poor performance next to erb, an early stage project and the fact that it's not a Rails standard.

2 years ago, David concluded that:

The pursuit of "no code"-templates reminds me of the search for the holy grail of the MDA camp with "no code"-programs. It's mirage, but its also a play on words of the "a rose by any other name..." variety.
[...]
So. If you want to try this out, feel free. Should a truly non-intrusive solution emerge, I shall even give it serious thought as whether to include it.

It should be interesting to know if this stills holds true with the arrival of Lilu and Amrita2.

1. Back to top

   DHH is oh so opinionated

   by Michael Klishin

   We all know DHH is way too opinionated, so what? This approach is much better for HTML coders and mockuping practices to my mind.
   
   Anyway Lilu and Erb still may co-exist.

   Reply

2. Back to top

   DRYML

   by Antonio Salazar

   Though not quite as clean, I suppose, as this, DRYML (hobocentral.net/manual/chapters/3_dryml.html) part of Hobo (hobocentral.net/) made it possible to strip Ruby out of the view some time ago.

   Reply

3. Back to top

   On David's opinion

   by Alex Popescu

   The pursuit of "no code"-templates reminds me of the search for the holy grail of the MDA camp with "no code"-programs. It's mirage, but its also a play on words of the "a rose by any other name..." variety.

   
   
   According to this analogy, I think MDA camp may start succeeding soon, because I know a couple of frameworks that are successfully using pure HTML for renderization for a couple of years already. The first that come to my mind: RIFE, Wicket, Tapestry... and I am pretty sure there are a couple more out there.
   
   bests,
   ./alex
   --
   .w( the_mindstorm )p.
   ________________________
   Alexandru Popescu
   Senior Software Eng.
   InfoQ TechLead&CoFounder

   Reply

• Older >