Не имея достаточного опыта в области Web разработки на Perl, хотелось бы почитать мнения опытных людей.
Какую модель шаблонизатора, callbacks [Mason, Embperl] или pipeline [Template Toolkit, HTML::Template], и в каких случаях вы предпочитаете?
Не имея достаточного опыта в области Web разработки на Perl, хотелось бы почитать мнения опытных людей.
Какую модель шаблонизатора, callbacks [Mason, Embperl] или pipeline [Template Toolkit, HTML::Template], и в каких случаях вы предпочитаете?
Может, callbacks и
Может, callbacks и имеет смысл - но ровно до тех пор, пока ты сам в одном лице пишешь и код, и верстку :)
Принципиальной разницы между моделями нет, пока ты держишь в голове то множество данных, которое передается в представление... А как только это перестает быть твоим личным делом :) то pipeline намного органичнее способствует ограничению этого множества данных.
На самом деле верстке приходится решать довольно ограниченный класс задач: показать/спрятать блок в зависимости от условия, вывести блок в цикле, возможно обработав особым образом первый (последний, n-ый элемент), и синтаксиса того же TT здесь более чем достаточно. Там даже обработка исключений есть :)
При этом совсем необязательно знать, что данные хранятся в структуре вида хеш с элементами-массивами хешей :) программисту так показалось удобней (более того, завтра он поменяет структуру), а видеть разименование такой структуры в шаблоне - бррр! Гораздо приятнее написать что-то вроде <a href="mailto:%user[n].contacts.email%"...
Почему Embperl разрешает вещи вида [$ if $ENV{REQUEST_METHOD} eq 'GET' $], ы? А чего еще в шаблоне можно узнать такого, чего знать не планировалось?
Особливо важно ограничить данные, выдаваемые в шаблонизатор, если шаблон накручивается на стороне клиента. Оставим в стороне экзотику типа ActiveX PerlScript, но вот XSLT таким образом используют все чаще и чаще.
Поэтому из соображений секьюрности и вообще порядка логичнее подготовить в серверном скрипте - обработчике запроса - тщательно контролируемую порцию данных и скормить ее шаблонизатору, чем разрешить шаблонизатору самому выбирать себе данные по вкусу. Правда, в первом случае мы можем сгенерить данных больше, чем их реально понадобится для формирования страницы (то есть имеем потенциальную неэффективность) - зато код становится гораздо более управляемым.
Вот еще маленькое соображение - не всякий парсер, встроенный в любимую HTML-кодером среду, сможет распознать и правильно подсветить перловые, например, конструкции. И вообще, верстальщику взять и поломать ваши вставочки <% %> - нефик делать :)
Короче, всё
Короче, всё сводится к тому, насколько конкретный верстальщик хочет/может обращаться с кодом. Если боится и ломает -- спрятать всё. Если хочет и может -- пусть помогает программить.