Пишу простенький шаблонизатор для себя.
Имена переменных заменяю на значения с помощью $str_replace


Столкнулся вот с какой задачей: есть фрагмент HTML-шаблона. В нем есть фрагмент, который может повторяться один или несколько раз. Я его выделяю тегами.

Ну например



Как бы мне сделать функцию, которая обнаружив тэг <%item вставит его содержимое столько раз, сколько элементов в массиве $item ?
Ваши идеи?

  

Это сообщение отредактировал(а) Feldmarschall - 7.5.2008, 20:07

Уважаемый Генералиссимус!

Я читал разные статьи про шаблонизацию.
В одних из них предлагалась пассивная конструкция через include : <tr><td><?=$caption?></td></tr>
В других = активная, путем $str_replace, с шаблоном типа <tr><td>{caption}</td></tr>


Я выбрал второй вариант и спрашиваю как реализовать детали в этом варианте.





Это сообщение отредактировал(а) =Женек= - 7.5.2008, 20:57

=Женек=, тов.главнокомандующий привел контр-пример, подумай над ним, может примешь другое решение.

А сам анализ абсолютно элементарен.
а) Без регулярных выражений. Шаблонизатор проходит посимвольно весь шаблон, встречая последовательность "<%" начинает "собирать" все символы до закрывающего тега. Потом, встретив его, разбирает строку, т.е. проводит операции, которые ты описал в своем посте.
б) С регулярными выражениями. Используется callback-функция для замены последовательностей нужных символов. В этой функции проводятся все операции.

Кхе кхе... либо smarty либо xml. Нафиг велосипед крутить? Для xml могу дать класс

Просто боюсь купив лопату получить впридачу громоздкий бульдозер.
Как он в плане ресурсоемкости?

=Женек=, на всех проектах использую, никто не жалуется

Ознакомился со Smarty - великолепная вещь, буду изучать. Спасибо.

Изучишь основательно - почитай пару холиваров(даже тут есть немало таких), в которых он задействован. Найдешь кучу недостатков.

Исходя из кода, который ты привел в первом посте - лучше взять что-либо полегче. Да и вообще, в любом случае стоит выбирать что-либо полегче.

Canarat, мне не нравится, что у него в щаблонизаторе оператор цикла.
Если бы был классический блочный - я бы понял. А так, он делает, действительно, второй смарти.

А недостатки везде есть. У нас у всех недостатки. Та к что теперь - и не жить совсем? =)

Feldmarschall, я просто в целом против псевдо-синтаксиса РНР в шаблонах.

А насчет второго смарти...логика в шаблонах должна быть, но настолько элементарного вида, чтобы не создавалось ощущение, что это обертка РНР-кода 

Вообще это интересная тема, до каких пределов в шаблоне должно присутствовать управление логикой. Хочу создать, но опять развернется холивар по типу xslt vs. smarty.

Всё уже отхоливарено до нас - см. http://forum.vingrad.ru/forum/topic-54581.html =)
Лично для меня смарти ничем не отличается от xslt. Как раз с точки зрения пределов управления логикой.
А главный вывод, который я для себя сделал - шаблонизатор делает программист для программиста =)

=Женек=, на мой взгляд, самый удачный шаблонизатор - patTemplate. Тег-основанный, ничего лишнего не содержит. Использует объектную модель.

Feldmarschall, хороший вывод, я всегда старательно закрываю на него глаза 

Нет, та тема - это очень много мусора и очень мало дела. Например классная цитата из сообщения на одной из последних страниц:

http://forum.vingrad.ru/index.php?showtopi...t&p=1426829

И не подумаешь, что речь идет о шаблонизаторах..

вполне логично. но это ж не недостаток  чем выше уровень абстракции - тем сложнее обучение использованию, но тем быстрее работа. ну, в общем случае. Как если макроассемблер после ассемблера.

до тех пор, пока это логика вывода, а не выборки из БД или обработки типа explode/preg_replace и т.д.

