Я собираюсь написать CMS, но прямо сейчас я записываю все свои идеи и пытаюсь получить все свои концепции прямо перед тем, как начать. Одна из вещей, которые я разорвал, заключается в том, следует ли использовать язык шаблонов и анализировать страницы веб-сайта, а также заменять теги шаблонов на элементы контента или просто разрабатывать сайт с прямым PHP и создавать CMS-структуры, которые помогают. Например:
{navigation: products} против
foreach($cms_label['products'] as $product) { echo '<li class="product_nav">'. '<a href="products/{$product.id}">{$product.name}</a>'. "</li>\n"; }
Первый из них чище, но он предполагает изобретать язык, а также анализировать каждую страницу перед отображением. Последнее менее чистое, но я думаю, что он мог бы отлично работать, если бы CMS предоставила данные для всего кода. Но будет ли это считаться смешением логики с презентацией? Другая альтернатива, которую я рассмотрел, – это использование функций PHP, похожих на теги шаблонов:
<?php navigation('products'); ?>
Что ты думаешь?
Имейте в виду, что мне не нужно делать что-то более сложное, чем включение страницы в определенное место или запись неупорядоченного списка; остальные должны обрабатываться CSS.
Языки шаблонов для PHP являются примером анти-шаблона, называемого « Эффект внутренней платформы ». Smarty – пример шаблона для PHP, но даже Хасин Хайдер, автор книги по Smarty, говорит, что Smarty мертв, и больше не нужно его использовать.
Могут быть веские причины для разработки языка шаблонов, например, если у вас есть дизайнеры без кодировщика или редакторы контента, использующие вашу CMS, и вы не хотите перегружать их сложностью PHP (или разрешить им писать код, который мог бы сломайте свой сайт).
Но вы не описали это как цель, поэтому я бы предпочел использовать PHP, поскольку в этом случае лучше использовать язык шаблона страницы. Это будет меньше, потому что вам не нужно разрабатывать свой собственный новый язык, и это обеспечит большую гибкость для необычных случаев, когда вам нужен определенный тип динамического контента.
Не записывайте PHP-функции для инкапсуляции блоков вывода HTML. Вместо этого используйте include() чтобы извлечь фрагменты HTML. Этот метод иногда называют «частичным».
Вы также можете использовать инфраструктуру MVC, такую как Symfony, Kohana, Solar, CodeIgniter или Zend Framework, чтобы помочь вам сохранить дисциплину в отношении разделения кода шаблона PHP на остальной код вашего приложения.
Я был очень счастливым пользователем Smarty в течение долгого времени, я больше не верю в специализированные языки шаблонов.
Язык шаблонов не помешает вам ввести неправильную логику в код презентации, это просто заставит вас писать плохой код на языке шаблона.
Это довольно тривиально бросить вашу собственную небольшую систему шаблонов, которая использует php в шаблонах. Затем создайте разных помощников, чтобы ваш код шаблона был чистым (например, функция «navigation ()»).
Я думаю, что подход Zend_View довольно хорош. Материалы для представления на Symfony довольно аккуратны, но могут быть немного запугивающими. Вам не нужно использовать фреймворк, чтобы получить что-то от него. Просто посмотрите на некоторые из кода шаблона в примерах и посмотрите, что вас вдохновляет.
Итог: забыть о специальном языке для шаблонов – просто примените хороший смысл дизайна к вашему коду зрения, сложность факторинга из сценариев представления и в помощники многократного использования.
Переосмыслить колесо в большинстве случаев плохая идея.
PHP уже является языком шаблонов. Вам не нужно реализовывать свои собственные.
Что касается Smarty, это самая полная система шаблонов для php, и это все еще плохая идея.
Несколько статей по теме:
Когда-то был Smarty! Хасином Хайдером. Он на самом деле написал книгу о умении, и он не рекомендует ее.
Php и Templates от Harry Fuecks (автор 1-го издания антропологии php)
Если вы хотите посмотреть на шаблоны, лучше посмотреть на:
Конечная цель, конечно, состоит в том, чтобы упростить кодекс, поддерживая разделение бизнес-логики и презентации
Возможно, вы захотите изучить Smarty-http://smarty.php.net Smarty – очень мощный механизм шаблонов, который дает вам лучшее из обоих миров. Он имеет обширную поддержку настраиваемых модулей и плагинов.
Я создал пользовательскую CMS с Smarty и PHP и ничего не могу сказать о ней.
PHP-код для использования Smarty выглядит следующим образом:
<?php // my cms $smarty = new Smarty(); . . $smarty->display('home.tpl'); ?>
Код шаблона выглядит примерно так:
<h1>{$pagetitle}</h1> {insert tag="navigation"}
Интересно, почему никто не упомянул о том, что является одним из наиболее важных применений языка шаблонов: автоматическое выходное экранирование.
Легко забыть htmlspecialchars () здесь или там, поэтому язык шаблонов, который предоставляет директивы типа {$ name}, должен удостовериться, что $ name автоматически передается через htmlspecialchars, с соответствующей кодировкой и всем.
Конечно, это также означает, что вы можете указать другой «контекст» для вывода переменной, например, alert («Привет {$ name | context = singlequotes}!»); где интерпретатор шаблонов избежал содержимого $ name, так что невозможно вырваться из одинарных кавычек, вместо того, чтобы сбрасывать XML (что должно быть по умолчанию).
Такие контексты также могут включать в себя такие вещи, как int (для принудительного числа), а также могут быть расширены, чтобы принимать дополнительные параметры для форматирования вывода и т. Д.
Мои 2 цента. Не уверен, есть ли решение с открытым исходным кодом, которое позволяет это (было бы интересно услышать об этом!), Я закатил собственный интерпретатор для этого материала на работе. Поскольку полученный «промежуточный код» является чистым PHP, его также можно легко «кэшировать» (например, Smarty и другие системы tpl).
Мне очень нравится Smarty, и я также считаю, что контроллеры должны быть чисто написаны в XML и моделях в YAML. Это единственный способ обеспечить соблюдение MVC.
Если вопрос о производительности возникает только тогда, то компиляция на php может рассматриваться как возможность (пусть и удаленная) с условием sine qua non, что это делается запутанным образом, чтобы препятствовать нетерпеливым разработчикам прочесть его.