简体   繁体   English

模板与编码的 HTML

[英]Templates vs. coded HTML

I have a web-app consisting of some html forms for maintaining some tables (SQlite, with CherryPy for web-server stuff).我有一个由一些 html 表单组成的网络应用程序,用于维护一些表格(SQlite,使用 CherryPy 用于网络服务器的东西)。 First I did it entirely 'the Python way', and generated html strings via.首先,我完全按照“Python 方式”完成了它,并通过生成了 html 字符串。 code, with common headers, footers, etc. defined as functions in a separate module.代码,具有公共页眉、页脚等,定义为单独模块中的函数。

I also like the idea of templates, so I tried Jinja2, which I find quite developer-friendly.我也喜欢模板的想法,所以我尝试了 Jinja2,我发现它对开发人员非常友好。 In the beginning I thought templates were the way to go, but that was when pages were simple.一开始我认为模板是要走的路,但那时页面很简单。 Once .css and .js files were introduced (not necessarily in the same folder as the .html files), and an ever-increasing number of {{...}} variables and {%...%} commands were introduced, things started getting messy at design-time, even though they looked great at run-time.一旦引入了 .css 和 .js 文件(不一定与 .html 文件在同一个文件夹中),并且引入了越来越多的 {{...}} 变量和 {%...%} 命令,事情在设计时开始变得混乱,即使它们在运行时看起来很棒。 Things got even more difficult when I needed additional javascript in the or sections.当我在 或 部分需要额外的 javascript 时,事情变得更加困难。

As far as I can see, the main advantages of using templates are: Non-dynamic elements of page can easily be viewed in browser during design.据我所知,使用模板的主要优点是: 页面的非动态元素在设计时可以很容易地在浏览器中查看。 Except for {} placeholders, html is kept separate from python code.除了 {} 占位符,html 与 python 代码分开。 If your company has a web-page designer, they can still design without knowing Python.如果您的公司有网页设计师,他们仍然可以在不了解 Python 的情况下进行设计。

while some disadvantages are: {{}} delimiters visible when viewed at design-time in browser Associated .css and .js files have to be in same folder to see effects in browser at design-time.而一些缺点是: {{}} 定界符在设计时在浏览器中查看时可见 关联的 .css 和 .js 文件必须在同一文件夹中才能在设计时在浏览器中查看效果。 Data, variables, lists, etc., must be prepared in advanced and either declared globally or passed as parameters to render() function.数据、变量、列表等必须提前准备好,并且要么全局声明,要么作为参数传递给 render() 函数。

So - when to use 'hard-coded' HTML, and when to use templates?那么 - 何时使用“硬编码”HTML,何时使用模板? I am not sure of the best way to go, so I would be interested to hear other developers' views.我不确定最好的方法,所以我很想听听其他开发人员的意见。

TIA, Alan TIA,艾伦

Although I'm not a Python developer, I'll answer here - I believe the idea of using templates is common for PHP and Python.虽然我不是 Python 开发人员,但我会在这里回答——我相信使用模板的想法对于 PHP 和 Python 来说很常见。

Using templates has many advantages, like:使用模板有很多优点,例如:

  • keeping the code clean.保持代码干净。 Separating the "logic" (controller) code from the presentation (view) is very important.将“逻辑”(控制器)代码与表示(视图)分开非常重要。 Working on projects that mix HTML / CSS / JS / Python is really hard.处理混合 HTML / CSS / JS / Python 的项目真的很难。
  • keeping HTML in separate files doesn't require you to modify the code itself.将 HTML 保存在单独的文件中不需要您修改代码本身。 For example, placing in the controller code (Python code) might require you to put a slash before each " character.例如,在控制器代码(Python 代码)中放置可能需要您在每个 " 字符之前放置一个斜杠。
  • you can ask your web designer to learn the basics of templates syntax so he's able to help you much without destroying your work on the controller code (which is quite common when a person with no experience in a given language modifies something)你可以让你的网页设计师学习模板语法的基础知识,这样他就能在不破坏你对控制器代码的工作的情况下为你提供很多帮助(当一个没有给定语言经验的人修改某些东西时,这很常见)

in fact, there are many more advantages, but those are most important for me.事实上,还有很多优点,但这些对我来说是最重要的。

The only disadvantage is that you have to pass parameters to the rendering function ... which doesn't require much of work.唯一的缺点是您必须将参数传递给渲染函数......这不需要太多工作。 Anyway it's much easier than maintaining any project that mixes controller code with view code.无论如何,这比维护任何将控制器代码与视图代码混合在一起的项目要容易得多。

Generally, you should have a look at >MVC pros and cons question< : What is MVC and what are the advantages of it?一般来说,你应该看看>MVC pros and cons question<: 什么是MVC,它有什么优点?

