StringTemplate模板技术.docxVIP

在模板引擎中强制模型-视图严格分离被推荐为最佳论文Terence Parr旧金山大学译注：部分翻译对照以及说明，参考文章最后的描述Translated by: Richie摘要：每一位富有经验的 web 应用开发者都主张：应当将业务逻辑和显示分离。然而几乎所有的模板引擎都允许违背这一分离原则，这极大的推动了 HTML 模板引擎的发展。这种情况主要是由于对分离缺乏形式的定义，以及担心强制分离将消弱模板的生成能力（generational power）。我将阐述严格的分离是非常有用的设计原则，通过提供有效的模板引擎能够强制分离。我使用 StringTemplate 引擎作为示例，用来建立 jG 和其它的商业网站，并解决一些重要的生成问题。我的目的是使对模板引擎的研究形式化，因此提供一个通用的术语，这个术语是一种对模板生成能力分类的方法，是对形式语言理论（formal language theory）感兴趣的补充。类似 Chomsky 的 1..3 型语法分类， 我把限制性模板（restricted template）分成三种类型，并且形式的定义分离，包括实现分离的规则。因为这篇论文提供了一个清晰的模型-视图分离定义，模板引擎设计者也许不再盲目的主张强制分离概 念。此外，给出理论论点和经验证明，程序员不再有借口混杂（entangle）模型和视图。分类和主题描述：D.3.4 [程序语言]：处理机-代码生成；D2.11 [软件工程]：软件架构-面向领域的架构，模式，语言；D1.1 [编 程技术]：应用（功能）编程常规项： 语言关键词：模板引擎，Web应用，模型-视图-控制器1. 简介 对动态生成web页面的需求，例如A上的图书显示页面，导致众多模板引擎的开发趋向于使web应用开发简单化，提高扩展性，降低维护成本，允许编码和HTML的开发并行。这种诱人的好处促进了模板 引擎的发展，这完全来自一个原则：将页面的业务逻辑声明（specification）和数据处理声明，与页面怎样显 示这些信息的声明分离。通过隔离封装的声明，模板引擎促进了组件复用，可插拔的站点外观，通用组件的单点变化（single-points-of-change），良好的系统清晰度。 我曾经跟很多经验丰富的程序员讨论过分离原则，调查过很多通用的模板引擎，这些模板引擎使用各种语言开发，包括Java、C和Perl。毫不意外，程序员赞成逻辑与显示分离是一种理想的原则。然而实际上，程序员和引擎开发者不太原意强制分离，他们担心满足这个原则会损失生成能力，导致某个关键页面无法生成。 相反，他们鼓励而不是强制要求这一原则，给自己留一个退路，避免不完善的页面生成能力。很不幸，在最终期限的压力下，只要可能，程序员会经常使用这个退路作为权宜之计，导致逻辑和显示 混杂。一个负责公司服务器数据模型的程序员告诉我，离最终期限他只有3天多时间，但如果强制他们的程序员采用分离原则，修改那些受影响的多语言页面显示需要10天。为将来的维护考虑做正确的事情，他可能面 临被解雇的风险，或者他可以通过数据模型将新的HTML输出到页面，从而保住他的工作，将这种混乱留给 以后或者其它程序员。另一种更普遍的情形是作为一个捷径，程序员将业务逻辑嵌入他们的模板中，避免更新数据模型。提供 完全图灵机式（Turing-Complete）的模板编程语言，程序员就趋向于直接在模板中需要的地方添加业务逻辑， 而不是在数据模型中完成，从模型中解耦视图。例如几乎每个模板引擎的文档都有描述，如何根据用户权限 改变显示，不是简单的向模型询问用户是否特殊，而是在模板中编码逻辑来确定用户是否特殊。如果这个特殊的定义改变了，可能系统中的每个模板都不得不修改，或者程序员可能忘了某个模板，给系统引入一个将 来随时可能出现的缺陷。通常这种捷径很快导致完全混杂的声明（entangled specification）。理想是否可能？就是说我们是否可以强制分离却又不消弱模板引擎的生成能力？限制性引擎导致一些版权归原作者所有WWW2004, May 17–20, 2004, New York, New York, USA. ACM 158113844X/04/0005.页面无法处理？通常理论跟实践是不一致的。理论表明一个完全图灵机式的模板引擎能够生成任何页面，并 且比限制性模板引擎更强大。实际中我建立web服务器的经验，例如jG（11万行），提供了有力的证 据，表明程序员实际上在这两个方面可以获得最好的效果：分离和足够的生成能力。过去五年我在构建站点 和打造我的StringTemplate模板引擎过程中，实际上是进行了一项软件设计的试验，在我的模板中严格的避免 逻辑和运算（译注：对上面例子的解释，完全图灵机式的模板引擎=自由模板引擎，例如JSP、ASP；自由