Возникла задача дать пользователям писать свои шаблоны. По понятным причинам дать возможность писать просто php код я не хочу, потому eval отпадает.
Сейчас склоняюсь к альтернативному языку шаблона который потом буду разбирать.
Основные требования шаблона это вывод переменных и перебор циклами.
Реализовал это так.
к примеру есть шаблон

Регулярными выражениями выделяю код что между foreach повторяю его пока не закончится массив $names и заменяю через strtr {$name} на значение переменной текущей итерации цикла. С {$title} тоже только без цикла.

Но хочется немного больше возможностей. К примеру базовая работа с if else, получение свойств обьектов, возможность перебора не просто переменной, а результата выполнения метода обьекта ( {foreach$post->getUsers() as $user} ).

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

taral, А почему не взять готовые шаблонизаторы? Twig, например. Или еще какие с тем-же Django-template синтаксисом. Можно даже  смарти, если отключить возможность вставлять php вставки.

taral, я думаю, что нужно тебе обратиться к человеку с опытом. Потому что чувствую, что тебя XSS ждет 

Спасибо за совет. Опыта у меня хватает. И защиту от XSS я сделал в первую очередь.

В целом причина в том что мне не нужен весь функционал который предоставляют те шаблонизаторы. А некоторый функционал вообще не должен присутствовать. К примеру include.
Как его отключить в Twig через конфиг я не нашел.
Вторая по порядку но не по значимости причина что эти шаблонизаторы заменяют свой синтаксис на php код и исполняют его (по крайней мере мне так кажется). Это делает их хрупкими при невалидных входящих данных.
К примеру код

Выведет ошибку, поскольку закрывающего тега нету.
Мне же нужен более продвинутый аналог strtr('template text', array('{{name}}'=>'user name', '{{city}}'=>'город...'));

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

Это сообщение отредактировал(а) taral - 5.1.2012, 23:16

twig позволяет перехватывать ошибки компиляции шаблона и обработать их как нужно.


Вероятно, можно решить проблему через переопределение Lexer'a. Или переопределить функции include, extends и какие там еще, так, чтобы они выбрасывали перехватываемую ошибку компиляции.

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

Огромное спасибо. Это отличное решение!

Добавлено через 6 минут и 37 секунд
actuator а вы не знаете, можно ли настроить Twig таким образом что бы он полностью игнорировал все ошибки шаблона. Я вижу что ошибку несуществующей переменной он игнорирует по умолчанию. Но есть еще запрос к не существующим методам обьектов, не закрытые блоки if и т.д.

Все ошибки игнорировать не получится, нарушения базового синтаксиса будут ронять парсер всегда. С не закрытыми блоками чуть проще - им на вход подается поток токенов, так что можно реагировать на закрытие внешних блоков, но это потребует понимания как блоки писать. Но в TWIG почти все ошибки отслеживаются на этапе компиляции, вызывая исключения, и схватить фатальную ошибку при использовании готового шаблона - это ещё надо постараться, в отличие от Smarty. Обращения к несуществующим методам, по-моему, игнорируются и так (для TWIG это тоже переменные, решение о вызове метода или возврате переменной принимается при выполнении).

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

В своё время перед до мной стояла такая же задача. Выбрал Twig и доволен.

по моему написать свой шаблонизатор быстрее, чем разбираться с готовым.
В свое время написал с десяток различных шаблонизаторов.
Ps. Как перехватывать фатальные ошибки http://dklab.ru/chicken/nablas/45.html

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

Если брать Twig или Smarty то вы быстрее изучите их чем повторите их функционал. 

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

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

смысл есть, вопрос в том, что ответ для чего это делается точно не должен быть таким:


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

Это сообщение отредактировал(а) krundetz - 23.7.2013, 13:39