无逻辑模板(如胡子)的优势是什么？

最近,我遇到了声称是无逻辑模板的小胡子.

但是,没有解释为什么它采用无逻辑方式设计.换句话说,无逻辑模板的优势是什么？

1> Miguel Ping..：

---

换句话说,它可以防止你在脚下射击自己.在旧的JSP时代,JSP文件中撒有Java代码是很常见的,这使得重构变得更加困难,因为你的代码已经分散了.

如果您按设计阻止模板中的逻辑(如胡子一样),您将不得不将逻辑放在别处,因此您的模板最终会变得整洁.

另一个优点是您不得不考虑关注点分离:您的控制器或逻辑代码必须在将数据发送到UI之前进行数据按摩.如果您稍后将模板切换为另一个模板(假设您开始使用不同的模板引擎),则转换将很容易,因为您只需实现UI详细信息(因为模板上没有逻辑,请记住).

---

那么,为什么控制器代码必须以完全以特定方式呈现数据所需的形式按摩数据呢？为什么更改演示文稿通常需要更改控制器代码是一件好事？这对我来说似乎是件坏事.我认为模板语言的一个目标是将控制器逻辑与表示逻辑分开.一个无法做出任何决定的愚蠢模板迫使表示逻辑回到控制器代码中.在不同的人在演示中工作的组织中,他们不能自己完成工作.

---

您不应为控制器中的视图准备数据.控制器用于控制应用程序流.相反,您应该创建一个演示者类,将您的模型转换为视图模型,然后由视图使用.视图模型是UI的模型,它与作为业务逻辑一部分的模型分开.我建议你观看罗伯特"叔叔鲍勃"马丁的"清洁建筑与设计"演讲:http://youtu.be/asLUTiJJqdE

2> brad..：

---

在我看来,我感觉自己几乎是孤独的,但我坚定地站在对面的阵营中.我不相信模板中可能混合业务逻辑是不充分使用编程语言的全部功能的理由.

无逻辑模板的常见理由是,如果您具有对编程语言的完全访问权限,则可能会混合使用模板中没有位置的逻辑.我发现这类似于推理,你应该用勺子切肉,因为如果你使用刀可以割断自己.这是非常正确的,但是如果你使用后者,你将会更有效率,尽管是谨慎的.

例如,请考虑以下使用胡须的模板片段:

{{name}}:

  {{#items}}
    
{{.}}
  {{/items}}

我可以理解这一点,但我发现以下(使用下划线)更加简单直接:

<%- name %>:

<% _.each(items, function(i){ %>
  
<%- i %>
<% }); %>

话虽如此,我确实理解无逻辑模板具有优势(例如,它们可以与多种编程语言一起使用而无需更改).我认为这些其他优势非常重要.我只是不认为他们的逻辑性质就是其中之一.

---

我很惊讶你觉得下划线模板更简单..它对我来说看起来不太可读.只是一个意见:-)

---

@ ben-clayton我同意第一种语法更漂亮,也许更具可读性.然而,当我说"简单"时,我正在驾驶的复杂性.

---

@PaulShapiro您将在模板外部生成数组中的项目数,并将其存储在单独的变量中.

---

@brad,下划线模板引入了一个XSS漏洞:`name`和`items`可以包含JavaScript.

3> pje..：

---

胡子是没有逻辑的？

不是这个:

{{#x}}
  foo
{{/x}}
{{^x}}
  bar
{{/x}}

与此非常相似？

if x
  "foo"
else
  "bar"
end

而不是说非常相似(读:几乎定义)表示逻辑？

---

是的,如果你只是在评估一个对象的真实性,但是尝试做任何更复杂的事情都是不可能的(`如果x> 0 && x <10`)......那么,虽然有或没有可以使用Mustache逻辑,这取决于你.毕竟,它只是一个工具.

---

你正在以错误的方式看待这个问题.仅仅因为你可以用不完全符合其一般范式的语言做一些事情并不意味着语言不属于那种范式.您可以在Java或Haskell中编写命令式代码,但您不会说Java不是OO语言,也不是Haskell不是函数式语言.看一下这种语言可以让你轻松做什么,以及它带给你什么样的语言.

4> Jeremy..：

---

无逻辑模板是一个模板,其中包含供您填充的孔,而不是填充它们的方式.逻辑放在别处并直接映射到模板.这种关注点分离是理想的,因为模板可以很容易地用不同的逻辑构建,甚至可以用不同的编程语言构建.

从小胡子手册:

我们称之为"逻辑无",因为没有if语句,else子句或for循环.相反,只有标签.有些标签被替换为值,有些没有,有些则被替换为一系列值.本文档介绍了不同类型的Mustache标记.

---

描述稍微复杂一些,因为这些部分的工作方式与条件和循环相似,只是非常有限.在散列中引用callables的能力还允许您将节转换为基本编程语言.尽管如此,至少它会让这条路走下去,而不是鼓励它.

5> mattmc3..：

---

硬币的另一面是,为了将业务逻辑排除在演示之外,您最终会在模型中放置大量的表示逻辑.一个常见的例子可能是您希望在表中的交替行上放置"奇数"和"偶数"类,这可以通过视图模板中的简单模运算符来完成.但是如果您的视图模板不允许您这样做,那么在您的模型数据中,您不仅要存储奇数或偶数行,而且取决于模板引擎的限制,您甚至可能需要污染模型使用实际CSS类的名称.视图应与模型分开,全程.但是模型也应该是View不可知的,而这就是许多这些"无逻辑"模板引擎让你忘记的东西.逻辑在两个地方都有,实际上确实正确地决定了它的去向.是演示问题还是业务/数据问题？为了获得100%纯净的观点,污染只会落在另一个不太明显但同样不适当的地方.

在另一个方向上有一个不断增长的运动,希望事情会在更合理的中间地带的某个地方.

---

在那里不得不同意你的意见.无逻辑模板的表示逻辑不在模型中,它在视图中,它所属的位置.视图采用原始模型数据,并根据需要进行按摩(通过注释奇数/偶数行等)以准备进行演示.

---

我知道我迟到了,但CSS nth-item(单数)应该用于交替的行颜色.

6> blockhead..：

---

它使您的模板更清晰,它迫使您将逻辑保存在可以进行适当单元测试的地方.

---

花费三个月的时间使用逻辑模板语言(如JSP)处理系统,程序员不要热衷于分离逻辑和表示.您将发现构建一个基本上在页面中具有编程的系统 - 用于表格布局的算术,用于显示定价信息的条件,等等.模板语言是非常糟糕的编程语言,因此这使得开发和维护成为一场噩梦.像胡子这样的东西不会让你首先陷入这种境地.

---

你能用更多细节解释一下吗？

7> 小智..：

---

这种对话感觉就像中世纪的僧侣会争论有多少天使可以放在别针的末端.换句话说,它开始感到宗教,徒劳和错误的焦点.

迷你咆哮随之而来(随意忽略):

如果您不想继续阅读..我对上述主题的简短回答是:我不同意无逻辑模板.我认为它是一种极端主义的编程形式.:-) :-)

现在我的咆哮继续如火如荼:-)

