Шаблонный движок на основе XML против лексера Smarty - PullRequest
2 голосов
/ 03 февраля 2011

Было много волнений по поводу Smarty 3 и его нового лексера, и того, как много энергии он даст вам как дизайнеру шаблонов, но когда он на самом деле попал на полки, это было настоящим разочарованием, насколько медленно,Компиляция шаблона с нуля заняла более секунды в Smarty 3, тогда как тот же шаблон в Smarty 2 занял бы около половины секунды.Нехорошо.

Но это заставило меня задуматься, зачем вам реализовывать полноценный синтаксический анализатор языка в PHP, когда в нем уже есть такие модули, как DOMDocument, SimpleXML и тому подобное?

Существуют ли какие-либо механизмы шаблонов для PHP, основанные на расширениях XML и / или DOMDocument?Если да, то на что похожа производительность?Если нет, то кто-нибудь пытался написать один?

Один недостаток, который я могу заметить, заключается в том, что он действительно будет полезен только для форматов на основе XML, таких как XHTML и RSS.Для генерации других выходных данных (не-XML HTML, простой текст, CSS и т. Д.) Это может быть довольно проблематичным, хотя я уверен, что вы можете обойти его с помощью блоков CDATA.Есть ли какие-либо другие последствия использования XML / DOM для анализа шаблонов, которые я не рассматривал?

Ответы [ 2 ]

3 голосов
/ 03 февраля 2011

На ваш пункт о Smarty, IIRC Smarty использует «скомпилированные шаблоны», так что если проблема производительности вы упоминаете только в «фазе компиляции» это становится спорным - каждый шаблон только компилируется один раз, после чего содержимое шаблона выводитсяиз (гораздо более быстрого) кэша.

Проблема с использованием синтаксического анализатора XML состоит в том, что HTML не всегда правильно сформирован XML.Даже если вы используете действительный XHTML, вы можете в конечном итоге перепрыгнуть через обручи для поддержки HTML-сущностей, а затем вы найдете угловые случаи, такие как встроенный Javascript и т. Д.все это старое дерьмо SGML и настаивают на использовании правильно сформированного XML. Если бы комитет по HTML сделал это, будущие механизмы шаблонов было бы намного проще писать с использованием стандартных API XML.) Я написал механизм шаблонов на основе XML Некоторое время назад для этого использовался API-интерфейс XMLReader, но чтобы он работал с HTML, необходимо добавить записи в системный каталог Libxml.Это работает достаточно хорошо, но это боль, большинство людей просто сдаются и используют что-то попроще.

1 голос
/ 11 сентября 2011

Вот некоторые из шаблонизаторов на основе XML, о которых я знаю:

http://phptal.org/

http://code.google.com/p/querytemplates/

http://www.hyperkit - программное обеспечение.com / projects / phptemplates / index.html

С точки зрения производительности, я не думаю, что большинство шаблонизаторов на основе XML значительно быстрее на этапе компиляции - большинство современных шаблонизаторов для PHP используют компиляциюТаким образом, производительность компилятора, как правило, жертвуется в пользу более расширяемой и поддерживаемой кодовой базы движка, а также для создания более оптимизированных скомпилированных шаблонов.Как отметил Робин, поскольку шаблоны компилируются, на самом деле никого не волнует, насколько быстрой или медленной может быть фаза компиляции.

Однако существуют и другие аргументы для механизмов шаблонов на основе XML.Лично мне не нравится идея смешивать два разных синтаксиса тегов, один из которых (Smarty) не может быть проанализирован, обработан или проверен с использованием обычных XML-инструментов.Чтобы уточнить, да, вы можете анализировать XML-часть шаблона Smarty, но вы не можете анализировать или изменять теги Smarty, которые выглядят как текст для инструмента XML.

Еще один распространенный аргумент против пользовательского синтаксиса (например,как используется в Smarty и большинстве других шаблонизаторов), PHP уже имеет синтаксис для всего, что предоставляют эти шаблонизаторы - например, <?=ucfirst($person->name)?> аналогичен {$person.name|ucfirst} в простом шаблоне PHP.Он использует синтаксис, который уже известен PHP-разработчикам, что означает, что нет кривой обучения, нет этапа компиляции, нет движка, который нужно развернуть, нет времени выполнения для визуализации шаблона и т. Д.

...