Добавлено через 17 секунд
Никак не могу найти пост, где говорится, что шаблонизатор не "логику от представления" отделяет, а логику обработки данных отлогики вывода :(

Добавлено через 1 минуту и 33 секунды

аа... это аллюзия к мифу "шаблонизатор - для дизайнера"?   

skyboy, ок, как поступить, если дизайнер хочет непосредственно в шаблоне в одном месте выделить в одном и том же тексте слово жирным, а в другом - нет? Текст, естественно, динамический и получаемый из скрипта.

Вот один из примеров, в которых мой взгляд программиста и абстракциониста натыкается на непробиваемое "ХАЧУ" дизайнеров и верстальщиков. 

Canarat, Если ты говоришь контенте, то твое замечание, имхо, в контексте разговора о шаблонах неуместно. 
Оформление шаблона - это одно.
Обработка выводимых текстов - другое. 

Это сообщение отредактировал(а) Feldmarschall - 9.5.2008, 20:46

Это только пример. Скрипт подает на выход "Описание компании ООО "Пивзавод".", верстальщик выводит этот текст в двух местах, но в одном из них по специфике необходимо выделить тегами <b>Пивзавод</b>. Как поступить? Плодить несколько описаний? Вводить отдельные переменные?

Canarat, 
использовать две переменные
 


У тебя ведь в этой надписи разнородная информация. А выделять только Пивзавод, но не выделять ООО - это глупость. Тогда нет смысла вообще выводить это самое ООО 

Canarat, это пример совсем другого. Вестка сайта и наполнение сайта контентом - совершенно разные вещи.
Тебя совсем не в ту сторону унесло.

Feldmarschall, именно в ту. Минимальная обработка данных в шаблоне.

Fortop, дело происходит в шаблоне, из синтаксиса - только {COMPANY_DESCRIPTION}.
Или сделать "{COMPANY_DESCRIPTION_BEFORE_NAME} OOO "{THAT_DAMN_COMPANY_NAME}"" ?

Canarat, все это очень интересно. 
Но не мог бы ты пояснить, к чему вся эта полемика? Ты не согласен с тем, что skyboy о том, для кого делаются шаблонизаторы? Приведи тогда пример того, как, по-твоему, должны решаться такие проблемы.
Или это просто жалоба в пространство на нелегкую судьбу программера?

Canarat, 

Вот эта фигня - это вообще статическая часть шаблона. 
Это даже не описание как таковое, это просто фраза "описание компании".... а она одинакова для всех! компаний без исключения.

Или ты хочешь экзотический универсальный шаблон на все случаи жизни?

Fortop, на самом деле, задачка, действительно, интересная. 
Исходя из постулата, что в коде не должно быть ни одного HTML тега, мы не можем использовать str_replce(). То есть, извращаться надо в шаблоне. У меня нет готового решения этого вопроса, но меня волнует другое- почему он поднялся в контексте обсуждения шаблонов вообще.

Это сообщение отредактировал(а) Feldmarschall - 9.5.2008, 21:55

Feldmarschall, 
А где ты тут видишь теги?

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

В шаблон подается не весь контент одной строкой, а его логически законченные части, если возникает желание выделить что-то внутри части/блока - значит ты неправильно разбил контент на блоки и надо его разбить еще.

Добавлено @ 22:06
Поясню свою мысль конкретно на примере Canarat.


Либо скрипт подает на вход
только ООО "Пивзавод"
либо отдельно "Описание компании" и  ООО "Пивзавод"
либо все одной строкой "Описание компании ООО "Пивзавод"

но здесь я вижу статическую часть Описание компании (которая никогда не лежит в базе, а находится всегда в самом шаблоне)
и динамическую ООО "Пивзавод".
Ничего более.

Это сообщение отредактировал(а) Fortop - 9.5.2008, 22:12

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

Feldmarschall, это не жалоба, это мой личный интерес - как, не потеряв абстрактности решить эту проблему.

Пример я действительно подобрал неудачно. Но почему вопрос поднялся здесь - я попытаюсь объяснить. Кто мне назовет более четкое разделение в Веб-приложениях, чем Представление и Логика? 
Шаблоны - это просто часть Представления, поэтому все вопросы визуализации данных решаются именно в этих т.н. "шаблонах".

Никакой полемики я не собираюсь разводить. Я просто хочу узнать ваше мнение на этот счет:
Как решить проблему различного представления данных, если их содержимое поступает в шаблон в определенном, неизменном виде?

В качестве примера предлагаю базовые функции работы со строками, чтобы не распаляться. Всегда ли оправдано вносить абсолютно все более-менее сложные операции в скрипт, оставляя в шаблоне абсолютно примитивные конструкции?

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

Ответ же на твой вопрос будет звучать так: любую задачу по шаблонихации, можно решить с использованием любой шаблонной парадигмы. Любой. Холивар на тему "простые" шаблоны vs. "сложные" не имеет смысла.

Именно об этом я и говорил, нормального диалога на эту тему все-таки не получится.

Canarat, возможно, я пока еще не дорос до использования шаблонов 
Но у меня View имеют достаточно много кода и местами сложного. Связан он исключительно в выводом, в худшем случае определяет, какую часть данных выводить.

Различное представление данных - это работа для разных шаблонов. Естественно ХО 

Canarat, диалог возможен, когда есь четко сформулированный вопрос, который необходимо обсудить. Если каждый говорит ни о чем, безо всякой связи с остальными - то, разумеется, диалога не получится. Но причина будет не в предмете обсуждения.

Вот, чтобы далеко не ходить.

Присоединённый файл ( Кол-во скачиваний: 3 )
 reports.rar 2,75 Kb

Canarat, в этом случае данные должны прилететь в виде 'Описание компании ООО "<span>Пивзавод</span>".' После этого уже дело верстальщика стилями обеспечить раскраску этой фразы в нужные цвета в нужных местах. Никакого отношения к шоблонам этот случай не имеет 

Попробую другой пример  Из жизни.

Скрипт - галерея. Страница - вывод thumnail'ов. Выводятся они в виде двумерной таблицы 7х7. Каждая ячейка таблицы - по желанию заказчика - отдельный файл шаблон "тумбы". Как работает сейчас - в шаблоне страницы имеется кривейший костыль в виде тега TableBuilder, которому передается массив уже отпарсенных(т.е. файл ячейки уже открыт, и в цикле полностью обработан) тумб.

Недостаток - TableBuilder и необходимость подготовки каждой ячейки в скрипте. Как исправлять?

Замечание: я с большим трудом открестился от раскрашивания четных/нечетных ячеек, ибо шаблоны заказчик не хотел усложнять, а в код такой бред пихать я не согласен.

Canarat, 

jQuery -> tablesorter -> widget - zebra 
Посмотри как там это организовано, возможно тебе поможет



Что мешает использовать вложенные шаблоны?

есть общий шаблон - таблица
в каждую ячеку вставляешь шаблон "тумбы" 

Fortop, я предлагал заказчику раскрашивать на клиенте  это было отнесено к разряду "да ну нафиг мне париться".


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

Canarat, 
Уточняющие вопросы.
1. За какую часть ты все же отвечаешь?  почему javascript внутри шаблона - это  "да ну нафиг мне париться" для заказчика?

2. Насчет вложеных шаблонов.
Кто мешает сделать шаблон таблицы с достаточно сложной структурой?
- Получил он данные о твоих картинках
- посчитал их
- построил нужную таблицу
- а для каждой ячейки вызвал шаблон ячейки передав ему только кусочек данных.

Fortop, 
1. С моей стороны - программа, которая работает с данными, и программа-парсер шаблонов. Больше ничего.
2. Так ведь в данный момент все так и происходит  Но суть в том, что шаблонный парсер очень прост. Пара булевых условий, {}-вставки и этот пресловутый TableBuilder. Который как раз таки и не вписывается в образ идеального шаблонизатора.

Поэтому в данный момент "шаблон таблицы с достаточно сложной структурой" - это суть РНР-скрипт.

Ты предлагаешь усложнить шаблонизатор?

Canarat, 
Во-первых, я не вижу ничего проблемного в нахождении php кода внутри шаблона 

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

Ну например



Сам table.phtml - может содержать примерно такое



Это сообщение отредактировал(а) Fortop - 10.5.2008, 13:03

Кто спорит, что так можно?

Редактирование шаблонов занимается именно заказчик, именно такой, который совершенно не хочет вкуривать в мою философию о том, что РНР-код в шаблоне это совсем неплохо 

И этот самый мета-шаблон table.phtml он будет редактировать чуть ли не чаще чем эти маленькие ячейки, учитывая что в этом мета-шаблоне ещё находятся форма смены количества картинок на страницу, способа сортировки, навигации по категориям - и куча другого мусора.

Canarat, 
ты же понимаешь, что и рыбку съесть и рот при этом не открыть - нереально.

Запрети редактировать ему мета-шаблоны.
Сделай шаблоны максимально модульными. 
Т.е. навигация, сортировка, форма и прочее - вынеси в отдельные шаблоны. 
Вплоть до того, что строка в таблице - это отдельный шаблон. который может в себя включать только ячейки и кое-какое оформление.
Ячейка - это отдельный шаблон.

Хочет строку с четными/нечетными разноцветными ячейками? - не вопрос.
Пусть создает отдельный шаблон, строки, где ячейки будут выводиться только парами (если второй ячейки нет - ничего не выводиться).
1я ячейкая зеленая, 2я ячейка - пупырчатая.
Т.е. в данном варианте данные у тебя рассматриваются не как набор ячеек. А как набор пар.
Каждая пара имеет свойства четная и нечетная ячейка.

Короче создай ему конструктор "сделай сам".

Добавлено через 3 минуты и 23 секунды
Твоя задача прописать базовые мета-шаблоны для 3-5ти страниц, содержащие внутри себя код. (для которых максимальное изменение - это CSS стили и не более)

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

Это сообщение отредактировал(а) Fortop - 10.5.2008, 14:06

Понимаю, потому и приходится творить такие конструкторы. Причем они со временем становятся все больше и сложнее, причем связи между компонентами проследить сложно, если все делается в виде файлов, а не шаблонов, хранимых в базе(тогда ещё можно в "админке" связи отрисовать, чтобы не путаться).

Мне ещё интересно услышать XSLT/Smarty любителей. Пусть у них будет такой заказчик как в моем примере и такая же область действия.

Я вижу только один выход - xslt/xml

awers, вот тебя то я и ждал   

Давай, объясни, и с кодом пожалуйста.

Canarat, в смысле тебе шаблонизатор? )

