Шаблоны против кодированного HTML

Question

У меня есть веб-приложение, состоящее из некоторых html-форм для поддержки некоторых таблиц (SQlite, с CherryPy для веб-сервера). Сначала я сделал это полностью «Путь Python» и сгенерировал html-строки через. код с общими заголовками, нижними колонтитулами и т. д., определенные как функции в отдельном модуле.

Мне также нравится идея шаблонов, поэтому я попробовал Jinja2, который я считаю вполне подходящим для разработчиков. В начале я думал, что шаблоны - это путь, но это было, когда страницы были простыми. После того, как были введены файлы .css и .js (не обязательно в той же папке, что и файлы .html), и все большее число {{...}} переменных и {% ...%} команд было введено, вещи начали запутываться во время разработки, хотя они отлично смотрелись во время выполнения. Все стало еще сложнее, когда мне понадобился дополнительный javascript в разделе или разделе.

Насколько я могу судить, основными преимуществами использования шаблонов являются: Нединамичные элементы страницы могут быть легко просмотрены в браузере во время проектирования. За исключением {} placeholders, html хранится отдельно от кода python. Если у вашей компании есть дизайнер веб-страниц, они все равно могут разрабатывать, не зная Python.

в то время как некоторые недостатки: {{}} разделители видны при просмотре в режиме разработки в браузере Associated .css и .js файлы должны находиться в той же папке, чтобы увидеть эффект в браузере во время разработки. Данные, переменные, списки и т. Д. Должны быть подготовлены в расширенном и объявленном глобально или переданы как параметры функции render().

Итак - когда использовать «жестко закодированный» HTML и когда использовать шаблоны? Я не уверен в лучшем пути, поэтому мне было бы интересно услышать мнения других разработчиков.

TIA, Alan

Answer 1

Самый простой способ решить вашу проблему с статическими файлами - использовать относительные пути при обращении к ним в вашем html. Например: <img src="static/image.jpg" />

Если вы готовы поставить в более немного работе, вы можете решить все проблемы времени разработки вы упомянули, написав мини-сервер для отображения шаблонов.

1. Поддержание файла, полного простых структур данных, содержащих значения примеров для всех ваших шаблонов.
2. Используйте микрофотограмму, такую ​​как Werkzeug, чтобы служить http на вашей локальной машине.
3. Напишите обработчик запроса root, который сканирует ваш список структур данных или каталог шаблонов, чтобы создать страницу индекса со ссылками на все ваши шаблоны.
4. Напишите вторичный обработчик запросов для запросов без полномочий root, который отображает запрошенный шаблон с структурой данных с тем же именем.

Вы можете написать этот инструмент за несколько часов, и это делает дизайн шаблона очень удобным. Одной из приятных особенностей встроенного wsgi-сервера Werkzeug является то, что он может автоматически перезагружать себя, когда обнаруживает, что файл был изменен. Вы можете оставить свой мини-сервер запущенным, пока вы редактируете шаблоны и нажимаете ссылки на своей индексной странице в течение всего дня.

Answer 2

Я настоятельно рекомендую использовать шаблоны. Шаблоны помогают поощрять хорошую структуру MVC для вашего приложения. Код Python, который испускает HTML, IMHO, ошибочен. Причина, по которой я говорю, заключается в том, что код Python должен отвечать за выполнение логики и не беспокоиться о презентации. Синтаксис шаблона обычно достаточно ограничительный, что вы не можете делать много логики в шаблоне, но вы можете использовать любую конкретную логику типа представления, которая вам может понадобиться.

ymmv.

Answer 3

Я думаю, что шаблоны по-прежнему являются лучшим способом отделить презентацию от бизнес-логики. Ключ - хороший шаблонный движок, в частности тот, который может принимать решения в самом шаблоне. Для Python я нашел неплохой шаблон для шаблонов Genshi. Он используется системой отслеживания Trac Wiki/Issue и достаточно силен, но при этом остается легко работать с шаблонами.

Для других задач я стараюсь использовать модуль BeautifulSoup. Я создам простую HTML-страницу, проанализирую ее с помощью BeautifulSoup, используя результирующий объект, чтобы добавить необходимые данные, а затем напишуте вывод в пункт назначения (как правило, файл для меня).

Answer 4

Хотя я не разработчик python, я отвечу здесь - я считаю, что идея использования шаблонов распространена для PHP и Python.

Использование шаблонов имеет много много много adventages, как

• сохраняя код в чистоте. Разделение «логического» (контрольного) кода с «представления» очень важно, поверьте мне, что работа над проектами, которые смешивают выход HTML/CSS/JS, очень тяжелая.
• Сохранение HTML в отдельных файлах не требует изменения самого кода. Например, размещение в коде контроллера (код python) может потребовать, чтобы вы поместили косую черту перед каждым символом.
• вы можете попросить своего веб-дизайнера изучить основы синтаксиса шаблонов, таким образом, он может вам помочь, не разрушая вашу работу логики (что довольно часто, когда человек, не имеющий опыта в данном языке, изменяет что-то)

на самом деле есть еще много adventages, но те, которые наиболее важны для меня.

только disadventage является что вам нужно передать параметры функции рендеринга ... которые не требуют большой работы, поверьте мне :) A nyway намного проще, чем поддерживать любой проект, который смешивает логику с представлением.

Как правило, вы должны взглянуть на> MVC плюсы и минусы вопрос <: What is MVC and what are the advantages of it?

Answer 5

Как разработчик Seaside, я не вижу никакой пользы для шаблонов, если ваш дизайнер может сделать CSS. На практике я считаю невозможным сохранение шаблонов DRY. Взгляните на this question, чтобы увидеть преимущества использования кода (DSL) для создания вашей страницы. Конечно, вы можете быть связаны наследием.

Разделение презентации (html) и бизнес-логики в веб-приложениях не приводит к хорошей модуляции, т. Е. К низкой связи и высокой когезии. Вот почему отдельные системы шаблонов работают неправильно.

Я только что прочитал Джеффа Атвуда «Что не так с CSS». Это опять-таки проблема, которая долго решается в мире мелких пользователей с помощью Phantasia DSL