Akyn: синтаксис (переменные)
Как я уже писал, несколько дней назад я заменил шаблонизатор на своём сайте на новый. Вы просили, чтобы я рассказал как он устроен, я постараюсь. Сразу, едином наскоком у меня это сделать не получилось, поэтому я решил попробовать сделать это по частям. Начну с синтаксиса. Сразу скажу, что в будущем мне хотелось бы
Идея, которую я считаю хорошей несколько последних лет — шаблон должен содержать минимум логики и весь HTML должен содержаться в шаблонах. Тут она одна из центральных.
Шаблонизатор работает с файлами (у меня на сайте всё работает на файлах), в простейшем случае файл содержит одни шаблон, в более сложном — несколько секций шаблона. Секции записываются между двумя тегами комментария с именем секции внутри (обратите внимание на закрывающий тег):
<!--имя секции-->
HTML-код секции
<!--/имя секции-->Самое простое, что есть в шаблоне — переменные. Они записываются как {$name}. Переменная уникальна в своей секции или шаблоне (если шаблон без секций). Установить переменную можно присвоив шаблону свойство с её именем. У меня открытие шаблона сделано в глобальном toolkit и всё описанное выглядит вот так:
$t = rt::t('menu', 'меню сверху');
$t->link = '/';
echo $t;В данном примере в секции «меню сверху» шаблона «menu» переменной link я присвоил значение ’/’. Шаблон выполнится при любом преобразовании объекта в string (например, когда я сделаю echo). Если переменной присвоить null, то атрибут тега, в котором она находится пропадёт. А если переменная входит в тег, то удалится сам тег. В следующем шаблоне, если я присвою переменной «hide» null, пропадёт тег «b» и атрибут title тега «a»:
<a href="/" title="{$hide}"><{$hide}b>текст<{$hide}/b>Минимальная логика, которая есть в шаблоне на данный момент — возможность подстановки значения переменных из списка и отрицание переменной. Выглядит это вот так: {$var?value1?value2?value3}, значений valueN может быть сколько угодно, нумерация начинается с нуля, значения выбираются по номеру (для тех кто в теме — и по модулю длины выбираемой последовательности). Пустое значение считается
Частный случай такой конструкции — конструкция {$!var}, которая на значение эквивалентное false вернёт пусто (не null), а на значение эквивалентное true — null.
Эта условная конструкция полезна шаблону тем, что позволяет сосредоточить максимум данных о шаблоне в самом шаблоне, например, в циклических конструкциях туда можно поместить имена стилей, которые должны применяться. Отрицание полезно в случаях подобных этому:
<{$hide}b><{$!hide}i>Текст<{$!hide>/i><{$hide}/b>тут, в зависимости от состояния переменной hide, появится либо тег «b», либо «i».
Переменные подставляются в момент выполнения шаблона, так что иметь значение будет последнее выставленное значение.
В следующий раз я рассмотрю циклическую конструкцию, конструкцию управления видимостью блока, а после этого — API и выложу исходный код.

Комментарии 44
Так же как джанго и питон делают php и абсолютно любые существующие фреймворки на нем — куском говна, так же и джанговский шаблонизатор кхм… интересен.
Интересна реализация подстановок в текстах шаблонов.
Т.е. у меня секции делаются
Видимо не так понял.
Не поздно перечитать :)
Идея в том, чтобы объединить HTML и язык шаблона в единый, более удобный язык, в котором не будет ни визуального шума HTML, ни синтаксической «разности импедансов» между языком шаблона и
http://en.wikipedia.org/wiki/Haml
Мне тут прекрасно виден цикл:
#content
— @entries.each do |entry|
.entry
%h3.title= entry.title
%p.date= entry.posted.strftime(«%A, %B %d, %Y»)
%p.body= entry.body
Шаблонизаторы пишутся для удобства программирования и чтения, а не для того чтоб ускорить код. Ну а скорость — это OCalm, C, ассемблер в конце концов.
Он не виден в HTML, поэтому я не понимаю зачем мне нужен язык шаблонизатора, который выглядит как HTML.
Шаблонизаторы пишутся для того, чтобы было удобно менять оформление сайта. Если шаблонизатор был написан так, что он тормозит у меня на
Комментарий для Евгения Степанищева:
Вы утверждаете что Haml тормозит наShared-хостинге? По моему это такое же голословное утверждение, как если бы я сказал что не тормозит.
И, если это сразу не было понятно, я говорил только про синтаксис. Ваша заметка про синтаксис, правильно?
Замечание про «язык шаблонизатора, который выглядит как HTML» я не понял.
Бессмысленно сравнивать этот Akyn со Smarty. Они же для совершенно разных ситуаций.
Smarty предполагает ситуацию, когда верстальщик и программер — это два абсолютно разных человека, один из которых боится увидеть код PHP, а другого уже тошнит от HTML. Ради такой заточки в Smarty стольким пожертвовано, что просто ужат. Smarty — это круто, когда сайт ведут между делом, на бегу, а когда сайт тщательно и вдумчиво сопровождает специалист, все плюсы Smarty становятся минусами.
Alisey, Haml — это
Одно дело, когда язык программирования эмбедят в хтмл шаблоны (когда эмбедят пхп в язык шаблонов пхп — это к Болку хехе), но когда парадигму эмбеднутого руби переносят в отдельный темплейт язык, который потом переносят в другие языки — это
Ваши «доводы» сводятся к тому, что Haml говно и Руби говно.
Проблема с ней в том, что $hide — по сути одно условие. А в коде это 4 отдельных условия.
У подхода есть и хорошая сторона, но плохая, на мой взгляд перевешивает.
Да, знаю, что не очень хорошо, именно её и хочется изменить, но пока не знаю как.
Руби не говно, просто он, мягко говоря, «слабо логичен». Например, параноидально классифицируя и
Данное условие отражает недостаки Akyn — HTML не парсится, значит найти парный тег невозможно.
Болк, замени на: Тест
Нет.
На PHP, кстати, можно написать понятнее:
Тест
или (сюрприз!) вот так:
Вот смотри, какое количество минусов в таком куске кода.
Но мы опять повторяемся.
Фактически, это уже тот самый каргокульт еруби/хамла, потому что от рельсов его почти ничего не отличает. Основная проблема же этого куска — это не хтмл. Проблема номер два — не дай бог нам потребуется добавить атрибут тагу — нужно переписывать хелпер, чтобы он понимал атрибуты.
Чё я хотел
я считаю что шаблон должен содержать логику. всю логику которая связана с отображением. т.е. движок должен поддерживать и математику, и циклы, и работу со строками, все что хочешь, если этого требует отображение.
пример: я не хочу на уровне кода думать как отобразить список страниц. это не моя проблема как разработчика бизнесс логики. я говорю шаблону что всего страниц 20, сейчас открыта страница номер 7, ссылка на страницу следующая " http://example.com/users.php?page=%22. дальше шаблон уже сам думает или нарисовать это вот так
12 … 6[7]8 … 19 20, или сделать дропдаун, или сделать 1 next >.
есть огромная куча логики которую я помещаю в шаблоны. логики связанной с внешним видом страницы.
сам использую php -> xml * xslt -> html
ps:
Твой хитрый username должен работать: меня иногда комментирует _dofin_, всё ок.
Мы ушли в сторону. Причём в
Болк, так не видно задачи. Есть
Я привёл пример такой логики выше, а не ушёл в сторону. Ты же рассказываешь, как у тебя хитро (но не совсем правильно) работаю в акыне переменные. Вопрос в том, нахрена они вообще?! И почему только переменные? Почему не циклы? Не обычные условия? (Ты ведь даже в своём примере очень криво пытаешься имитировать условие
Давай я до конца всё изложу, а там посмотрим какие вопросы возникнул. Я же объяснил — это первая часть изложения.
Через некоторое время использования самописного шаблонизатора приходит понимание (скорости, гибкости и возможножностей уже не хватает), что лучший шаблонизатор -- это сам PHP, если уметь его грамотно использовать.
Несколько лет тому назад я показал, как это можно делать в шаблонизаторе PHPTemplate: http://forum.dklab.ru/viewtopic.php?t=16364
Комментарий для Евгения Степанищева:
Евгений, пусть кажый пользуется тем, что ему удобнее :)
Некоторые мысли в пределах вашей концепции. :)
В прошлом я делал шаблонизатор (похожий на ваш), специально заточеный под HTML -- он автоматически квотирует значения, в зависимости от контекста, обрабатывает условные блоки и даже умеет вставлять и вырезать параметры из URL! Вместо проверки на null у меня идет проверка конструкцией strval($value) === '' (удобно использовать значения из $_REQUEST, получается, что '', null и false это одно и тоже), а для условного парсинга тага используется служебный атрибут if. Парные таги вместе с содержимым (блоки) вырезаются/невырезаются с помощью служебного атрибута @if в парном таге. На практике пользоваться такой штукой оказалось очень удобно, но пришлось отказаться и вернуться к PHP, т.к. скорость меня не устроила.
«Пусто» у меня это пусто, а null — удаление атрибута/тега, вещи разные :)
Поведение для удаления атрибута тага / параметра URL у меня такое же -- удаляется только для NULL. Иначе невозможно послать на сервер пустое значение из поля ввода формы, что неправильно.