3

我认为大多数模板引擎对于设计师和前端开发人员来说很难使用，而让程序员承担维护它们的负担。

在设计师更新 html 模型后频繁更新模板是一场噩梦，因为您的模板不再与原始 html 兼容。

我有这个问题很长时间了，最​​近我有了一个想法，但我不知道我是不是在重新发明一些东西，或者是否存在更好的东西。

所以，我问你是否找到了解决这个问题的更好的解决方案，如果有，是哪一个？

4

3 回答 3

2

自从我切换到内容与演示完全分离以来，我从未回头，原因如下：

  • 你的业务逻辑变得非常清晰。如果没有混入 HTML 标记和表示逻辑，代码需要 ½ 的空​​间和不到 ½ 的时间来维护。维护代码和表示之间的链接的负担可以通过指定两者之间的正式接口来减轻，即使是作为文本文件或 Wiki 注释，列出表示层呈现/需要的所有变量和值。

  • 频繁地根据设计人员的更改更新模板意味着您的表示层应该细分为各种“块”，例如菜单块、页面布局块和内容块。在大多数页面上，只有内容块不同。当使用 CSS 和其他现代 Web 技术正确划分和实现时，设计中的合理更改将对您的演示代码产生最小的影响。

  • CMS 进一步自动化了这个过程，现在从一致性和易于支持的角度来看，即使是 5-10 个页面的网站也可以从使用 CMS 与手动编码的 HTML 中受益。

  • 代码安全 - Smarty 不是 PHP，因此您的设计人员对网站的信任度可能较低（他们不能过多地混淆基础，尽管他们可以将演示文稿破坏为与 DoS 相同的效果，所以无论如何不要惹他们）；如果您不太关心安全性，PHPTal 和其他人几乎以“本机”速度运行。

至于我的工作解决方案，我有两个建议：

  • 制定项目范围的文件夹结构和命名约定，并坚持下去。给定您的业务逻辑文件的名称，我应该能够告诉您演示文件是什么，反之亦然。

  • 在业务逻辑和表示之间有一个明确的接口规范（同样，一个文本文件或一个 Wiki 条目就是你真正需要的）。知道哪些变量可用，以及它们应该如何（程序员）/（设计师）格式化，让他们在一年后必须维护页面时都非常高兴。

于 2009-01-11T19:31:41.487 回答
1

是的，但前提是它们尽可能接近原生 HTML。

Dreamweaver 模板（忽略编辑器）基本上很好地完成了这一点，因为它们基本上用一些 HTML 注释标记了一个普通的旧 HTML (POH™) 页面。

于 2009-01-12T03:46:38.677 回答
0

我个人喜欢一些 CMS 解决方案如何使我能够将我的模板分成非常小的部分。SiteCore 通过映射到用户控件的占位符和渲染很好地做到了这一点。

过去我也大量使用 UserControls 来分解常见的功能，如登录、菜单、页脚链接等，以便将来更容易修改或替换功能。(ASP.NET)

你使用什么模板引擎？PHP 的 Smarty 之类的东西？

于 2009-01-11T19:08:03.607 回答