Разное

в принципе, я понимаю зачем они нужны и как работают, но не понимаю, когда оправдано их использование, в смысле, что это существенно экономит время, или считается более профессиональным, или что там еще.
в общем проблема следующая.
есть сайт, несложный, типа каталога товаров с возможностью поиска и корзиной заказов (ну например как fitnessfactor_com_ua). хотим заказать, чтобы его переписали, так как он несколько устарел, изменили дизайн, структуру базы подправили, добавили несколько новых функций. В общем в любом случае придется переписывать с нуля поскольку старый код слишком уж топорный. Исполнитель говорит, что он это сделает с использованием шаблонизатора, библиотеки просмотра/показа картинок (надстройка над jQuery)
и у меня вопрос - а зачем? почему не сделать сайт на простом php и jQuery.
можно конечно и используя чистый javaScript, но jQuery уже стал, можно сказать, стандартом де-факто и бессмысленно изобретать колесо, а ни про один шаблонизатор я такого не слышала.
Ведь на чистом php работать будет быстрее, и потом если позже снова что-то придется менять, где гарантия, что новый Исполнитель захочет работать с этим шаблонизатором, а не переписать все с использованием того, что он знает и что ему нравится и подходит?
вопрос не стоит в том какой шаблонизатор лушче использовать, вопрос в том нужно ли чтобы такого рода сайт был сделан с использованием того или иного шаблонизатора.
если кто-то поможет разобраться в сомнениях буду очень признательна.

Плюсом шаблонизатора является возможность замены дизайна без редактирования кода, ну может быть элементов буферизации (но это можно и без шаблонов делать). Т.е. редизайн можно проводить отдельно от обновления кода приложения - это удобно, когда дизайнеры и разработчики составляют отдельные слабо-взаимодействующие команды. Да, вы правы, шаблонизаторы никогда не добьются стандартизации уровня jQuery, которая тоже сойдет на нет, когда JavaScript будет одинаково работать во всех браузерах. Но если перспективы стандартизации JavaScript довольно туманны, то для разделения оформления, верстки и кода существуют стандартные технологии: CSS и (X)HTML. Если мало, можно еще и XLST использовать, который поддерживается всеми (вплоть до IE6), но не очень популярен из-за громоздкости и не отображения страниц в случае сбоя верстки. Поэтому на шаблонизаторы профессионалы смотрят криво, да они решают свою задачу, но использовать ресурсы перегруженного сервера для выполнения работы браузера (на вечно пинающей балду машине клиента) как-то не правильно и бесперспективно.

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

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

где гарантия, что новый Исполнитель захочет работать с этим шаблонизатором,

В этом случае достаточно использовать какой-нибудь популярный шаблонизатор (я рекомендую Smarty).

>(например, в циклах можно проверить, не является ли текущая итерация первой, последней,
>узнать номер итерации и т. д.).
Это и JavaScript позволяет и CSS. Правда, не все браузеры пока это поддерживают, но JS-библиотеки это сглаживают (это кстати, тоже неправильно, не должно быть таких библиотек - все должно быть в бразуере)... Вот тут возникает проблема, где выполнять эту работу: на сервере (шаблонизатор), у которого и так много работы или на клиентских машинах (CSS, JS-библиотеки), которые простаивают и практически ничего не делают.

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

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

Спасибо всем за ответ. Особенно cheops, доступно и всеобъемлюще.
я тоже склоняюсь к тому что связка php+html+css+jQuery(javascipt) лучшая для небольшого сайта - каталога товаров на 10-15тыс. позиций с возможностью поиска и корзиной заказа.
а есть какой-то уже устоявшийся свод правил грамотного программирования, описывающего алгоритм, реализующий идею mvc (разделения дизайна и поведения). чтобы следуя этому алгоритму (т.е. не изобретая велосипед) можно было бы решить задачу (максимально приблизиться) разделения дизайна и поведения даже используя вышеупомянутую связку?
или это все на уровне идей и общих рекомендаций, а более конкретные вещи - авторские разработки, мало афишируемые? если такие принципы программирования уже сформулированы и описаны, где об этом почитать?
спасибо за помощь.

Ну, в PHP это все довольно размыто, но правила есть... они не совсем работают в связке PHP+MySQL и PHP+HTML, из-за слабости MySQL и слишком вольных правил PHP.

