在两年前就有过一场争论，争论的焦点在于Rails 框架及它缺乏内建模板语言的支持，还有是否要为Rails 引入这样的模板语言。直至今天，已经存在有不下五种的模板系统：ERB、 HAML、Liquid、Amrita2 等等。然而所有这些都是将Ruby 语言或是Ruby 的派生语言与HTML 代码混合在一起。 Yurii Rashkovskii 最近引入了一种新的模板系统，称为 Lilu 。
Lilu 是一种允许保持 Rails 视图不变，使其内部无须含有 ERB 标签侵扰的方法（和工具）。
Lilu 的目标是让被插入在其中（按照 Java 中 Tapestry 的方式）的实际数据与 HTML 完全分离开，使保存并读取纯 HTML 代码更加容易。
Lilu 保证你得到纯粹的 HTML 代码，并使你通过编写指令来使用实际数据更新代码。
Yurii Rashkovskii在挪威奥斯陆的Ruby Tuesday 会议上进行了一次演讲，给出了如下的Lilu 代码示例：
静态XHTML 模仿 app/views/blog/post.html
<ul id="found_users"><br></br> <li id="found_user"><br></br> <h1>John Doe</h1><br></br> </li><br></br></ul><br></br><h4 id="no_matching_users">No matching users found</h4><br></br>同时也给出对应的 Lilu 代码app/views/blog/post.lilu
if @users and !@users.empty?<br></br> populate('#found_user').for(:each,@users) do |user|<br></br> mapping 'h1' => user.name<br></br> end<br></br> remove('#no_matching_users')<br></br>else<br></br> remove('#found_users')<br></br>endRails 创始人 DHH 对一个 HTML 和代码完全解耦的模板语言系统如何处像布局（layouts）和 partils 这样带来生产力的复杂技术持怀疑态度。但 Lilu 也提供对于 partials 的支持。
在 RailsConf07 大会上，Bruce William 在主题演讲 V is for Vexing 中给出了 Rails 模板解决方案的介绍，以及优缺点分析。Lilu 项目也应该被加入到列表之中。优点是 Lilu 将程序代码与 HTML 文档清晰的划分开来，允许通过 HTML 方便的与设计人员进行维护和协作。缺点有：1) 与 ERb 相比性能稍逊，2) 项目还处于早期状态，以及 3) 它不是 Rails 的标准之一。
两年前，David（即 DHH）这样总结到：
对“无编码”模板的追求，让我想起 MDA 阵营对“无编码”程序这个圣杯的找寻。这是一种海市蜃楼式的幻想，也就是和“把玫瑰换个名字”（译注：原文是“a rose by any other name”，语出莎翁《罗密欧与朱丽叶》第二幕第二场的“A rose by any other name would smell as sweet.”朱生豪先生译为：“姓名本来是没有意义的；我们叫做玫瑰的这一种花，要是换了个名字，他的香味还是同样的芬芳。”）如出一辙的演出。 […]
所以，如果你打算尝试一下这种方式，请自便。如果真的可能有一个完全非侵入性的（non-intrusive）解决方案出现，我将会认真思考是否要加入这样的特性。
现在有意思了：随着 Lilu 和 Amrita2 的到来，DHH 这段话是不是还当真呢？
暂无签名
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论