Акын: блоки
Я тут, если помните, принялся описывать свой шаблонизатор «Акын», многие просили. Сейчас попробую продолжить. Итак, часть вторая: блоки.
Частые паттерны — скрыть целый блок разметки или повторить его несколько раз, решается в «Акыне» одной конструкцией: описанием блока. Что именно будет происходить с блоком, шаблон «не знает». Блок идентифицируется своим именем и описывается следующим образом:
<:имя>
Значение переменной: <b>{$var}</b><br />
</:имя>В API шаблонизатора есть два
Пусть блок, описанный выше, нужно повторить три раза, заменяя «var» каждый раз на определённый текст, вот как это выглядит в коде:
$t = rt::t('template');
for ($i = 0; $i<3; $i++) {
$t->var = $i;
$t->iterate('имя');
}
echo $t;Чтобы просто показать содержимое этого блока можно вызвать
В предыдущей части я забыл упонянуть ещё одну важную конструкцию, позволяющую включать один шаблон в другой. Выглядит она, на мой взгляд, очень логично:
<$+шаблон>
<$+шаблон секция>Конструкция предпроцессорная (обрабатывается первым проходом), т. е. все блоки, переменные и прочее будут включены в шаблон из которого она вызвана.
В следующий раз опишу actions, а так же дальнейшие планы. На этом описательная часть закончится, если по этой части не потребуются разъяснения.
Комментарии 27
Это всё равно что выучить свой новый адрес при переезде. А кроме того, я никого ни к чему не принуждаю :) Это мой шаблонизатор, который писал для себя.
1. Написать на Assemblere вирус;
2. Написать engine (3D график, шаблонизатор, и т.д.);
3. Изобрести велосипед;
4. Увидеть чужой код. Сказать, что это го%но и переписать его.
100 раз в этом уже убедился … :)
2) done
3) done
4) done
По моему хорошо, когда шаблон знает об итерациях внутри себя.
Со стороны шаблона в таком случае понятно, почему
— обёрнуто в
Любой код — это источник данных. Но мы же не выносим тело
Иногда телу цикла нужно знать, что оно является телом цикла. Зачем разделять шаблон на два уровня, активный и пассивный? Не вижу в этом смысла.
Не понял про разделение шаблонов на два уровня. Какие два?
Часть презентационной логики у вас в шаблоне, а часть вне шаблона.
Если тот iterate — это не презентационная логика, то шаблонизатор либо вообще не преследует цель разделения модели и вида, либо преследует, но плохо её достигает.
Я предпочитаю писать эти части отдельно.
Я не задаюсь теми целями, которые вы обозначаете и MVC для меня вовсе не божество :) Мне работать с этим шаблонизатором удобно, дизайн править удобно, значит он хорош.
MVC не предполагает религиозного поклонения.
А удобство бывает обманчиво, многим программистам удобно использовать
Почему плохо? С гордостью. :)
Вот я сейчас работаю с индийскими программистами — вот там дела куда хуже обстоят. Каждый индийский программист:
1. Целый день (неделю) может
2. Может долго слушать и махать головой, при этом продолжать делать лажу.
3. Сделать из простой задачи очень сложную. С массой классов и пропертис, причём обязательно в этом решение есть как минимум 2 класса которые делают одно и тоже.
4. Работать с сервером через флэшку ибо обычно скорость с сервером, который находиться с ним в одном офисе 30кб/с.
5. Если надо переиспользовать код, он его просто Copy&Paste'ит.
и так далее…
У меня большой опыт, в том числе разработки своих шаблонизаторов и использования чужих, опыт не только частный, но и в коллективе.
Подход без логики в шаблоне мне, при работе в коллективе понравился больше. В частном порядке мне это тоже более удобно, тут вообще никаких «обманчиво» быть не может, весь процесс «внутри меня», я просто вижу — работает или нет. Работает.
Сравнений, увы, не хочу проводить, это вопрос очень длительного исследования, времени на это пока нет.
Комментарий для alisey.myopenid.com:
Хотябы для того, что если следовать концепции разделения обязанностей, то получится, что в подходе bolk'a -
M — данные, переменные PHP
V — «пассивный» шаблон
C — активная часть, которая говорит «как» отображать данные.
Некоторые шаблонные движки берут часть этих функций от контроллера, но отсутствие этой возможности не нарушает общей концепции. :)
Я тут ещё подумал, правильнее сказать что тут не Controller а Presenter. В итоге мы имеем полноценный MVP…
О том под какую концепцию подводить я не думал и не думаю. Под
А зря…С опытом начинаешь понимать, что помимо Manual'а надо почитать и Gang of Four и Fowler'а — из всего этого формируется более глубокое понимание в программирование, особенно в ООП подходах.
У меня есть глубокое понимание и все прочие понты :)
Я говорю, что к
Комментарий для companyowner.myopenid.com:
Рисование табличек контроллером — это не дело, тут не о чем говорить.
Вот Болк «так чувствует», этот подход я понимаю.
я переформулирую вопрос: правда, что существенным поводом написать «ещё один шаблонизатор» было ощущение что это весёлый/интересный/тп. процесс, просто как игра (не ради результата)?
а если нет, то в чём основные отличия от других шаблонизаторов? предыдущие посты я читал, если вдруг считаешь что они отвечают на вопрос -- можешь не отвечать =)
Как это нет нотификации? А вот справа от твоего ника в форме коммента
Правда, что существенным поводом написать «ещё один шаблонизатор» было то, что меня не устраивает куда идёт существующая шаблонизация: к написанию ещё одного языка программирования.
Если предыдущие посты читал, то откуда
а вопрос… ну вот возник в итоге всёравно =)
ну и раз уж тут разговаривать теперь можно, скажу, хороших же языков программирования мало (особенно под специфичные задачи)
Мало, ага, но это не причина писать на PHP ещё один :)