无逻辑模板与模板语言中的更多功能的编程原理是什么？

Question

无逻辑模板的编程原理是什么（如胡子/把手）？为什么有意限制模板语言的功能被这些无逻辑模板库的制造者和用户认为是一个好的和理想的设计模式？

我最近在一个小项目中使用node.js和把手，我发现我经常因车把模板中缺少简单的逻辑而受阻。

在我放弃把手模板引擎以寻找具有更强逻辑功能的引擎之前，我想了解使用无逻辑模板语言背后的编程原理。

我应该澄清一点，我并不是在询问人们对哪种模板语言更好的看法。我问的是人们设计，构建和使用无逻辑模板的客观原因是什么。

---

这里有一个相当简单的例子，说明我希望模板能够自行处理，但我不知道如何在把手中这​​样做，所以我不明白它为什么会这样做。 s被认为是一种理想的特性，即“无逻辑”和“＃34;模板本身无法处理这种简单的UI表示。由于有许多无逻辑模板选择，我假设我有理由了解它。

我有两个来自may app状态的变量传递给模板：

fanOn       // boolean: true or false
fanControl  // three states: "on", "off", "auto"

fanOn代表我控制的一些粉丝的当前状态 fanControl描述了粉丝所处的控制模式。＆＃34; on＆＃34;意味着它们会被手动打开并保持这种状态直至另行通知。 ＆＃34;关闭＆＃34;意味着它们会被手动关闭并保持这种状态直至另行通知。 ＆＃34;自动＆＃34;意味着它们处于自动恒温/软件控制之下。

如果风扇打开，我想显示一个按钮，手动关闭它们。

如果风扇关闭，我想显示一个按钮，手动打开它们。

如果打开或关闭fanControl设置，我想显示一个按钮，将其设置为自动。

所以，总有一个＆＃34;开启＆＃34;或＆＃34;关闭＆＃34;按钮，如果它不在＆＃34; auto＆＃34;模式，有＆＃34;设置回自动＆＃34;按钮。

这里没有业务逻辑，只需根据当前状态构建正确的演示文稿。

以下是我在该主题上发现的各种参考资料（其中包含意见和事实的组合 - 读者必须理清哪个是哪个）：

• Enforcing Strict Model-View Separation in Template Engines
• What are the benefits of logic-less templates like {{Mustache}}?
• The Case Against Logic-Less Templates
• Cult of Logic-less Templates
• Logic-less Template Redux
• Your templating engine sucks and everything you have ever written is spaghetti code (yes, you)
• Simple is better - Template Engines
• Mustache is logic-less but the logic has to go somewhere
• 3 Reasons to choose Logic Less templates like Mustache
• Dust is eloquent – the logic wars - Paypal Engineering Blog

Answer 1

有一种趋势，特别是对于没有经验的程序员，人们将业务逻辑包含在模板中。这通常被认为是不良做法和反模式。业务逻辑属于模型层，不应与表示/视图层有任何关系。

极端情况下，您最终会使用PHP - 其中100％的代码，业务逻辑，控制器粘合和视图都嵌入在HTML中。

为了阻止这种情况，开发了无逻辑模板，以便初级开发人员不会轻易地在视图层中包含业务逻辑。

对于真正良好的关注点分离（单一责任），检查值以决定在屏幕上打印的内容不是视图层的责任。它应该在控制器中完成。但是，有时它实际上不应该是控制器的工作（例如，当使用由原始元素组成的复合UI元素时，检查可能是实现细节的一部分）。对于这些用例，模板库通常可用于提供诸如辅助方法之类的解决方法。但是这种用例应该很少见。

如果你不得不编写辅助方法，那么你可能只是不习惯将控制器逻辑与表示逻辑分开。因此，一些更极端的无逻辑模板语言（如Google的ctemplate）甚至不提供这样的解决方法（请注意，ctemplate早于许多较新的无逻辑模板语言）。

无逻辑语言的新发展甚至更加极端 - 无模板语言。如果模板语言根本没有语言，你只需传递正确的JSON数据（或其他结构化数据），模板引擎就会找到具有正确id或类名的匹配HTML元素，以便将值注入。

Answer 2

在研究了一堆其他模板语言之后，似乎基本上有三种思想流派，你真的必须根据你的发展理念，团队情况和项目需求来决定哪一种最好。

选项＃1：模板中包含完整的编程语言（例如PHP）。

选项＃2：模板无逻辑（例如Mustache / Handlebars）。

选项＃3：模板具有一些能够做出以演示为中心的逻辑决策（例如Dust）的能力。

PHP模型存在并且有效。如果没有适当的纪律，演示文稿和业务逻辑就会变得非常交织，造成无法解决的混乱局面。这并不意味着良好的纪律和适当的技术不会导致干净的实施，但是通过不正当的做法也很容易在脚下射击自己。

也许作为对这种以及随后的一些辩论引起的混乱的反应，无逻辑模板的概念到了。零业务逻辑可以放入无逻辑模板中。但是，由于模板中没有逻辑，因此必须在某处创建另一层代码，以便对表示逻辑进行决策，并对发送到模板的数据进行预处理，以使其与所选的UI设计完美对齐。这需要一个单独的位置用于表示逻辑代码。如果没有适当的规则或理解，此代码会与业务逻辑混合在一起，并且通常必须修改此代码以对模板中的UI设计进行相当简单的更改。没有纪律的案例可能不像选项＃1那样凌乱，但仍然有些人认为这也不理想 - 其他人似乎也喜欢它。

第三个选项是试图根据屏幕大小，基于数据状态，要选择的单选按钮，要显示的按钮等等，根据屏幕大小显示足够的逻辑以进行基于演示的决策的模板...但仍保留与主应用程序中的任何业务逻辑分开。另外，这可以允许具有不同技能的人（例如UI设计者）更完全地控制演示，而不需要来自主服务器端应用程序的javascript程序员。

与许多工具一样，人们可以争论每种方法的优点和缺点，而且从来没有绝对正确或错误的答案。

在搜索更符合选项＃3的模板时，我遇到Dust（由LinkedIn使用）和Walrus以及Nunjucks在他们的文档中找到了这些模糊信息描述他们与选项＃3相关的目标：

来自Walrus：

查看逻辑与业务逻辑不同（这没关系！）。在现代网络应用程序中，通常涉及大量的表示逻辑。此逻辑不属于您的应用程序代码，主干模型或除表示层之外的任何其他位置。模板语言是放置它的好地方。

而且，来自Dust：

模板中的逻辑

具有逻辑与＃34;逻辑无关的模板＆＃34;模板是模板语言设计者和用户之间备受争议的焦点。通过采用更少的逻辑＆＃34;而尘埃跨越了鸿沟。姿态。我们都知道真正的业务逻辑不属于表示层，但是简单的面向表示的东西呢，比如在表中着色替换行或在下拉列表中标记选定的选项？要求控制器/业务逻辑代码将这些计算到简单的布尔值以减少表示模板中的逻辑似乎同样错误。这条路线只会导致使用面向表示的逻辑污染业务层代码。 Dust提供了一些简单的逻辑机制，并相信您在最小化模板中的逻辑时只需处理面向表示的决策。也就是说，让我们来看看Dust让你有逻辑的方式。