The simplest way to solve your static file problem is to use relative paths when referring to them in your html.解决静态文件问题的最简单方法是在 html 中引用它们时使用相对路径。 For example: <img src="static/image.jpg" />例如: <img src="static/image.jpg" />

If you're willing to put in a little more work, you can solve all the design-time problems you mentioned by writing a mini-server to display your templates.如果你把愿意在一点点更多的工作,就可以解决所有你所提到的通过编写一个小型服务器,以显示你的模板设计时的问题。

  1. Maintain a file full of simple data structures containing example values for all your templates.维护一个充满简单数据结构的文件,其中包含所有模板的示例值。
  2. Use a microframework like Werkzeug to serve http on your local machine.使用像Werkzeug这样的微框架在本地机器上提供 http 服务。
  3. Write a root request handler that scans your data structure list or templates directory to produce an index page with links to all your templates.编写一个根请求处理程序来扫描您的数据结构列表或模板目录,以生成一个包含所有模板链接的索引页面。
  4. Write a secondary request handler for non-root requests, which renders the requested template with the data structure of the same name.为非 root 请求编写一个辅助请求处理程序,它使用同名的数据结构呈现请求的模板。

You can write this tool in a few hours, and it makes template design very convenient.您可以在几个小时内编写此工具,它使模板设计非常方便。 One nice feature of Werkzeug's built-in wsgi server is that it can automatically reload itself when it detects that a file has changed. Werkzeug 的内置 wsgi 服务器的一个很好的功能是,它可以在检测到文件已更改时自动重新加载自身。 You can leave your mini-server running while you edit templates and click links on your index page all day.您可以在编辑模板和单击索引页面上的链接一整天时让迷你服务器保持运行状态。

I would highly recommend using templates.我强烈建议使用模板。 Templates help to encourage a good MVC structure to your application.模板有助于为您的应用程序提供良好的 MVC 结构。 Python code that emits HTML, IMHO, is wrong.恕我直言,发出 HTML 的 Python 代码是错误的。 The reason I say that is because Python code should be responsible for doing logic and not have to worry about presentation.我之所以这么说,是因为 Python 代码应该负责做逻辑,而不必担心表现。 Template syntax is usually restrictive enough that you can't really do much logic within the template, but you can do any presentation specific type logic that you may need.模板语法通常具有足够的限制性,以至于您无法在模板中真正执行太多逻辑,但是您可以执行您可能需要的任何表示特定类型的逻辑。

ymmv.嗯。

I think that templates are still the best way to separate presentation from business logic.我认为模板仍然是将表示与业务逻辑分开的最佳方式。 The key is a good templating engine, in particular, one that can make decisions in the template itself.关键是一个好的模板引擎,特别是一个可以在模板本身中做出决定的引擎。 For Python, I've found the Genshi templating engine to be quite good.对于 Python,我发现Genshi模板引擎非常好。 It's used by the Trac Wiki/Issue tracking system and is quite powerful, while still leaving the templates easy to work with.它被 Trac Wiki/Issue 跟踪系统使用并且非常强大,同时仍然使模板易于使用。

For other tasks, I tend to use the BeautifulSoup module.对于其他任务,我倾向于使用BeautifulSoup模块。 I'll create a simple HTML page, parse it with BeautifulSoup, use the resulting object to add the necessary data, and then write the output to its destination (typically a file for me).我将创建一个简单的 HTML 页面,使用 BeautifulSoup 对其进行解析,使用结果对象添加必要的数据,然后将输出写入其目的地(通常是我的文件)。

As a Seaside developer, I see no use for templates, if your designer can do css.作为 Seaside 开发人员,我认为模板没有用,如果您的设计师会做 css。 In practice, I find it impossible to keep templates DRY.在实践中,我发现保持模板干燥是不可能的。 Take a look at this question to see the advantages of using code (a DSL) to generate your page.查看此问题以了解使用代码(DSL)生成页面的优势。 You might be bound by legacy, of course.当然,您可能会受到遗产的约束。

Separation of presentation (html) and business logic in web apps does not lead to good modularisation, ie low coupling and high cohesion. Web 应用程序中表示 (html) 和业务逻辑的分离不会导致良好的模块化,即低耦合和高内聚。 That is why separate template systems don't work well.这就是为什么单独的模板系统不能很好地工作。

I just read Jeff Atwoods "What's Wrong With CSS".我刚读了 Jeff Atwoods “CSS 有什么问题”。 This again is a problem long solved in the smalltalk world with the Phantasia DSL这又是一个长期以来在使用Phantasia DSL的 smalltalk 世界中解决的问题

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM