模板与编码的 HTML答案

【问题标题】：Templates vs. coded HTML模板与编码的 HTML
【发布时间】：2010-06-11 22:48:00
【问题描述】：

我有一个包含一些用于维护一些表的 html 表单的网络应用程序（SQlite，CherryPy 用于网络服务器的东西）。首先，我完全使用“Python 方式”，并通过生成 html 字符串。代码，具有共同的页眉、页脚等。在单独的模块中定义为函数。

我也喜欢模板的想法，所以我尝试了 Jinja2，我觉得它对开发人员非常友好。一开始我认为模板是要走的路，但那时页面很简单。一旦引入了 .css 和 .js 文件（不一定与 .html 文件在同一个文件夹中），并且引入了越来越多的 {{...}} 变量和 {%...%} 命令，事情在设计时开始变得混乱，即使它们在运行时看起来很棒。当我在 or 部分需要额外的 javascript 时，事情变得更加困难。

据我所知，使用模板的主要优点是：页面的非动态元素可以在设计期间在浏览器中轻松查看。除 {} 占位符外，html 与 python 代码分开。如果您的公司有网页设计师，他们仍然可以在不了解 Python 的情况下进行设计。

虽然有些缺点是： {{}} 分隔符在设计时在浏览器中查看时可见关联的 .css 和 .js 文件必须位于同一文件夹中，才能在设计时在浏览器中查看效果。数据、变量、列表等必须提前准备好，要么全局声明，要么作为参数传递给 render() 函数。

那么 - 什么时候使用“硬编码”HTML，什么时候使用模板？我不确定最好的方法，所以我很想听听其他开发人员的意见。

蒂亚，艾伦

【问题讨论】：

标签： python html templates

【解决方案1】：

虽然我不是 Python 开发人员，但我会在这里回答 - 我相信使用模板的想法在 PHP 和 Python 中很常见。

使用模板有很多优点，比如：

保持代码干净。将“逻辑”（控制器）代码与表示（视图）分开是非常重要的。处理混合了 HTML / CSS / JS / Python 的项目真的很难。
将 HTML 保存在单独的文件中不需要您修改代码本身。例如，在控制器代码（Python 代码）中放置可能需要您在每个 " 字符之前放置一个斜杠。
您可以要求您的网页设计师学习模板语法的基础知识，这样他就可以在不破坏您在控制器代码上的工作的情况下为您提供很多帮助（当没有给定语言经验的人修改某些东西时，这很常见）

其实还有很多优点，但这些对我来说是最重要的。

唯一的缺点是您必须将参数传递给渲染函数......这不需要太多工作。无论如何，这比维护任何将控制器代码与视图代码混合在一起的项目要容易得多。

一般来说，你应该看看 >MVC 的优缺点问题What is MVC and what are the advantages of it?

【讨论】：

在 Seaside 中保持代码整洁比在我见过的任何模板系统中都容易。
@Stephan Eggermont 我同意这对于开发人员来说可能是正确的，而对于设计师来说可能是不正确的。模板系统的重点是允许设计人员进行设计工作并让开发人员能够使用它，而不是采用设计并使用其他语法重写它来创建原始结果。
我们需要一种高效的合作方式。模板失败了。

【解决方案2】：

解决静态文件问题的最简单方法是在 html 中引用它们时使用相对路径。例如：<img src="static/image.jpg" />

如果您愿意多做一点工作，您可以通过编写一个迷你服务器来显示您的模板来解决您提到的所有设计时问题。

维护一个包含所有模板示例值的简单数据结构的文件。
使用像 Werkzeug 这样的微框架在本地计算机上提供 http。
编写一个根请求处理程序来扫描您的数据结构列表或模板目录，以生成一个包含所有模板链接的索引页面。
为非根请求编写辅助请求处理程序，该处理程序使用同名数据结构呈现请求的模板。

你可以在几个小时内编写这个工具，它使模板设计非常方便。 Werkzeug 的内置 wsgi 服务器的一个很好的特性是它可以在检测到文件已更改时自动重新加载。您可以在编辑模板和点击索引页面上的链接时让您的迷你服务器全天运行。

【讨论】：

好主意 Forest - 根据您的建议，我刚刚写了一个小程序。使用 CherryPy 显示模板，css 文件，测试数据和所有......好主意。有一个索引页面列出单个文件夹中的所有文件。问候。

【解决方案3】：

我强烈推荐使用模板。模板有助于为您的应用程序鼓励良好的 MVC 结构。发出 HTML 的 Python 代码，恕我直言，是错误的。我这么说的原因是因为 Python 代码应该负责执行逻辑，而不必担心表示。模板语法通常具有足够的限制性，以至于您实际上无法在模板中执行太多逻辑，但您可以执行您可能需要的任何特定于演示文稿的类型逻辑。

ymmv.

【讨论】：

是的，由于 Web 开发人员可以处理模板，因此您可以专注于编码。

【解决方案4】：

我认为模板仍然是将表示与业务逻辑分开的最佳方式。关键是一个好的模板引擎，特别是可以在模板本身中做出决定的引擎。对于 Python，我发现 Genshi 模板引擎非常好。 Trac Wiki/Issue 跟踪系统使用它，并且功能非常强大，同时仍然使模板易于使用。

对于其他任务，我倾向于使用BeautifulSoup 模块。我将创建一个简单的 HTML 页面，使用 BeautifulSoup 对其进行解析，使用生成的对象添加必要的数据，然后将输出写入其目标（对我来说通常是一个文件）。

【讨论】：

没有。您需要演示逻辑。这应该和你的业务逻辑一样强大，以便 DRY。面向对象，可调试，可测试。那不再像 html
@Stephan Eggermont - 与业务逻辑一样“强大”的“演示逻辑”的示例是什么？ “表示逻辑”实际上是将“事物”放在“位置”——业务逻辑正在执行计算、检查条件和派生值——你什么时候需要为数据表示做如此复杂的事情？
例如客户端验证，可以（部分）从业务规则派生
客户端验证很好用（它经常使应用程序更可用），但您仍然必须在业务层进行验证。太多的 Web 应用程序使用 JavaScript 来“强制”应用程序限制，结果却有人手动制作了一个忽略这些限制的 URL。如果您想根据您的应用程序规范生成验证代码，那很好，但您不应该仅仅因为您的公司更改了它的调色板，或者因为有人在 Internet Explorer 中发现了一个新漏洞，就必须修改您的应用程序代码。跨度>
您可以使用许多工具来实现该结果。很长一段时间以来，模板一直对我很有效，但我并不是要你使用它们。

【解决方案5】：

作为 Seaside 开发人员，如果您的设计师可以做 css，我认为模板没有用处。在实践中，我发现保持模板干燥是不可能的。查看this question，了解使用代码（DSL）生成页面的优势。当然，您可能会受到遗产的约束。

Web 应用程序中表示 (html) 和业务逻辑的分离不会导致良好的模块化，即低耦合和高内聚。这就是为什么单独的模板系统不能很好地工作的原因。

我刚刚阅读了 Jeff Atwoods 的“CSS 出了什么问题”。这又是一个在 smalltalk 世界中长期解决的问题，Phantasia DSL

【讨论】：

我同意 DSL 对于模板语言来说并不总是一个好主意……但是，Genshi、Jinja2 或 Django 的模板框架几乎只是带有一些特殊标签的纯 HTML。这些类型的模板解决了使用 DSL 可能出现的许多问题。
嗯？我声称没有模板的地方。 Seaside DSL 非常适合生成 HTML（和 javascript），并且是集成的。
模板系统的部分要点是表示层可能会有很大的不同。当所需的输出可能甚至不是 HTML，或者可能是生成器不支持的 HTML 版本时，我为什么要依赖自动生成的 HTML？我不确定您要解决什么问题，但这肯定不是我遇到过的问题。
对不起，我看错了你的帖子......所以你说使用 DSL 你可以编写一次代码，它会自动知道如何为用户交互呈现 UI，RSS/ATOM，和 XML 用于 Soap/REST 请求？如果是这种情况，并且单个 DSL 可以做到这一点……那真是太酷了！我在哪里注册？
我认为 Stephan 所做的比较是在一组相对未组合的模板（HTML 猴子易于使用，不是很干燥）与您从顶部使用可重用代码组件的系统之间进行比较一直到点点滴滴。但是，您也可以使用模板一直向下执行组件，尽管可能不那么优雅。不过，Stephan 作为纯 CSS 设计师的角色可能在其他商店中并不适用，尤其是在有大量静态内容的地方。