Модель стараются полностью реализовать в базе данных, со всеми бизнес-правилами, абстракциями, доступами и т.п. Обычно база данных - это не просто хранилище, это сложная система, оформленная в виде триггеров, хранимых процедур, условий и т.п. В общем поэтому такие базы как MS SQL, Oracle и ценятся - там можно построить полноценную модель. Иногда, в PHP почти всегда, бизнес логику (модель) переносят на серверный уровень - т.е. вам нужен набор классов, который бы реализовывал абстрактный уровень - пользователь, его аккаунт, правила их обслуживания - язык на котором компоненты сервера будут говорить друг с другом. Далее следует контроллер (язык на котором сервер будет говорить с браузером), который обеспечивает интерфейс к модели, а браузер уже будет заниматься представлением этого интерфейса (язык на котором приложение будет говорить с клиентом). Шаблонизатор позволяет подтащить представление (вид) на сервер со стороны клиента, чтобы лучше его контролировать и не зависеть от сложных CSS/JS-правил. Однако, представление (вид) - это в сети традиционная задача браузера.
Имея это в виду, w3c и развивал HTML/XHTML/CSS в этом направлении (это и есть стандартный шаблонизатор, который работает на стороне браузера, смена CSS позволяет менять вид полностью - нужно только разработать соответствующие наборы). Теоретически через несколько лет (да и уже сейчас), если вы придерживаетесь семантической верстки по новым стандартам, вам специальные средства для разделения представления от контроллера не потребуются (на сервере никакого дизайна уже нет - идет просто текст в тэгах, без непонятных таблиц и 1px изображений). Сервер выдает XML-подобный код, который все оформляют кто во что горазд - бразуеры по своему (причем пользователь может вмешиваться в оформление), программы чтения текста по своему, парсеры с ним тоже забот не знают... Другое дело, что пока CSS/HTML/JavaScript отстают от современных потребностей (вернее уровень их реализации в бразуерах). Тут на сцену выходят вспомогательные средства, которые сглаживают и устраняют это отставание, не бесплатно, конечно, либо нагружая сервер, либо клиента, либо канал связи, а то и все одновременно. Вообще такое положение дел, должно со временем уйти.

>если такие принципы программирования уже сформулированы и описаны, где об этом
>почитать?
О том, что я написал выше - твердят во всех книгах, на всех конференциях, лет уже 12 точно... А костыли меняются слишком быстро, чтобы по ним успевали фундаментальные работы появляться... но они есть (правда по крупицам разбросаны). А философском плане... сложно проектирование изучить по книгам - опыт нужен, а когда появляется опыт - книги уже не нужны. В общем пашите всю Web-область от края до края (да собственно вы наверное этим и занимаетесь уже не один год :).

cheops, спасибо за пояснения, признательна.

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

Лично я не вижу особых преимуществ в том же смарти, например, кроме встроенного кэширования, которое можно реализовать и самому за 20 минут.

Лично я не вижу особых преимуществ в том же смарти, например, кроме встроенного кэширования, которое можно реализовать и самому за 20 минут.

Мне нравится синтаксис. Все-таки, написать:

<title>{$page_title}</title>

несколько проще, чем

<title><?php echo $page_title;?></title>

Тоже касается доступа к элементам массива:

<?php     //PHP     echo $array["index"];     //Smarty     {$array.index} ?>

Да, кстати, это серьезный плюс, как и синтаксис jQuery.

Кстати, по поводу циклов в Smarty. Вы написали выше, что тоже самое можно и при помощи JQuery и CSS. Не всегда. Дело в том, что номер итерации может пригодиться не только для смены класса у четных/нечетных элементов. Мне сегодня пришлось выводить изображения в виде галереи:

<table style="width:{$table_width}"> {foreach from=$items item=value name=gallery} {if $smarty.foreach.gallery.first} <tr> {/if} {if $smarty.foreach.gallery.iteration%3 == 0 && !$smarty.foreach.gallery.last} </tr><tr> {/if} <td style="width:{$td_width};border:3px #cacaca solid;padding:4px;text-align:center;vertical-align:top"> <div style="text-align:center;font-weight:bold;padding-bottom:4px;color:black">{$value.name}</div> {*Выводим изображение*} </td> {if $smarty.foreach.gallery.last} </tr> {/if} {/foreach} </table>

Это потому, что у вас таблица... если бы были div-блоки, вы бы при помощи JavaScript и CSS просто переводили бы строку когда вам нужно. Без серверной компоненты нельзя обойтись, когда авторизация вступает в дело (пользователь, база данных) - тут да, JavaScript не спасет... а все остальное - вплоть до игр, JS позволяет - была бы на то воля браузера.

тут да, JavaScript не спасет... а все остальное - вплоть до игр, JS позволяет - была бы на то воля браузера.

В том-то все и дело. Мне лично проще все это сделать на сервере, чем юзать JS. Да еще и от воли браузеров зависеть... Увольте. И дивной версткой заниматься, когда каждый браузер по-своему понимает CSS %) .

