我认为大多数模板引擎很难用于设计师和前端开发人员，而程序员则需要维护它们。
在设计师更新html模型后经常更新模板是一场噩梦，因为你的模板不再与原来的htmls兼容。
I had this problem for very long time，最近我有一个idea，但我不知道我是不是要重新发明一些东西，或者是否存在更好的东西。
所以，我问你是否为这个问题找到了更好的解决方案，如果是的话？
答案 0 :(得分：2)
由于我已经切换到完全分离内容和演示文稿，我从未回头，这就是原因：
您的业务逻辑变得非常清晰。如果没有混合使用HTML标记和表示逻辑，代码占用的空间为1/2，维护时间不到1/2。维护代码和表示之间的链接的负担可以通过指定两者之间的正式接口来缓解，即使是作为文本文件或Wiki注释，列出了表示层所呈现/所需的所有变量和值。
经常从设计人员的更改中更新模板意味着您的表示层应该细分为各种“块”，例如菜单块，页面布局块和内容块。在大多数页面上，只有内容块不同。如果使用CSS和其他现代Web技术进行适当划分和实现，设计中的合理更改将对您的演示代码产生最小的影响。
CMSes甚至可以进一步自动化这一过程，现在甚至可以从一致性和易于支持的角度使用CMS和手工编码的HTML，从而使5-10页的网站受益。
代码安全 - Smarty不是PHP，因此您的设计师可以对网站拥有较低的信任度（他们不能过多地混淆基础，尽管他们可以将演示文稿的效果与DoS会有，所以不管怎么说都不要乱用它们;如果你不太关心安全性，PHPTal和其他人几乎以“原生”的速度运行。
至于我的工作解决方案，我有两条建议：
开发项目范围的文件夹结构和命名约定，并坚持下去。给定您的业务逻辑文件的名称，我应该能够告诉您演示文件是什么，反之亦然。
在业务逻辑和演示之间有一个明确的接口规范（同样，文本文件或Wiki条目是你真正需要的）。了解哪些变量可用，以及它们应该如何（程序员）/（设计者）格式化，这使得他们在一年后必须维护页面时非常高兴。
答案 1 :(得分：1)
是的，但前提是它们尽可能接近原生HTML。
Dreamweaver模板（忽略编辑器）基本上可以很好地实现这一点，因为它们基本上用一些HTML注释标记了一个普通的旧HTML（POH™）页面。
答案 2 :(得分：0)
我个人喜欢一些CMS解决方案如何让我将模板分解成非常小的部分。 SiteCore通过映射到用户控件的占位符和渲染来做到这一点。
我过去也大量使用UserControl来突破常用功能，如登录，菜单，页脚链接等，以便将来更容易修改或替换功能。 （ASP.NET）
您使用的是哪些模板引擎？像Smarty for PHP？