Добавлено через 2 минуты и 41 секунду
если что - читать тут

awers, признайся, последние две страницы темы не читал совсем? 

Canarat, тебе привести пример как с помошью xslt я обработаю/вызову шаблон в шаблоне?

и

?

Это сообщение отредактировал(а) awers - 10.5.2008, 20:08

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

Canarat, я считаю что раскрашивать на стороне клиента - это твоя лень 100% )

Добавлено @ 20:16
Нет.


Хм. Ответов неограниченное множество и каждый справляется посвоему. Я выбрал для себя путь xslt и живу так )

Добавлено через 5 минут и 25 секунд
И еще. Раз ты исполнитель и человек который общается с заказчиком одно лицо - ты обязан научиться показывть человеку весы. На одной чаше простота - на другой функциональность.

Добавлено через 6 минут и 51 секунду
А если ты всетаки по тем или иным причинам неможешь донести до заказчика суть такой проблемы, плюс он открещивается от вариантов - делай как он просит, даже через Ж--- обходные пути )

Это сообщение отредактировал(а) awers - 10.5.2008, 20:16

awers, 

у меня нет доступа к шаблонам. Я предложил написать простенький JS для раскраски- но с ним не захотели иметь дело. Фраза типа "или автоматом или вообще без костылей".

Весы я умею показывать. Более того, благодаря обстоятельствам у меня есть возможность упираться рогами в свой вариант. Но такая возможность есть далеко не всегда.


Я сейчас не говорю о конкретно этом заказчике. Я говорю о реализации данной задачи таким образом, чтобы самому потом отплевываться не пришлось.

Canarat, ну я же сказал. Вариантов милионы. Я выбрал свой путь и показываю другим )
Взвешивай, читай думай. Ведь то, какие у тебя заказчики и ситуации - в точности знаешь только ты один. Мы можем рассказать только то что пробовали, проходили. Некоторые уже поделились с тобой своим опытом.