К тому же, IMHO, расставить элементы по странице должен сервер, а задача JS и CSS - раскрасить их. А то я выстрою все дивы в ряд, возлагая на JS обязанность расставить их, как надо, а у юзера JS отключен - что будет? Вы бы как расставляли? Думаю, не JavaScript'ом.

кстати есть же еще и синтаксис

<title><?=$page_title;?></title>

хрен редьки не слаще :)

Вот именно. Не сильно оно страшнее смарти-тегов.

Да и вообще. Кто сказал что разметка шаблонов должна быть из двух символов? Вполне нормально читаются шаблоны на чистом пхп. Не хуже смартивских. А работает в разы быстрее.

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

А теперь изобразите компактный вариант для этого

<title>{$page_title|default:"default title"|escape}</title>

<title>{$page_title|default:"default title"|escape}</title>

<?php <title><?=($page_title)?htmlspecialshars($page_title):"default title"?>></title>

*если я правильно понял синтаксис
разве страшно?

Лишняя треугольная скобка.

P.S. Звиняюсь, слишком занят, чтобы писать подробнее.

Именно что страшно... да еще и неправильно - в htmlspecialshars должно быть заключено все выражение. Ну и ради интереса можете показать данное выражение не программистам на предмет понятности. Кстати, шаблонизаторы позволяют делать намного более интересные вещи. При этом, синтаксис у них остается по прежнему простым.

Я думаю не программисты ужаснутся обоим строкам :)

>Кстати, шаблонизаторы позволяют делать намного более интересные вещи.
В этом и суть, что образуется если не язык, то библиотека с новым синтаксисом, вроде jQuery. Если образуется, значит есть потребность и текущие языки её не удовлетворяют. То, что раньше делал PHP берут на себя Smarty, сейчас jQuery, которая тоже позволяет делать много чего интересного, используя простой синтаксис, но уже на стороне клиента. Обычно такие напряжения заканчивается сменой технологии разработки и тут Smarty может оказаться не в самой выигрышной ситуации, так как основан на PHP, и не подлежит стандартизации. А довольно жесткий тренд в сторону возвращения функций представления браузерам, расширение каналов связи, повышение нагрузки на сервера, приводит к тому, что популярность Smarty если не будет падать, то как минимум не будет и расти.

PS А вообще количество программных слоев и языков в Web просто катастрофичное, и приближается к состоянию дел в Вавилоне :)

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

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

Работа с шаблоном в смарти происходит в два этапа:
1. парсинг шаблона
2. генерация html

Результатом первого этапа является обычный php файл. Если в шаблоне было что-то вроде

<title>{$some_var}</title>

То после парсинга это будет выглядеть как-то так:

<title><?=$smarty->getVar('some_var');?></title>

Так что все крикуны о "тормозном парсинге" идут лесом - парсинг выполняется только один раз. Дальше файл вызывается как обычный php.

То что данные и код нужно разделять, это я думаю ни у кого сомнения не вызывает, и Smarty для PHP-сообщества - это находка. Тем более со скоростью там вроде все в порядке (собственно, вы это подробно расписали). Когда я говорю о скорости и перегруженности серверов, я имею в виду даже не PHP, а вообще сервера. Когда у вас 500 сайтов на сервере - это одно, вывести 10 слишком производительных за его пределы и 490 сайтов продолжат работу как ни в чем ни бывало. А когда у вас один сайт на 500 серверах - это другое, ту не то что Smarty, ассемблер выучишь и всех вокруг выучить заставишь, если хотя бы от 50-70 серверов можно будет избавиться. А тенденции таковы, что Web-проекты укрупняются и популярность PHP падает, так как его использование в таких проектах - плохая затея - это язык маленьких проектов. Например, за прошлый год популярность PHP в мире упала на 20% (В РФ это будет заметно, как всегда, чуть позже). Вот о чем речь идет, и если произойдет массовый переход на другую технологию, то JS и CSS это не затронет, а Smarty - затронет (насколько мне известно, у него же нет PHP-независимого API?).

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

А откуда взялась цифра в 20%? По ссылке написано всего о 2,5%. При том что яваскрипт, которому Вы предлагаете делегировать функции серверного языка, тоже потерял 0,5%. Короче, фуфлыжная какая-то таблица - все в кучу свалено:) Хотя, даже из нее видно что ближайший веб-конкурент отстает от php примерно в 4 раза.

20% от состояния на 2010 год. Т.е. использовался в 10% мировых проектов, потерял 2.4%, т.е. интенсивность его использования упала на 24%.

