Lilu and Rails

Posted by yrashk

I’ve commited initial Rails support for Lilu. Now you can try to install a plugin (svn://dev.railsware.com/lilu/lilu/trunk) and use the following naming schema:

 app/
   layouts/
      application.html
      application.lilu
   views/
      blog/
       post.html
       post.lilu

Typical application.html should contain complete HTML mockup where some element content should be replaced with actual data:

1
2
3
4
5
6
7
8
9
10

<html>
  <head>
    <title>Hello world</title>
  </head>
  <body>
  <div id="main">
        Body goes here
  </div>
  </body>
</html>

application.lilu is pretty simple:



update('#main').with yield

or even



replace('#main').with yield

post.html could contain either full page with blog post or blog post design itself. in first case, you should prepend your post.lilu with something like use(’#post’).

1
2
3
4

<div id="post" class="post">
  <div id="title">Hello, world</div>
  <div id="text">I'm Lilu!</div>
</div>
 
1
2
3
4
5

# Uncomment this if you have full page design in your post.html
# use('#post')
update('#post').with :id => @post.id,
                     '#title' => { :id => "title-#{@post.id}", self => @post.title }, 
                     '#text' => { :id => "text-#{@post.id}", self => @post.text }

That’s it, first Lilu + Rails experience. The above code is just from my head (too lazy to check exactly this code right now), so it can contain some minor bugs.

And yes, current Lilu implementation most probably contains bugs and problems. It’s quite young—it’s only few days old. I hope it will be getting better and better each day. I’m working on this.

Comments

Leave a response

  1. Aris Bartee – May 09, 2007 @ 01:49 PM

    I like the file placement, it makes a lot of since. I’m not sure about how I like the syntax for { :id => “title-#{@post.id}”, self => @post.title } but I’ll play with it see how manageable it is.

  2. Dr Nic – May 10, 2007 @ 01:26 AM

    So with no/minimal code inside the template, this will make caching super easy?

  3. Dr Nic – May 10, 2007 @ 01:29 AM

    Is it “worth” making the lilu syntax as similar as possible to the RJS syntax? In a way, they perform the same job: lilu on the server side and rjs on the client side?

  4. Yurii Rashkovskii – May 10, 2007 @ 09:34 AM

    Dr Nic,

    I’m not sure it is worth making the Lilu syntax as similar as possible to the RJS syntax. They serve somewhat different purposes and slightly different approaches.

    Anyway, I would like to experiment with current Lilu syntax. It will be never late to add RJS-compatible API if there will be a real need to.

  5. jherber – May 20, 2007 @ 03:48 PM

    dr nic – rjs uses more of a html structure centric dsl, and doesn’t rely on div naming. Y’s technique reminds me a bit of tapestry, the way it maps components into an html page. then, there is also prototype’s dsl for modding html elements and their values. now we have 3 ways to address and modify content or html structure.

    totally off the wall, but maybe of value. Yurii could also do something like ship the template to the client and parse lilu into javascript commands that do his bidding on the client. this dual approach for where the processing takes place might be handy if your content is very dynamic, and server cpu cycles are expensive for you at the moment.

  6. Yurii Rashkovskii – May 20, 2007 @ 09:18 PM

    jherber,

    actually I was thinking about two renderers already (HtmlRenderer instead of Renderer plus JSRenderer). It’s highly possible that next version will contain JS renderer.