Рано или поздно начинает как-то нервировать, когда при смене дизайна тебя отрывают от других проектов, потому что чтоб сменить дизайн, надо лезть внуть PHP-страниц и что-то там менять. А дизайнер этого делать и подавно не собирается (а может просто не умеет).
Собственно, для меня это и стало толчком в сторону концепции “разделения данных и представления”.
В самом простом случае мы можем использовать HTML-шаблоны. Что это такое? Средство, позволяющее вынести из РНР весь HTML в отдельные файлы. Но данные туда вставлять все-равно надо, скажите вы. Да, надо, и для этого служит свой простой синтаксис, и никакого РНР-кода вперемежку с HTML!
Такова идея движка шаблонов Smarty. Я бы сказал, что это очень удобная штука, если применять ее с умом.
Итак, в первую очередь нам понадобится сам шаблонизатор. Берем и разваливаем его в какую-то папку в нашем www. После этого топаем сюда и читаем ускоренный курс обучения.
Как правило, все должно заработать. Если же все так просто с первого раза не запустилось, то давайте напишем обертку для класса Smarty.
Для начала, немного теории. Смарти при парсинге шаблона генерирует его PHP-код. Для увеличения быстродействия он его сохраняет в своем кеше и в следующий раз отдает его оттуда уже без повторной генерации (это папка template_c, у которой должны быть права на запись для апача).
И вот обертка…
function Page()
{
$path = '/var/www/mywebsite';
$this->template_dir = "$path/templates";
$this->compile_dir = "$path/templates_c";
$this->config_dir = "$path/configs";
$this->cache_dir = "$path/cache";
}
}
И теперь можно создать объект Page и делать $page->assign(‘var’,$var);
Ну, дальше уже думаю сами – кому на языке оригинала, а кому на русском.
Также я писал о том, что данные от дизайна можно отделять при помощи XHTML + CSS (т.н. бестабличная верстка). Так вот, недавно обнаружил увлекательную статью, которую советую всем прочитать.
Хотел бы заметить, что использовать такого монстра как Smarty и таскать везде эти мегабайты кода за собой — дело неправильное, особенно когда сайт целиком весит меньше этого Smarty. Впрочем, и в обратных случаях высказывание смысла не теряет.
Лучше его очень сильно упростить. Скоро напишу у себя статью про это.
Евгений
October 10th, 2006
Сказал бы, что я согласен.
За некоторым исключением. девелу-то все равно, по большей части. Смарти умеет делать циклы, чего я не видел у других.
Но одно, что мне нравится много больше, это то, что этот монстр довольно широко распроостранен. Т.е. если верстальщик к нему приучится раз, на каждом другом месте работы ему не прийдется учить новую самописную тварюшку. Это покрывает ее большой размер.
Ну а из-за самого размера я не сильно переживаю – в конце концов, он генерит PHP, который не то чтобы дизайнеру тяжело понять, но и девелу в него заглядывать страшно. Но он его не перегенеривает при каждом вызове.
Вот после Mambo я особенно остро почувствовал, что уж лучше пусть быдет такой монстр, чем такое… гм… неподдающееся описанию изврщение над человеческой психикой.
Кроме того, движек Smarty есть для Drupal, и меня это сильно порадовало – в некотором роде я почувствовал себя эдаким верстальщиком, который знает 1 инструмент, но знает его хорошо.
И я не могу не сказать, что я использую смарти хотя бы на 70% – ну на 50% в лучшем случае.
Может имеет смысл сделать SmartyLight?
dm
October 10th, 2006
Имеет, это точно. Поотчистить его от килограммов комментариев и прочей муйни.
Кстати, все эти шаблонизаторы — это написание PHP на PHP, так как PHP изначально предполагался как язык, легко встраивающийся в HTML-документы. Он сам — один большой шаблонизатор.
Так что все эти шаблонизаторы надо выкидывать к чёрту и использовать только один шаблонизатор, зато самый правильный!
зы: минуты полторы просчитывал, сколько будет 4 + 7…
Евгений
October 10th, 2006
Это куда как лучше чем ввод текста с картинки – заставляет вспомнить, как запускать калькулятор ^__^
Ну… я бы сказал, что как сам шаблонизатор он умрет. Рано или поздно, но умрет. Уровни абстракции – это сила! А облегченный Смарти – это мысль.
dm
October 10th, 2006
На этот раз вычисления прошли быстрее.
Сегодня-завтра и вправду выложу свой «шаблонизатор» (как я его привык называть).
А вообще, согласись, даже для дизайнера выучить смысл конструкций if, for и foreach — дело совсем несложное. Так нафига городить огород?
Но я и сам этот огород горожу, так что зря я сам возмущаюсь…
Евгений
October 10th, 2006
If if’у рознь =)
Ок, а такая фича как {debug} в смарти? Против танка не попрешь.
Кроме того, удобная генерация списков (options). Кеширование. Конфигурационные файлы (установка формата даты, хотябы).
И что самое приятное, верстальщик не может повредить что-то внутри РНР-кода из шаблона (а-ля присвоить $user=’vasia’ при том, что $user – инфа о пользователе из БД с кучей полей).
dm
October 10th, 2006
Если у верстальщика есть мозги он не будет ничем вредить коду. Кроме того, код ведь можно вынести в отдельные файлы, а больше верстальщика никуда и не пускать.
Что же до установки даты (и прочей конфигурации) — эти действия должен делать движок ещё ДО вывода данных, а верстальщику отдавать только готовый вариант, который никак преобразовывать не придётся.
Списки и ручками генерировать несложно.
С кэшированием соглашусь.
Что за {debug}?
Евгений
October 10th, 2006
{debug} – это неймоверная весчь.
Вот беру я как девел выдаю в шаблон кучу данных. А сам верстальщик может посмотреть, что же кроме того, что он хочет показать, приходит.
Например, страничка отображает список мп3. Верстальщик смотрит – а там еще и битрейт выдается, и длинна и т.д.
Грубо говоря, показывает все, что так или иначе попало в шаблон.
А формат даты может варьироваться в дизайне – тут надо 10/10/06, а там надо 10 Октября 2006 года. Вот. Бывает? Бывает.
dm
October 10th, 2006
Для формата даты (и вообще для вывода дат) можно использовать функции даты/времени.
А для просмотра всего что есть возможен такой вариант:
В скрипт-шаблон передаётся не куча переменных со значениями ассоциативный массив, в котором — все эти данные.
То есть не $var1=1; $var2=’абв’; а $v['var1']=1; $v['var2']=’абв’;
В этом случае:
1. Верстальщик в другие переменные не лезет и с именами не ошибается.
2. print_r($v) — и все данные для шаблона у тебя на ладони.
Вообще говоря, глупо говорить, что некая вещь, сделанная на некотором языке сильнее самого этого языка. Такое бывает крайне редко и уж Smarty к таким случаям точно не относится
Евгений
October 10th, 2006
Да, print_r всегда помогает. Но {debug} просто удобнее. Я не говорю о том, что он мощнее, но повторно изобретать велосипеды – гиблое дело, если не уверен, что получится лучше.
Смарти набрал обороты куда как выше, чем другие шаблонизаторы. Может он и медленнее, но для меня он показался значительно удобнее остальных – как для девела, так и для верстальщика.
dm
October 10th, 2006
Не спорю: у каждого свои вкусы и предпочтения. Я ведь тоже использую шаблонизатор. Просто пытаюсь сказать, что мы не правы, когда используем шаблонизаторы, в них нет необходимости.
Евгений
October 10th, 2006
Вы забываете о существовании такой организации как w3c и ее стандартах. Для шаблонизации с помощью PHP есть очень неплохо продуманый и _стандартный_ интсрумент – XSLT который берёт все данные из XML, который в свою очередь пишеться с помощью PHP DOMXML (или какого-то другого способа). Что получаем: класс-генератор XML дерева (или готовые данные в формате XML), класс который занимается управлением деревьев (в том числе их скрещиванием с помощью PHP Sablotron или LibXSLT) и XSLT шаблоны.
И все довольны – кодер т.к. ему не надо ничего переписывать и сам код чист как от элементов энтерфейса, так и от их структуры; верстальщик т.к. ему не надо трогать ни код программы ни контент и не надо учить очередной шаблонизатор, а XSLT должен знать любой уважающий себя верстальщик; человек который занимается контентом (например переводчик) т.к. он может редактировать информацию и элементы интерфейса на основе логического XML дерева.
Единственый минус – немалая нагрузка на сервер, поэтому этот метод не подойдёт для больших проэктов.
sas171
October 10th, 2006
А ведь таки мысль. Надо бы и самому поучить XSLT.
dm
October 11th, 2006
Стыдно признаться, но XPath и XSLT я только начал изучать. Но судя по тому, что уже знаю sas171 прав.
Евгений
October 11th, 2006
Я прошелся по DOMу в плане генерации XML, а XSLT видел еще в университете – он меня тогда просто ужаснул. В то же время Друпал меня тоже отпугнул, а сейчас оказался очень интересным. Надо посмотреть на XSLT, надо.
dm
October 12th, 2006
Объясните мне, несведущему, на хрена нужен смарти, если сам php – это язык в общем-то шаблонов. Берем html-код и в него вставляются псевдо-теги, которые при выполнении заменяются на результат их обработки. Чем это не шаблоны?
Вы говорите, что смарти позволяет разделить логику и представление? Так не суйте логику в представление! Заведите массивчик $A, и наполняйте его по мере выполнения скрипта..
Не
$smarty->assign(’id’,25);
а
$A[id] = 25;
и остальное в том же духе.
А в html ШАБЛОН вставьте только переменные из массива $A.
<title>Страница #<?=$A[ id ]?><title>
и все. И будут у вас логика и представление разделены Любой дизайнер в дримвивере может колбасить этот html как угодно – никакой код он не нарушит (кстати, я думаю мало кто здесь видел, как такое выглядит в дримвивере. Я сам html пишу руками, но все-таки.. Не поленитесь, будете приятно удивлены. Потому что php – это СТАНДАРТ, а смарти – так, поделки..).
С циклами – то же самое. Заводим в массивчике массив и в шаблоне вместо {start_row} и {end_row} пишем и foreach и }. Да и все точно так же. Отладочную информацию пихаем в массивчик $D, кешированием занимаемся через mod_rewrite.. Зачем городить огород?
PHP – это ведь и ЕСТЬ ЯЗЫК ШАБЛОНОВ! И работает во сто крат быстрее, чем любые “парсеры”, на нем писанные.
anton
October 13th, 2006
Антон, Вы видимо, предыдущие обсуждения не читали, но именно это я уже и пытался донести.
Евгений
October 15th, 2006
+1 в огород смарти.
вот грят, что нельзя дизигнеру знать программинг и грят смарти рул для этого – глядь, а там тот же пхп, только символы чуть чуть другие…
как говорит мой отец: – Теже яйца, ттолько в профиль!.
Р.S.
у нас тут проектик парни писали на смарти(наджен им был шаблонизатор, а вот пхп им чето не понравился…), так самая распространенная проблемма – это отсутствие валидатора смарти. ошибку именно в смарти искали по несколько часов.
а еще сами, нашли ошибки в самом смарти… мало в пхп они есть, так еще нате получите…
mika
October 16th, 2006
> самая распространенная проблемма – это отсутствие валидатора смарти
Мысль непонятна.
> нашли ошибки в самом смарти
Часто встречал ситуацию, когда спустя час-два находили ошибки в собственных руках из-за незнания предмета.
> ошибку именно в смарти искали по несколько часов
Уже год проекты со смарти делаю – ошибки не в смарти, а в руцях, его юзающих. Права на папочку, еще что-то где-то, замена файликов более старыми и удивление, чего же видишь не то.
Не юзать такие надстройки – и нафига ж нам РНР? ASM рулит! И по скорости выполнения просто зверь! И коменты и макросы жизь упрощают. Только на деле так не выходит, ибо устарел такой метод, разввивается язык, развиваются технологии, развиваются новые языки. И, скажите пожалуйста, почему РНР должен стоять на месте и торчать из HTML-ля во все стороны? Есть разница между “Быстрым” и “Удобным” вариантами. Лично для меня смарти – “удобный”. Я ж не заставляю каждого использовать его.
dm
October 16th, 2006
>вот грят, что нельзя дизигнеру знать программинг и грят смарти рул для этого – глядь, а там тот же пхп, только символы чуть чуть другие…
Угу, посмотрите на mambo и сравните с шаблонами на smarty для Drupal. Разница – на лице.
dm
October 16th, 2006
>> самая распространенная проблемма – это отсутствие валидатора смарти
>Мысль непонятна.
что же здесь непонятного. вот забыл ты где нибудь скобочку поставить и здрасьте…
>> нашли ошибки в самом смарти
>Часто встречал ситуацию, когда спустя час-два находили ошибки в собственных руках из-за незнания предмета.
дык, так везде, тут смарти не хуже не лучше. мысль в том, что ошибки пхп + ошибки смарти(только не надо говорить, что в смарти нет ошибок и написано все идеально)
в смарти меня смутило только одно – ну нафига свой синтаксис придумали???
mika
October 18th, 2006
Свой синтаксис – чтоб не забивать моск верстальщику. Так у него есть резко ограниченный круг действий, который может поместиться в голову класса “foreach – это очень сложно для меня”.
dm
October 18th, 2006
ИМХО нет смысла спорить и пользе/бесполезности SMARTY. Его главное приемущество, это то для чего он создан – возможность отделения кода от дизайна со всемы вытекающими отсюда плюсами.
Меня например больше беспокоит проблема прозводительности. Насколько большую нагрузку она даёт на сервер (особенно на больших проектах). Может кто проводил такого рода исследования?
Что касается большого объема сриптов, то это ещё ничего не значит. Там оч. много плагинов, которые в большенстве случаев не нужны. Если кого-то беспокоит что они занимают места на хостинге, то можно их поудалять, но ИМХО это не принципиально.
#Dialer
October 30th, 2006
С нагрузкой могу совершенно точно сказать – вполне примелемую. Дело в том, что он переводит при первом обращении к шаблону отпарсеный шаблон в HTML с кучей PHP в нем. Т.е. если после первого раза файл something.tpl не менялся – то он его не парсит, и возвращает данные из кеша.
дебаггером еще не тестил на скорость, но думаю если бы он был тупым и тормозным он не приобрел бы такую популярность.
dm
November 1st, 2006
нагрузка капитальная – тестил xdebug2 профайлером. процентов 50% в среднем идет дисковые операции. на ext2 чуток поменьше.
НО – это при включеной compile_check и без кэширования + у меня обычно иерархическая вложеность шаблонов – это порядка 5-10 фетчингов на генерацию странички.
к плюсам смарти (кроме перечислиных выше):
1. плагины – половину плагинов писал/менял сам по просьбе дизайнеров. это _очень_ удобно.
2. security&trusted – это тоже довольно удобно. особенно это удобно когда работают внештатные дизайнеры.
3. ресурсы – за 3 года фича понадобилось всего дважды, но порадовала простота использования.
понятно, что все это можно сделать самому на чистом пхп, но когда у тебя в разработке 5-6 проектов одновременно и 9 дизайнеров, постоянно меняющих лук-н-фил для долбаных клиентов – стандартизация и общий подход _очень_ облегчают жизнь.
да, кстати “Мегабайты кода таскать за собой” вовсе не обязательно. вполне хватит установить 1 копию на сервер и инклудить ее во всех проектах
Alex
November 3rd, 2006
Ну нагрузка с отключеным кешированием понятно что высокая. А после того, как шаблон закешировался она должна спадать до вполне приемлемого уровня.
dm
November 3rd, 2006
На одном из сайтов у меня часто возникает необходимость править шаблоны. Проблема заключается в том, что если в момент аплоада шаблона происходит обращение к сайту, в следствие чего происходит обращение и к данному шаблону, то происходит его перекомпиляция. Но так как в этот момент шаблон ещё не загружен до конца, компиляция происходит с ошибкой. Для исправленря такой ситуации приходится идти в папку templates_c и удалать там скомпилированный файл, тем самым инициируя повторную перекомпиляцию.
Сайт, о котором идёт речь достаточно посещаемый, поэтому такое происходит практически через раз. Есть идеи как это можно решить?
#Dialer
November 5th, 2006
Ставить redirect на время (на update.html например) – например, сайт обновляется – это займет пару минут – please wait a while.
dm
November 5th, 2006
я по-другому сделал, правда по другим причинам – не хотелось открывать на запись templates_c на продакшн сайте
я просто копирую компиленные темплы с девелопмент хоста. на всякий пожарный канешна пришлось немного smarty поэкстэндить – если боронь боже тестеры провтыкали, и какой-то шаблон был некомпилен, редиректю людей с дикими извинениями на хомпэйж, ну и соответственно мыло мне – устраивать разбор полетов.
Alex
November 7th, 2006
Ну это всё не то…
А что если сделать небольшой файл менеджер на PHP для работы с темплетами, который бы пзволял УМНО загружать темплейты. То есть блокировал бы на время перекомпиляцию или закрывал для чтения перезаписываемый файл. Вобщем как-то так
У кого-нибудь есть идеи как такую “умную” загрузку лучше реализовать???
#Dialer
November 10th, 2006
хм. В продолжении мысли о скрипте отдельном…
Сколько файл льется по фтп? Можно успеть заметить.
Если же их копировать на сервере из папки в папку то это займет в n раз меньше времени. И вероятность что файл будет в этот момент читаться ничтожно мала.
Собственно, что я предлагаю сделать…
Закачиваем файлы по фтп. Запускаем update.php, начинка которого близка к такой:
<?
system(‘mv /var/www/site/tpl_temp/* /var/www/site/tpl’);
?>
Скопируется моментально. Тем более, если файлов немного.
Enjoy =)
dm
November 11th, 2006
Есть шанс что хочтер запретит system и т.п. – тогда анаогичное сделать средствами php – это тоже будет довольно быстро, хотя и медленее чем использовать shell.
dm
November 11th, 2006
Ну тогда проще всего сделать простенький скрипт, который будет аплоадить файлы через web-интефейс. Ведь функция move_uploaded_file() как раз и делает то, что перемещает загруженный файл в нужное место.
#Dialer
November 13th, 2006
Аплодить много мелких файлов неудобно. Вывод: надо аплодить тарболл (tar.bz2, например). А на сервере его разворачивать в темп и дальше перемещать файлы в нужную папку. Так?
dm
November 13th, 2006
В том числе и так. Хотя мне как правило нужно аплоадить 1-2 файла, т.к. я обычно делаю шаблоны по принципу header-content-footer. Изменять как правило нужно либо header либо footer, которые для всех странц общие.
#Dialer
November 13th, 2006
Вот и сформировали идею. Осталась лишь реализация. Я надеюсь, при качественной реализации такое решение будет кем-то востребовано. У меня временно проблемы со временем, потому к реализации приступить не смогу, хотя очень и очень хотелось бы.
Еще было бы довольно неплохо использовать ajax. И этот проект (ajax-toolkit) стоит в списке приоритетов несколько раньше.
dm
November 14th, 2006
ну, есть еще старый но надежный метод с лок-дирами.
перед тем как заливать или разворачивать архивы темплов сделайте лок-дир гденить рядом с index.php что-то типа ’smaty.lock’ (после всех манипуляций с темплами его нада бу удалить) а в самом index.php сразу после создания smarty объекта проверять наличие этой директории. что-то типа
if(file_exists(’smarty.lock’)){
$smarty->compile_check = false;
}
создание директории – атомарная операция. т.е. если создать эту директорию и потождать max_execution_time вы будете иметь гарантию корректной работы со старыми компиляциями, и единственную перекомпиляцию после удаления лок-диры.
хотя имхо – compile_check должно быть false _всегда_. слишком много это check занимает. даже если перекомпиляция ненужна(99,9% всех вызовов!!!), smarty всеравно сравнивает датувремя каждого компиленного шаблона с сырцом.
Alex
November 14th, 2006
Ой чиатю зачитываюсь.
Когда вижу фразу “PHP тот же щаблонизатор” хочется толи плакать от бездарности написавшего или дико хохотать.
Совет простой если непонимаешь в чем заключается концепция шаблонизатора Smarty то не используй его.
И нехрен на него бочку гнать. Следить нужно своими кривыми руками.
alex_tc
November 21st, 2006
>Когда вижу фразу “PHP тот же щаблонизатор” хочется толи плакать от бездарности написавшего или дико хохотать.
Alex_tc, поясни плз, почему именно ты используешь смарти и почему ты советовал бы другим использовать его.
Я согласен, что шаблонизатор из РНР убогий, и сам пользую смарти, но не могу внятно обяснить почему.
dm
November 21st, 2006
Смарти генерирует PHP+HTML (в итоге), зачем нам нужно генерировать PHP, если мы сразу можем на PHP писать???
topy
March 27th, 2007
Зачем нужно писать на РНР, если можно писать на асме? Все-равно в машинный код все будет переведено.
Любой уровень абстракции – удобство и не более. Все концепции ОО, все, что изобретено поверх машинного кода не более чем удобство. Хочешь скорость – выбирай меньше абстракций. Хочешь комфорт – жертвуй скоростью.
dm
March 27th, 2007