我认为,当你把很多想法推向极致时,结果就变得荒谬了.有时(即本主题)问题是我们将"错误"的想法推向了极致.

从视图中删除所有逻辑是"ludicroous"和错误的想法.

退一步.

我们需要问自己的问题是为什么要删除逻辑？这个概念显然是关注点的分离.保持视图处理尽​​可能与业务逻辑分开.为什么这样？它允许我们交换视图(针对不同的平台:移动,浏览器,桌面等),它允许我们更容易地交换控制流,页面序列,验证更改,模型更改,安全访问等.当逻辑是从视图中删除(尤其是Web视图),它使视图更具可读性,因此更易于维护.我明白并同意这一点.

然而,最重要的焦点应该是分离关注点.不是100%逻辑少的视图.视图中的逻辑应该与如何呈现"模型"相关.就我而言,视图中的逻辑非常好.您可以拥有非业务逻辑的视图逻辑.

是的,早在我们编写JSP,PHP或ASP页面时,很少或根本没有代码逻辑和视图逻辑分离,这些Web应用程序的维护是一个绝对的噩梦.相信我,我知道,我创造并保持了一些这些怪物.正是在维护阶段,我真正理解(内心)我和同事的错误方式.:-) :-)

因此,来自高端(行业权威人士)的法令变成了,您必须使用前端控制器(派遣给处理程序或操作[选择您的Web框架])来构建您的Web应用程序,并且您的视图必须不包含任何代码.观点是变成愚蠢的模板.

所以我总体上同意上述观点,不是针对法令条款的具体细节,而是法令背后的动机 - 这是希望将观点和商业逻辑之间的关注分开.

在我参与的一个项目中,我们试图遵循无逻辑的观点理念到荒谬的极端.我们有一个自行开发的模板引擎,它允许我们在html中渲染模型对象.这是一个简单的基于令牌的系统.一个非常简单的原因是可怕的.有时在我们必须决定的视图中,我应该显示这个HTML的小片段..或者不是.决定通常基于模型中的某些值.当你在视图中完全没有逻辑时,你是如何做到的？嗯,你不能.我和我们的建筑师有一些关于此的主要论点.前端HTML写的人我们的观点是完全陷于瘫痪时,他们面临着这个并非常强调,因为他们不能达到他们本来简单的目标.所以我在模板引擎中引入了一个简单的IF语句的概念.我无法向你描述随之而来的安慰和平静.我们的模板中使用简单的IF-Statement概念解决了问题!突然间,我们的模板引擎变好了.

那么我们是如何陷入这种愚蠢的压力状况的呢？我们专注于错误的目标.我们遵循规则,您的观点中不得有任何逻辑.那是错的.我认为"经验法则"应该是,尽量减少视图中的逻辑量.因为如果你不这样做,你可能会无意中允许业务逻辑蔓延到视图中 - 这违反了关注点的分离.

我知道当你声明"你必须在视图中没有逻辑"时,很容易知道你什么时候成为一个"好"的程序员.(如果这是你善良的衡量标准).现在尝试使用上述规则实现中等复杂度的Web应用程序.它不是那么容易做到的.

对我来说,观点中的逻辑规则并不是那么明确,坦率地说,这就是我想要的地方.

当我在视图中看到很多逻辑时,我发现了代码嗅觉并尝试从视图中消除大部分逻辑 - 我试图确保业务逻辑生活在其他地方 - 我试图将问题分开.但是,当我开始与那些说我们必须从观点中删除所有逻辑的人聊天时,对我而言,正如我所知,你可能最终会遇到如上所述的情况.

我完成了我的咆哮.:-)

干杯,

大卫

8> eagspoo..：

---

我为无逻辑模板提出的最佳论点是,您可以在客户端和服务器上使用完全相同的模板.然而,你真的不需要逻辑,只有一个拥有它自己的"语言".我同意那些抱怨小胡子毫无意义地限制的人.谢谢,但我是一个大男孩,我可以在没有你帮助的情况下保持我的模板清洁.

另一个选择是找到一个模板语法,它使用客户端和服务器都支持的语言,即使用node.js在服务器上的javascript,或者你可以通过类似therubyracer的东西使用js解释器和json.

然后你就可以使用像haml.js这样的东西,它比目前提供的任何例子都要干净得多.