Концепции работы шаблонизатора

DexizeR

Новичок
Концепции работы шаблонизатора

Горьким опытом и спорами в конторе было решено писать свой шаблонизатор. Причины:
Известные нам шаблонизаторы работают с шаблонами не так, как хотелось бы нам.
Наши требования:
1. Поддержка динамических и вложенных динамических блоков.
2. Замена переменных на значения.
3. Доступный для верстальщиков синтаксис шаблонов(никаких условий, циклов, кода PHP и т.п.).
4. Самое главное требование - динамический блок можно конкатенировать с любым другим динамическим блоком или переменной в любой момент времени.


Моя концепция. Шаблон разбирается на куски - до динамического блока, тело динамического блока(соответственно если внутри него есть ещё блоки - то происходит рекурсия) и то что после динамического блока.
Реализовал я это с помощью рекурсивной функции которая создает структуру данных следующего формата(для этого примера):
$array[$filename][0] = "html code";
$array[$filename][1][0] = "begin dynamic block1";
$array[$filename][1][1][0] = "dynamic block2";
$array[$filename][1][2] = "end dynamic block1";
$array[$filename][2] = "html code";

Таким образом сами динамические блоки для удобства хранятся так:

$blocks['block_name1'] = &$array[$filename][1];
$blocks['block_name2'] = &$array[$filename][1][1];

С такой структурой, как вы сами видите, можно можно без проблем парсить и дописывать, хоть последовательно, хоть в разнобой, хоть к другим блокам, данные. Так же замечу, что при таком подходе я полностью отказался от регулярных выражений и реализовал всё с помощью функций strpos, str_replace и substr.

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

[Gisma]

Новичок
твой парсер, сложен по реализации и медленен. Особенно скользкий момент это коды до и после дин. блока. Это плохо ибо если у тебя два блок что с ними случистя при вставке html., неясно Концепции нашего парсера это:
1. Только представление данных, либо данные с привязанными к ним кодом, но логикой(блок-функции)
2. синтаксис шаблонов 2-3 вида конструкций (объявление блока, маркер, блок-функция)
3. конкатенация блоков в принципе так же как у тебя;)
4. компиляция шаблон (обязательно!;))
5. расширяемый функционал
Наш парсер весит всего 230 строчек полезного кода;)
 

Krisha

pain in the neck
Сорри за офтоп, но порода "тупых" верстальщиков постепенно себя изживает и любой более менее нормальный кодер-верстальщик способен справится с шаблонизатором у которого есть условия и циклы.

Минимальные требования для кодера-верстальщика уже сейчас это: HTML, CSS, JS, опыт работы с шаблонизаторами.

Брать в команду кодера, которого пугают циклы - это неактуально.

Не занимайтесь ерундой.

Еще раз сорри.
 

DexizeR

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


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

Концепции нашего парсера это:
1. Только представление данных, либо данные с привязанными к ним кодом, но логикой(блок-функции)
2. синтаксис шаблонов 2-3 вида конструкций (объявление блока, маркер, блок-функция)
3. конкатенация блоков в принципе так же как у тебя;)
4. компиляция шаблон (обязательно!;))
5. расширяемый функционал
А по какому же всё таки алгоритму разбираются у вас шаблоны ? И ещё мне не очень понятно что значит маркер и блок-функция. Кроме того, очень любопытно посмотреть сам ваш шаблонизатор, если можно, конечно.

Компилируемость в моё случае бесполезна, т.к. прокрутка самих блоков описана в PHP, а не в шаблоне.
Наш парсер весит всего 230 строчек полезного кода;)
Ну у меня пока около 50-70 строчек полезного кода(т.е. без пустых строк), при этом он обладает уже достаточным функционалом, но с другой стороны, код действительно достаточно сложен.

Сорри за офтоп, но порода "тупых" верстальщиков постепенно себя изживает и любой более менее нормальный кодер-верстальщик способен справится с шаблонизатором у которого есть условия и циклы.

Минимальные требования для кодера-верстальщика уже сейчас это: HTML, CSS, JS, опыт работы с шаблонизаторами.

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

Во вторых, верстальщик у нас девушка... Ну думаю тут обсуждать не будем ничего.

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

Фанат

oncle terrible
Команда форума
а почему бы не рассмотреть существующие реализации?
правда, я не очень понимаю, что такое конкатенация шаблонов...
 

mar

Новичок
DexizeR
посмотрите в сторону класса template, реализованный в phplib (именно сам template, который в файле template - без шаблонизаторов форм - они не нужны). По-моему, это (причем может быть даже не в полном объеме) то, что Вам (судя по ТЗ), требуется и по-моему в достаточно удачной реализации, которую, собственно, и можно посмотреть :) :
- шаблон полностью абстрагируется от кода
- подключение любого количества шаблонов к имеющемуся
- переменная {some_var}, которая "заполняется" из php
- блоки (любой степени вложенности), котрые парсятся из php, где и живут циклы

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

texrdcom

