...Да да, избитая тема, религиозные войны и т.п.

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

Дело в том, что я должен предоставить возможность пользователю менять шаблоны отображения списка новостей (например) или еще что-то.
И у него нет прав к многим другим модулям CMS. Поэтому я не могу допустить, того, чтобы такой пользователь мог выполнять любой php скрипт, а это значит, что использовать PHP в качестве шаблонизатора ни в коем случае нельзя, это огромная дырень.

Итог: PHP нельзя использовать в качестве шаблонизатора в системах с гибким разделением прав доступа. 


P.S. Думаю это весомая причина отказаться от PHP в качестве главного шаблонизатора.


Приведу также пример. Допустим CMS Bitrix, где не используются шаблонизаторы. В результате чего, если злоумышленник получит доступ к управлению файлами он сможет сделать все что угодно, т.к. он может менять и загружать php файлы. 

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

Это сообщение отредактировал(а) lukas - 25.7.2009, 09:31

Опять таки зависит от ситуации, где-то легче шаблонизатор, а где-то РНР

В некоторых (небольших) проектах я вообще не заморачиваюсь и пишу HTML вперемешку с РНР, а всё оформление уходит в CSS, при несложном оформлении этого более чем достаточно...

lukas, все зависит от задачи. Где-то удобнее одно, где-то другое.
Тут нельзя не зная задачи что-то утверждать.
Я лично не люблю шаблонизаторы, потому что:
1. Это чужой код и черт его знает какие там ошибки.
2. Это универсальная обертка, которая в любом случае будет тормозить выполнение моего скрипта, по сравнению с точной подгонкой шаблоноизатора в коде ПХП.


Это значит что ты систему коряво сделал (систему шаблонов и их запуск в ГУЕ), ибо по хорошему, ГУЙ не связан с функционалом ;) В широком смысле этого слова.

Есть разные шаблонизаторы, например которые компилируют в php код. И никакой потери в быстродействии.



Зря ты так думаешь, почему это система шаблонов связана с функционалом? Посмотри на шаблоны например в UCOZ'e, там любой новичек может отдельно настроить вывод элемента новости, или регистрации в визуальном редакторе используя только шаблонные возможности.

Вот я про это и говорю, что система шаблонов не должна быть связана с функционалом, т.е. внутри PHP кода не должно быть что-то вроде: if(userValid) {print "<a href='admin.php'>ломани меня</a>"}.

Да это уже другой вопрос.   

Как раз он самый ;)

С такой параноей можно ничем не пользоваться, боясь что там ошибки. Изобретать самому велосипед, и быть уверенным что ни в чём не ошибся? 



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

Моё мнение совпадает с автором топика - если шаблоны пишешь не сам, то обязательно шаблонизатор. Тем более дизайнерам куда проще разобраться.

Свой велосипед я могу подогнать четко под задачу, это раз. Два, ошибок будет 100% меньше, пусть это и не скромно звучит, но все-таки, одно дело когда код МОЙ скорее всего будет в 10 раз меньше, чем код смарти, к примеру, то вероятность ошибки будет как минимум в 10 раз меньше.

lukas, что за бред? почему нельзя использовать PHP??? Если шаблоны компилятся в PHP значит можно сделать на PHP. 

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

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

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

ну а что мешает ему получить доступ к файлам конфигов скажем? Или к самому index.php??? Это уже вопрос настройки доступа.

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


Я конкретно про шаблоны. 


А громозкость - минус в скорости выполнения. Что касается проработки, что на 100% опенсурс код все равно не будет абсолютно устойчивым, без проверки временем. =)

А то что в нормальной cms пользователь не должен иметь доступа к таким файлам, вообще файловый менеджер должен предоставлять доступ только к мультимедийной папке, где показываются только файлы с определенным расширением. И естественно где есть ограничение на загрузку файлов по расширению. Поэтому никакого доступа к php файлам нет, и тем более к config файлам.