>При том что яваскрипт, которому Вы предлагаете делегировать функции серверного языка, тоже
>потерял 0,5%.
Специально оговорился, что не функции серверного языка, а представление страницы. Собственно, если переносить представление на сторону сервера, то альтернативы то особенно нет. Я не говорю, что все разом ломанулись в сторону крупных проектов, просто наблюдается такая тенденция. Если она продолжится (а пока она продолжается), то JavaScript будет играть большую роль в разработке представления (так как не зависит от серверной компоненты вообще и позволяет лучше масштабировать приложения). Пока теряет да, потому что связан с текущим пока еще не очень интенсивным использованием JS (особенно на старых проектах), если концепция сменится, его движение будет независимым от серверных языков (PHP, Python, Perl), к которым он сейчас привязан.

>20% от состояния на 2010 год. Т.е. использовался в 10% мировых проектов, потерял 2.4%, т.е. интенсивность его использования упала на 24%.

Вообще достаточно смелое заявление. А как Вам такая трактовка:
из таблицы видно что за прошедший год упала доля абсолютно всех языков, традиционно используемых в вебе. Это может говорить либо о падении интереса к нему, либо о росте интереса к клиентским приложениям (что, в общем-то, логично, учитывая бурное развитие мобильных платформ).
Как я уже сказал, потеряли в доле все скриптовые языки, но python, perl, JavaScript потеряли несколько меньше за счет их обширного использования для клиентских приложений. А тот же lua так и вообще подпрыгнул на 10 позиций. Так что падение доли php объясняется только ростом клиентских приложений, а не снижением интереса к самому php (наверняка, в абсолютном выражении его использование даже увеличилось).

Короче, как я и говорил выше, таблица абсолютно фуфлыжная и высосать из нее можно любые выводы:)

Возможно. Я не использую эту таблицу для доказательства, скорее для иллюстрации. Есть другие факторы, свидетельствующие о падении интереса к PHP. 20% - это к РФ не имеет отношения, тут другие цифры, в том числе и использованию PHP (он традиционно более популярен, чем во всем мире). Корректнее говорить о тенденциях. Мне кажется, что пик популярности пройден (вывод этот не из таблицы), далее PHP будет либо оставаться на том же уровне, либо падать. Мне, как вы наверное догадываетесь, интересен не сколько сам PHP сколько, будет ли приток новых специалистов и проектов в область или она останется на прежнем уровне. Вот такое ощущение, что приток новых специалистов падает (он и должен рано или поздно падать, хотя бы из-за насыщения отрасли), а проекты становятся все масштабнее и масштабнее. Падения притока новых специалистов может в долгосрочной перспективе привести к любопытным следствиям. Как и укрупнение Web-проектов. Об них я и задумываюсь. Укрупнение проекта - это много серверов, много серверов - выгодно вычисления производить на клиентских машинах. Укрупнение проекта - нужен более производительный язык. Нет новых специалистов - нет смысла в новых книгах, книги покупают только те, кто входит в отрасль.

Спорить по этой таблице бесполезно (она отражает состояние дел в мире, а не у нас), тем более у них бывают ляпы, как это случилось в 2004 в связи со сменой поисковых движков. Тем более это не доля языков, это индекс интереса к языкам в новых проектах на текущий момент (старые проекты, понятно, разработчикам ПО не очень интересны). Мне именно этот индекс в свете вышеозначенного и интересен. Интерполяция только на основе индекса, да бесполезна, но помимо его есть и другая статистика. Собственно все это просто точка зрения - это не доказательства или руководство к действию. Это попытка предугадать развитие ситуации и сосредоточить ресурсы в наиболее выгодном порядке и направлении. Считайте, что это трейдерский прогноз, которые сработает с вероятностью 60% и не срабатывает с вероятностью 40% - на разнице и идет игра :)

имхо, по-моему они будут одинаково непонятны.

Зачем же так не красиво примеры приводить?

<title>{$page_title}</title>

против

<title><?=$page_title?></title>

{$array.index}

против

<?=$array["index"];?>

Уверен, что у шаблонизаторов есть свои интересные стороны и преимущества, но они явно заключеныне в этих примерах.

зачем вы тему 2011 года воскресили?)

Лично я не вижу особых преимуществ в том же смарти, например, кроме встроенного кэширования
кешируется код скрипта обработанный один раз вплоть до изменения шаблона, а не результат работы кода, результат тоже можно кешировать, но речь сейчас не об этом
обычные же шаблонизаторы (как раз с Вашим инклудом) каждый раз обрабатывают шаблон
единственный минус Смарти - это то что его нужно учить

единственный минус Смарти - это то что его нужно учить

А что сложного? При необходимости можно освоить в достаточной степени за несколько дней. Я эти пару дней потратил, зато теперь шаблонизатор на require_once("templates/header.php") ни за какие коврижки не променяю.

ну я же не говорил что это большой минус ;)