Новичок
От куда такое рвения отделить все от кода ?
ведь вы наверное считаете что ваш код - символы которые вы придумали ну типа #_nameVare# or {some_var}, намного выглядет лутче чем <?php echo $_nameVare;?>
Может они и выглядят коротче но несут теж правила только другие! ведь не понятно что сделает ваш шаблонизатор если пользователь внесет обычный текст {email} - не это конечно шутка но все же.
Ведь шаблонны давно уже делятся на два главных типа
Активные
Пасивные
Я сделал проще у меня шаблонны могут хранить как php код цикл, или вызов определенного метода обьекта для получения как масива так и сформированного html (который формируеться также с шаблонов - html) тоесть если логика сложна мы выносим ее в отдельный метод модуля, и метод возвращает или масив или html.
Вывод шаблонов формируеться с помощью функции перехвата вывода ...
 

alexhemp

Новичок
Как только я вижу слова "Концепция шаблонизатора" - сразу становиться ясно, что человек изобретает велосипед, ибо он просто не знает что ему реально нужно.

Используйте смарти, там все что вам нужно есть. Научите верстальщика писать foreach - это просто.

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

Фанат

oncle terrible
Команда форума
смарти - это самая большая наё... в мире пхп.
мыльный пузырь на пустом месте
 

Develar

Новичок
Фанат
Я придерживаясь вашей позиции. Любой шаблонизатор вводящий свой язык любого уровня - будь такой сложный как как smarty или что-то простенькое абсолютно ненужная вещь. Шаблонизатор должен управлять загрузкой самих шаблонов и ничего более.
Да, иногда есть такие сложные задачи, которые решаются только монстроподобным циклом и встает вопрос куда это помещать - в код программы или в код шаблона - но тут приходит на помощь SPL - и оба участника кофликта получают ясный и читаемый код.
DexizeR
Я пришел почти к такой же модели как у вас. Только использую стек буферизации - переложив грязную работу на PHP. Такой подход можно назвать макетированием или раскруткой стека.
 

Develar

Новичок
Да.
Но вопрос некорректен.
Шаблонизатор это не что то неземное, а всего лишь кусок кода.

Если не поняли привожу пример: DexizeR изобретает велосипед применяя рекурсивную функцию (читайте его пост) и грязный код с strpos, str_replace и substr. Я применяю свойство буферизации - стек.
 

alexhemp

Новичок
Фанат

По этому поводу сломано много копий. Я лично считаю промежуточный язык - приемуществом.

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

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

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

DexizeR

Новичок
Ситуация такая, за 8(в сумме) часов я написал с нуля функционал аналогичный FastTemplate(который мы использовали до этого времени)... Время генерации странички с 10 динамическими блоками и несколькими переменными общим весом в пару десятков КБ(средний размер шаблона) составляет 0.001 секунды, что на мой взгляд вполне приемлимо. При этом я получил весь требуемый функционал.

2 alexhemp, ещё раз повторяю, задания передо мной ставит начальник(он оплачивает мое время). И он решил что циклов и условий в шаблоне быть не должно.

2 Develar, очень интересно подробнее узнать о вашей концепции с применением стека.
 

[DAN]

Старожил PHPClub
DexizeR, тогда передайте вашему начальнику от PHPClub`a в моем лице глубокое непонимание его решений. Хорошему начальнику свойственно изучить суть вопроса перед принятием решений.

А вам рекомендую взять быстрый на ваш взгляд шаблонизатор (я юзаю php-templates) и быстренько написать к нему враппер.
 

Develar

Новичок
DexizeR
Ядро CMF инстанцирует View и вызывает get передавая в качестве аргумента имя шаблона с которого начнется раскрутка (как вы его определите дело вашей cmf). метод get содержит include.
Дальше в шаблонах верстальщик пользуется при необходимости четырьмя методами:

begin - начало макетирования
end - конец макетирования
insert - вставка того что было между последними begin и end
get - вставка шаблона

код класса View
http://phpclub.ru/paste/975

Пример вида page.tpl
http://phpclub.ru/paste/973
И пример макета page.layout.tpl
http://phpclub.ru/paste/974

Разумеется код представлен только как пример и как готовое использоваться не может.

И рекомендую при сложном коде и необходимости одновременного вывода оформления обратить внимание на SPL. Мух от котлет отделять помогает.
 

Alexandre

PHPПенсионер
Горьким опытом и спорами в конторе было решено писать свой шаблонизатор. Причины:
Известные нам шаблонизаторы работают с шаблонами не так, как хотелось бы нам.
Наши требования:
1. Поддержка динамических и вложенных динамических блоков.
2. Замена переменных на значения.
3. Доступный для верстальщиков синтаксис шаблонов(никаких условий, циклов, кода PHP и т.п.).
4. Самое главное требование - динамический блок можно конкатенировать с любым другим динамическим блоком или переменной в любой момент времени.
Изобретаете велосипед - похвально.
п 1-2 поддерживают большинство шаблонизаторов
п 3 - не хочешь использовать циклы или условные операторы - не используй, хотя все мои знакомые HTML кодеры знают с десяток шаблонизаторов
п4 - не обоснованное и не понятное требование. Мне кажется это требование покрывают тоже большинство шаблонизаторов, или я что-то недопонимаю
 
Сверху