Comments 195
> А то что IDE не дружат со Smarty и ему подобными - это меня просто бесит (даже если вы настроите подсветку, навигации по классам и функциям Вам не видать)
vs.php приблуда к вижал студии прекрасно дружит и со смарти и с зенд фреймворком
vs.php приблуда к вижал студии прекрасно дружит и со смарти и с зенд фреймворком
Насколько я помню, тама реализована только подсветка синтаксиса и подсказка для функций (и то, только для стандартных)
для эклипса подсветка синтаксиса http://code.google.com/p/smartypdt/
автодополнение в эклипсе работает также как и для любого др обьекта/класса
автодополнение в эклипсе работает также как и для любого др обьекта/класса
я так и не понял чем же все-таки смарти не угодил? В нем есть все, включая кэширование, многим он удобен, почему же нужно использовать шаблонизаторы с нативным PHP синтаксисом?
судя по описанию я попадаю где-то между Junior и PHP, давно не изучаю, но еще ничего серьезного не подозреваю :)
а вот по поводу подсветки, "А то что IDE не дружат со Smarty и ему подобными - это меня просто бесит (даже если вы настроите подсветку, навигации по классам и функциям Вам не видать)", у меня старый эклипс который толком ничего не подсвечивает кроме PHP и даже не выдает подсказки по функциям, и не выделяет по всему файлу переменные или функции с таким же именем как и та на которой стоит курсор, и как-то работаю без проблем и не беспокоюсь об этом, все быстро и так нахожу и названия, параметры и их порядок вспоминаются на ходу. Я думал Lead девелоперы тем более не комплексуют из-за таких вещей. :)
судя по описанию я попадаю где-то между Junior и PHP, давно не изучаю, но еще ничего серьезного не подозреваю :)
а вот по поводу подсветки, "А то что IDE не дружат со Smarty и ему подобными - это меня просто бесит (даже если вы настроите подсветку, навигации по классам и функциям Вам не видать)", у меня старый эклипс который толком ничего не подсвечивает кроме PHP и даже не выдает подсказки по функциям, и не выделяет по всему файлу переменные или функции с таким же именем как и та на которой стоит курсор, и как-то работаю без проблем и не беспокоюсь об этом, все быстро и так нахожу и названия, параметры и их порядок вспоминаются на ходу. Я думал Lead девелоперы тем более не комплексуют из-за таких вещей. :)
Я когда-то файлы открывал по ssh и редактировал при помощи mcedit, и мне _казалось_, что я все быстро нахожу и я работаю эффективно. Когда попробовал нормальный IDE, понял, что ошибался
я работал с разными IDE и реально не вижу большого выигрыша в скорости. Особенно если работаешь со своим/знакомым кодом. Зачем мне подсветка или подсказки если я и так знаю что и как использовать?
И что вы помните все методы всех классов? А параметры для функций? А как вы отладку делаете?
да вот как-то получается, не знаю :) стандартные php функции помню и так, и параметры к ним тоже. Если свой код или чужой с которым уже работаешь какое-то время, то конечно и классы и методы и их параметры запоминаются. Я думаю многие точно так же запоминают со временем. Тем более раньше люди как-то работали без навороченных IDE, в простеньких редакторах. Наверно сейчас расслабились :)
Ну все-не все это сложный вопрос, часто лезу на php.net/strpos :) Но уже пол года как отказался от ZDE, банально из-за того, что стал вообще ничего не помнить по своему же коду и надеястя на подсказки..
Разницы в скорости в принципе не замечал с IDE без IDE.
Разницы в скорости в принципе не замечал с IDE без IDE.
Лезешь и будешь лезть постоянно, потому что в PHP нет стандарта по параметрам даже стандартных функций и где-то ($haystack, $needle), а где-то наоборот.
А еще IDE (Eclipse, ZDE) будут крайне полезны при работе с Фреймворками и Сторонними библиотеками к примеру из PEAR (тут уж точно не запомнишь и прийдется лезть в код). Лишат вас долгой отладки из-за того, что неправильно напсал имя переменной(опечатка например). И крайне будут полезны при работе в команде.
А еще IDE (Eclipse, ZDE) будут крайне полезны при работе с Фреймворками и Сторонними библиотеками к примеру из PEAR (тут уж точно не запомнишь и прийдется лезть в код). Лишат вас долгой отладки из-за того, что неправильно напсал имя переменной(опечатка например). И крайне будут полезны при работе в команде.
просто я к тому, что по описанию, Lead developer не должен от этого страдать.
А зачем изобретать велосипед заново когда он уже изобретён (PHP в смысле)? Любой не нативный шаблонизатор предоставляет меньше возможностей чем PHP... так зачем себя добровольно ограничивать?
Иногда ограничения ой как нужны... Например, чтобы из шаблона не прибить дескриптор соединения с БД (намеренно ли, нечаянно ли) или подобным образом не сотворить беды :)
Мне хватает возможностей Smarty, к тому же его легко расширять. В чем я себя ограничиваю? Например есть поддержка кэширования, мне не нужно об этом задумываться, я беру и использую.
Синтаксис смарти на мой взгляд очень удобный, он изначально нацелен на решение определенного круга задач и соотвественно не перегружен лишними вещами.
Синтаксис смарти на мой взгляд очень удобный, он изначально нацелен на решение определенного круга задач и соотвественно не перегружен лишними вещами.
дополнение к eclipse pdt видел вроде. которое добавляет поддержку синаксиса смарти. да и сам по себе Eclipse PDT впонле нормально работает со смарти.
Lead Developer - не задумывается о таких мелочах
ну не правда же =/
Задумываться приходится.
ну не правда же =/
Задумываться приходится.
И еще как приходится, ибо времени на все мало и приходится жить с уже готовым, просто приходится латать самим смарти с его багами.
Да, перегнул палку конечно автор. Линейка прогарммеров ни о чём, совневаюсь что девлид будет писать свой шаблонизатор, очередная эпопея о велосипедах. Затюненый под свои нужды смарти просто радует, отличный шаблонизатор.
Smarty нужен не столько как шаблонизатор (MVC и без него прекрассно реализовывается), а нужен он для кеширования страниц имхо.
да хреновое у него кеширование, по дате
Кеширование не должно быть частью шаблонизатора. Как правило, шаблонизатор "отрисовывает" страницу после того, как отработает бизнес-логика. В нормально спроектированной системе, данные будут прочитаны из кеша и не потребуется затрат на отработку бизнес-логики системы.
не вижу в вашей статье серьезных минусов, чтобы отказаться от использования смарти.
http://templatelite.sourceforge.net/ - есть кстати облегченный вариант. любой человек, далекий от пхп, но знакомый с html, глядя на смарти шаблончик легко поймет что там где.
хоть убейте, но синтаксис zend view, даже в их примере выглядит громоздко.
http://templatelite.sourceforge.net/ - есть кстати облегченный вариант. любой человек, далекий от пхп, но знакомый с html, глядя на смарти шаблончик легко поймет что там где.
хоть убейте, но синтаксис zend view, даже в их примере выглядит громоздко.
PHP4 - чем не минус?
Чем синтаксис <?=$test> более громоздкий и менее понятный чем {$test} ?
Чем синтаксис <?=$test> более громоздкий и менее понятный чем {$test} ?
Пятый год доказываю ровно то же самое: нафиг нужен дополнительный парсинг средствами интерпретируемого языка, когда пхп сам всё прекрасно парсит?
Ну это не мне доказывайте, я это и пытаюсь донести до разработчиков :)
Шаблоны компилятся в php-код, и при каждой загрузке не парсятся
И при каждом обращении проверяют mtime шаблона, что конечно ускоряет работу
Это можно отключить в продакшене.
Ну значит мы каждый раз считываем лишний конфиг-файл и усложняем себе жизнь. Теперь нам надо заменить шаблон, потом найти его в кеше и прибить, хорошо если меняем один файл в день. Какбы мелочь, но все состоит из таких-вот мелочей.
> считываем лишний конфиг-файл
Ну какбэ у проекта бывают конфиги, да :) И их надо читать :) И отдельный тут заводить не нужно.
> потом найти его в кеше и прибить
Наверно у любого более менее крупного проекта есть инсталляционные и обслживающие скрипты, в которых можно просто чистить папку с откомпиленными шаблонами. А в режиме дебага просто не отключать проверку mtime шаблонов.
Надуманные проблемы вобщем.
Ну какбэ у проекта бывают конфиги, да :) И их надо читать :) И отдельный тут заводить не нужно.
> потом найти его в кеше и прибить
Наверно у любого более менее крупного проекта есть инсталляционные и обслживающие скрипты, в которых можно просто чистить папку с откомпиленными шаблонами. А в режиме дебага просто не отключать проверку mtime шаблонов.
Надуманные проблемы вобщем.
видимо вы не пользовались zend_view
там будет
там будет
Чем синтаксис
Чем синтаксис
более громоздкий, нежели
?
Действительно, ничем.
<?= $this->test ?> более громоздкий, нежели {$test}?Чем синтаксис
<a href="/info/about/user/<?= $this->user->id ?>/"><img src="/img/icons/gender/<?= $this->user->gender ?>.gif" alt="<?= $this->user->gender ?>" /></a> <a href="/info/about/user/<?= $this->user->id ?>/"><?= $this->user->name ?></a>более громоздкий, нежели
<a href="/info/about/user/{$user->id}/"><img src="/img/icons/gender/{$user->gender}.gif" alt="{$user->gender}" /></a> <a href="/info/about/user/{$user->id}/">{$user->name}</a>?
Действительно, ничем.
Лично я не вижу особой разницы.
Дело ведь не в "скобочках", вопрос намного шире.
Дело ведь не в "скобочках", вопрос намного шире.
Вопрос ничем не шире - вопрос именно в скобочках. Код шаблона на нативно PHP выглядит просто жестко и неудобно. А смарти и иже сним компилируют шаблоны в код. Что очень удобно. Шаблон ты видишь в удобном виде - ну а если вдруг захочется код посмотреть - смотри.
Речь идёт именно о громоздкости синтаксиса.
Одиаково уныло...
Ваш вариант?
пых-пых изначально шаблонизатор. и если надо ТОЛЬКО шаблонизатор - не надо выдумывать велосипед
<?= sprintf(
'<a href="/info/about/user/%d/"><img src="/img/icons/gender/%s.gif" alt="%2$s" /></a> <a href="/info/about/user/%1$d/">%s</a>',
$this->user->id,
$this->user->gender,
$this->user->name
) ?>
'<a href="/info/about/user/%d/"><img src="/img/icons/gender/%s.gif" alt="%2$s" /></a> <a href="/info/about/user/%1$d/">%s</a>',
$this->user->id,
$this->user->gender,
$this->user->name
) ?>
xslt.
Меня тоже удивляет изобретения велосипедов с нативными педалями при наличии простого, мощного и хорошо реализованного механизма шаблонизации xml (имею ввиду XSLT). Более того, разбор и подстановку шаблона можно поручить как клиентскому, так и серверному процессу, не говоря уже об отсутствии привязок к версиям пхп и к пхп вообще. То есть можно смело перейти к другим язывам программирования для генерации xml и практически вся отображательная часть будет работать ;)
Wicket умеет так - естественно можно тестировать в браузере без сервера и отдавать верстальщику на доработку:
"А Вам слабо?" © =)
<a href="#" id="profileLink"><img id="genderIcon"> <span id="userName">Vasya</span></a>"А Вам слабо?" © =)
Почему-то порезалось - вместо id, должно быть wicket:id, но особой роли не меняет.
Интересный подход. А циклы?
Например так:
Ну у TR & TD, не id, а wicket-id. Табличка наполняется данными из коллекции Users, Васю мы естественно не увидим, ну только если откроем шаблон локально. Как это всё работает на сервере можно посмотреть на сайте Wicket'a.
<table>
<thead>
<tr>
<th>Id</th>
<th>Name</th>
</tr>
</thead>
<tbody>
<tr id="users">
<td id="userId">1</td>
<td id="userName">Вася</td>
</tr>
</tbody>
</table>
Ну у TR & TD, не id, а wicket-id. Табличка наполняется данными из коллекции Users, Васю мы естественно не увидим, ну только если откроем шаблон локально. Как это всё работает на сервере можно посмотреть на сайте Wicket'a.
Если уж гнаться за громоздкостью то можно в указать не идентификатор пользователя, а например, всю ссылку:
UFO just landed and posted this here
Окей. Мы пишем на 2 буквы больше, но инклудим файлы, как-то обрабаываем шаблоны, куда-то их складываем.
А потом еще смотрим дату создания, что-то вычисляем.
А так- наисал, сгенерил, отложил в memcached и радуешься жизни - генерация-то меньше получилась.
А потом еще смотрим дату создания, что-то вычисляем.
А так- наисал, сгенерил, отложил в memcached и радуешься жизни - генерация-то меньше получилась.
short_open_tag = Off стоит учитывать
PHP4 минус, да...
а short_open_tags это плюс?
а short_open_tags это плюс?
а короткие тэги по умолчанию отключены ;)
PHP4 совместим вверх с PHP5. В чем минус?
Свой собственный код можно писать на PHP5, smarty не помеха
Свой собственный код можно писать на PHP5, smarty не помеха
Мда, бинго за утрирование. Понимаете, смарти даёт выигрыш не в этой строчке кода, а в том что прячет от несчастного верстальщика рутины PHP кода (напрмиер запросы в БД или какие нибудь регулярные выражение). Смарти занимается толкьо выводом информации. Выводом данных. Так что шутка не удалась.
А short_open_tag вас не смущает?
Быстродействие. Нативные шаблоны в 2-3 раза быстрее смарти. Серьезный довод? ;)
А какой процент из времени генерации содержимого страницы (выборки из БД, обработка данных PHP и т.д.) занимает именно работа шаблонизатора ? На моих проектах 90% всего времени - это выборки из БД. И оптимизация БД или включение кеширования дает гораздо больший прирост производительности, чем 7%, которые я выйграю начав использовать нативный PHP.
Не очень. Хотя бы по той простой причине, что шаблоны Смарти представляют собой в точности такую же гремучую смесь HTML и PHP. А метаязык, на котором шаблоны верстаются - не более чем вкусность, без которой, в принципе, можно обойтись :)
Впрочем, если основное время выполнения Ваших проектов занимает рендеринг шаблонов, то да, я бы не посоветовал Вам ими пользоваться :)
Впрочем, если основное время выполнения Ваших проектов занимает рендеринг шаблонов, то да, я бы не посоветовал Вам ими пользоваться :)
есть не только смарти, скачайте http://quicky.keeperweb.com/ru/download или http://alexeyrybak.com/blitz/blitz_ru.ht… и измерьте, результаты будут менее ошеломляющие
Мне кажется, вопрос о целесообразности использовани Smarty, либо другого шаблонизатора, это вопрос личных предпочтений. Читал несколько статей с критикой Smarty и не нашел ни одного минуса, который для меня существенен. В любом случае, поменять используемый шаблонизатор в хорошо спроектированной системе можно за пару минут (не считая конечно изменение самих шаблонов)
XSLT (Extensible Stylesheet Language Transformations) - спецификация над которой работают многие не только php девелоперы, почему не использовать их опыт собранный в этой технологии?
Почему не сказано ничего о нем в статье?
Почему не сказано ничего о нем в статье?
Ага, согласен. Очень мощная вещь, и приятная в использовании :)
полностью согласен.
приходилось много всяких шаблонизаторов использовать в разное время (Smarty, в том числе), но ни один не дал такой гибкости и простоты (и разделения логики представления от логики приложения, о которых столько говорят), как XSLT. есть, конечно, и у него свои недочёты, но они в большинстве своём, нивелируются средствами exslt.
приходилось много всяких шаблонизаторов использовать в разное время (Smarty, в том числе), но ни один не дал такой гибкости и простоты (и разделения логики представления от логики приложения, о которых столько говорят), как XSLT. есть, конечно, и у него свои недочёты, но они в большинстве своём, нивелируются средствами exslt.
У нас используется, правда его втыкали по принципу, вау давайте посмотрим что за новая технология, до сих мучаемся. Ибо рекурсивные шаблоны это не особо приятно дизайнерам. Потрясает разница в скорости работы xslt шаблонизатора на PHP 4 и PHP 5. на php 5 оно может работать на несколько порядков быстрее. Хотя возможно это кривая реализация нашего шаблонизатора )
тяжело сказать почему у вас именно так все плохо с xslt, возможно вы используете старый xslt парсер (например sablotron)? Возможно не правильно используете механизм шаблонов в xslt?
По моим тестам у меня не было отставания xslt на "несколько порядков" от шаблонизаторов, а во многих случаях и выигрывали у "тяжелых" шаблонизаторов, было отставание по скорости работы от чистого php, но был выигрыш по использованию памяти и процессора.
По моим тестам у меня не было отставания xslt на "несколько порядков" от шаблонизаторов, а во многих случаях и выигрывали у "тяжелых" шаблонизаторов, было отставание по скорости работы от чистого php, но был выигрыш по использованию памяти и процессора.
Он родимый, я про sablotron. ^_^
libxslt попробуйте, sablotron не годится
Проблема в том что оно должно работать еще и на php4 ( не уверен чь libxslt поддерживает php4
http://ua.php.net/domxml_xslt_stylesheet… это функция использует libxslt и работает в php4
Саблотрон надо закопать :)
Собирайте libxslt с поддержкой exslt и будет Вам счастье.
Так же в libxslt можно регистрировать в процессоре свои функции, что позволяет гибко работать со строками.
Собирайте libxslt с поддержкой exslt и будет Вам счастье.
Так же в libxslt можно регистрировать в процессоре свои функции, что позволяет гибко работать со строками.
XSLT это не шаблонизатор как следует из эго названия!
Гланых два недостатка использования XSLT/PHP (для меня):
1) Необходимость серелизации всего в XML
2) Нет стандартного подходи к интернациолизации
Хотя сам пользуюсь последих два года только XSLT
Гланых два недостатка использования XSLT/PHP (для меня):
1) Необходимость серелизации всего в XML
2) Нет стандартного подходи к интернациолизации
Хотя сам пользуюсь последих два года только XSLT
согласен на все 100
Самое главное не то, что в нем работают многие. Самое главное что XSLT - рекомендованный w3.org стандарт.
Следование стандартам в HTML-верстке давно уже всерьез не обсуждается, в отличие от темы "какой php-шаблонизатор лучше". К сожалению.
Следование стандартам в HTML-верстке давно уже всерьез не обсуждается, в отличие от темы "какой php-шаблонизатор лучше". К сожалению.
Да, дествительно. Смарти это один из самых удобных шаблонизаторов, но у него один минус, эт оскорость. Хотя, сейчас у меня смарти стоит на проекте с ежедневной посещаемостью в 10 тысяч человек, и справляеться на ура. Но вот лично я хочу попробовать Blitz. Как понимаю он по скорости самый быстрый.
Smarty по скорости обгонял все шаблонизаторы кроме Blitz (но он написан не на PHP). В сети уже давно выкладывали тесты скорости.
Забыли добавить, что все шаблонизаторы проиграли коду без шаблонизаторов
А вот, кстати, не всегда! Внимательнее посмотрите на тесты. Иногда PHP проигрывал. Для меня это непонятно, но факт! Такое было.
С включенным кэшированием в HTML - против кода на PHP без оного кэширования...
пруфлинк?
Не то что б не доверяю, интересно почитать.
Не то что б не доверяю, интересно почитать.
Ну ладно, наврал по памяти :)
Вот тут php на втором месте после blitz.
Но! Обратите внимание: результат Smarty - 414%
А вот тут:
мы видим, что на большом шаблоне (main.tpl) TemplateLite (облегченная версия Smarty) обгоняет свой оригинал в 4 раза. Так что я думаю, что для templateLite вполне реально было бы показать результат как минимум сравнимый с чистым PHP.
Вот тут php на втором месте после blitz.
Но! Обратите внимание: результат Smarty - 414%
А вот тут:
мы видим, что на большом шаблоне (main.tpl) TemplateLite (облегченная версия Smarty) обгоняет свой оригинал в 4 раза. Так что я думаю, что для templateLite вполне реально было бы показать результат как минимум сравнимый с чистым PHP.
Лично мне нравится Blitz. Хочу, однако, заметить: подобные шаблонизаторы имеют право на жизнь только в том случае, если не реализованы на PHP (иначе - тормоза неизбежны). В остальном - синтаксис Blitz гораздо удобнее, нежели смарти или тот же PHP. Бывают ситуации, когда в PHP-шаблонизаторе неудобно сделать вещь, которую в Blitz можно сделать легко и элегантно. Например: у вас есть таблица данных, нужно посчитать общую сумму и вывести перед собственно таблицей. В случае PHP придется вынуть все данные из выборки (цикл), обернуть во что-нибудь вроде массива, посчитав при этом сумму, вывести сумму, вывести таблицу (еще цикл), пройдясь по свежесозданному массиву. Получилось два цикла (ок, я не рассматриваю сейчас пляски с ob_* бубнами). А Blitz? проходимся по результатам выборки, выводим нашу таблицу, а затем, уже имея итоговую сумму, возвращаемся к блоку, который в шаблоне стоит перед таблицей и вставляем туда эту сумму.
Я почему-то всегда думал, что задача подсчета - должна делаться не во View, а в Model. А вы оказывается для этого шаблонизатор используете..
Концепции MVC существуют разные, концепции собственно представления - тоже. Есть "активные" и "пассивные" шаблоны. Native-PHP - ярко выраженные "активные" шаблоны, ничего страшного, если какой-то минимум логики будет в них присутствовать. В Blitz схема работы несколько другая: помимо собственно шаблона, есть еще контроллер шаблона - программа на PHP. Я говорил именно про код контроллера шаблона.
Lead Developer - не задумывается о таких мелочах
За него думают Junior PHP Developer, PHP Developer, Senior PHP Developer
Zend_View я не считаю шаблонизатором. Скорее это фундамент для написания своих или использования чужих шаблонизаторов. Не случайно Смарти уже давно прикрутили к Zend_View.
Так вот - для начала Вы должны у себя в голове разделить логику от представления, а не вопить - "я смарти юзаю - я разделяю".
Я думаю, что начала стоит сделать хотя бы несколько серьёзных проектов в большом, меняющемся коллективе, а потом уже что-то разделять.
Видимо, для многих ZF стал серьёзным авторитетом....
А что в этом плохого?
По-моему уж лучше такой авторитет, чем вообще никакого.
По-моему уж лучше такой авторитет, чем вообще никакого.
Получается, что в каждом деле для Вас есть авторитет?
По-моему вы сделали поспешный и безосновательный вывод :)
Просто я считаю, что за каждой технологией должен стоять авторитет, который будет показывать типичные способы применения этой технологии. Чтобы девелоперы не писали собственные шаблонизаторы, если они сами того не хотят. Чтобы был какой-то мейнстрим, а не каша из говнокода, который копипейстится по всему инету.
Будет ли это Smarty или Zend_View - это уже не так принципиально, лишь бы был какой-то индустриальный стандарт. Именно в этом успех Джавы и Дотнета - за ними стоят крупные компании, которые учат разработчиков грамотно реализовывать типичные решения, не изобретая велосипедов.
Zend упустил этот момент в отношении PHP и теперь пытается исправить свою ошибку при помощи Zend Framework. Жаль, конечно, что они взялись за это важное дело так поздно, но лично меня очень радует, что они наконец таки взялись за него. И пусть в некоторых местах ZF пока ещё кривоват, а архитектурные решения - не совсем очевидны, прогресс идёт, шестеренки закрутились :)
Просто я считаю, что за каждой технологией должен стоять авторитет, который будет показывать типичные способы применения этой технологии. Чтобы девелоперы не писали собственные шаблонизаторы, если они сами того не хотят. Чтобы был какой-то мейнстрим, а не каша из говнокода, который копипейстится по всему инету.
Будет ли это Smarty или Zend_View - это уже не так принципиально, лишь бы был какой-то индустриальный стандарт. Именно в этом успех Джавы и Дотнета - за ними стоят крупные компании, которые учат разработчиков грамотно реализовывать типичные решения, не изобретая велосипедов.
Zend упустил этот момент в отношении PHP и теперь пытается исправить свою ошибку при помощи Zend Framework. Жаль, конечно, что они взялись за это важное дело так поздно, но лично меня очень радует, что они наконец таки взялись за него. И пусть в некоторых местах ZF пока ещё кривоват, а архитектурные решения - не совсем очевидны, прогресс идёт, шестеренки закрутились :)
Лично я считаю самым лучшим и быстрым фреймворком - чистый php, а всё остальное - приблуды, которые необходимо подключать при необходимости.
Та если бы все писали используя готовые фреймворки, то и ZF не было бы, так как до него были фреймворки, и после него будут, лично я не вижу смысла использовать настолько большой фреймворк, ну мож не дорос еще ;)
P.S. А про XSLT уже все забыли?
P.S. А про XSLT уже все забыли?
В том, что ZF - большой фреймворк, нет ничего страшного. Никто ведь не заставляет использовать абсолютно все классы, которые в него входят, причем одновременно :)
Тот же Zend View отлично живёт своей жизнью.
Другое дело, что есть куча плюшек в виде интеграции разных компонентов вместе, что дает синергетический эффект. Но это уже немного оффтопик.
Тот же Zend View отлично живёт своей жизнью.
Другое дело, что есть куча плюшек в виде интеграции разных компонентов вместе, что дает синергетический эффект. Но это уже немного оффтопик.
ZF не то чтобы авторитет, но довольно хороший фреймворк.
При чем тут ZF? Речь идет о том, чтобы отринуть саму концепцию дополнительного парсинга шаблонов, а ZF View и Smarty это просто примеры.
И по собственному опыту скажу, что и в Smarty можно нагородить такие конструкции, что даже я, как разработчик, пугаюсь.
И по собственному опыту скажу, что и в Smarty можно нагородить такие конструкции, что даже я, как разработчик, пугаюсь.
Мне кажется, что вопрос выбора того или иного шаблонизатора сильно зависит от конкретных условий разработки конкретного проекта.
По опыту могу сказать, что Smarty, особенно в руках начинающих, очень часто приводит к использованию плохих практик. Хотя, скорее всего, плох не факт использования какого-то конкретного шаблонизатора, а факт его неправильного использования.
По опыту могу сказать, что Smarty, особенно в руках начинающих, очень часто приводит к использованию плохих практик. Хотя, скорее всего, плох не факт использования какого-то конкретного шаблонизатора, а факт его неправильного использования.
Поделитесь ссылками на примеры и идем хороших практик. Спасибо.
К плохим практикам в Smarty, о которых я написал относятся:
- include одного шаблона в другой шаблон, если этот другой нигде больше не используется;
- include шаблона самого в себя (для вывода дерева);
- создание глобального объекта Smarty, в который в разных скриптах добавляются переменные так, что в итоге не понятно, что и где добавилось и что и где можно удалить.
Что касается практик хороших, то тут все более субъективно. Мое мнение, что если периодичность правок системы соизмерима со временем жизни системы, стоимость правок и стоимость введения нового человека в команду несоизмеримо меньше стоимости написания системы с нуля, то скорее всего мы имеем дело с хорошими практиками :)
- include одного шаблона в другой шаблон, если этот другой нигде больше не используется;
- include шаблона самого в себя (для вывода дерева);
- создание глобального объекта Smarty, в который в разных скриптах добавляются переменные так, что в итоге не понятно, что и где добавилось и что и где можно удалить.
Что касается практик хороших, то тут все более субъективно. Мое мнение, что если периодичность правок системы соизмерима со временем жизни системы, стоимость правок и стоимость введения нового человека в команду несоизмеримо меньше стоимости написания системы с нуля, то скорее всего мы имеем дело с хорошими практиками :)
Смартя прекрасно работает на 5-ке. Может афтар незнает...
Что мешает в качестве шаблонов использовать сам PHP. Ибо данный "шаблонизатор" самый гибкий из всех.
Неужели стоит так сильно извращаться, чтобы вместо писать {$foo}?
Лишь бы шаблоны были именно шаблонами, а не все в одном.
Неужели стоит так сильно извращаться, чтобы вместо писать {$foo}?
Лишь бы шаблоны были именно шаблонами, а не все в одном.
чтобы вместо
<?php echo $foo; ?>
писать
{$foo}
<?php echo $foo; ?>
писать
{$foo}
Не нуждаемся в шаблонизаторах (как в отдельных подсистемах), так как в концепции команды нет верстальщиков, (клиентских|серверных) разработчиков, а есть технологи. Поэтому каждый понимает все, от и до. В процессе генерации страниц используем eval-based шаблонизацию.
UFO just landed and posted this here
Действительно - чутка однобоко осветил сей вопрос - смысл же поста - шаблонизатор - это всего лишь инструмент для разделения логики и отображения - если не понимать как орудывать сим инструментом - то ничего толкового не получиться, и вторая мысль - используйте шаблонизаторы с нативным PHP синтаксисом.
Лично у меня сложилось мнение что все нужно в меру, и использовать надо то, что реально необходимо в том или ином случае. В этом у меня возникло 3 варианта:
1. Без шаблонизатора вообще - мелкие скрипты по разбору данных, анализаторы логов, висящие в cron-е, довески к статитчным сайтам в виде скрипта отправки формочки на мыло и т.д.
2. Smarty - для небольших сайтов, в разработке которых нет нужды в команде верстальщиков
3. XSLT - более менее крупные проекты
Во 2-ой пункте на самом деле Smarty - это один из вариантов, и если честно, там без разницы что использовать, хоть нативный PHP, поэтому ломать копья по этому поводу: Smarty - это некошерно, или кунфу Zend View лучше чем Fast Template - это бесполезно. Выбирать надо всегда под задачу, а не потому что что то нравится. Это как для решения задачи: поездка по бездорожью, выбирать, что лучше - Ford Focus или Hundai Accent, в то время когда нужен джип. И наоборот - брать Land Cruiser где нужен мотоцикл. В общем, ТС-у рекомендую сначала определиться что он сделать хочет, а потом уже говорить о чем либо предварительно указав рамки применения этого средства. И если он сможет это сделать, прочитав ТЗ на проект - вот тогда он Lead Developer. А пока это как анекдот:
- Грузины лучше, чем армяне !
- Чем это лучше ?
- Чем армяне !
1. Без шаблонизатора вообще - мелкие скрипты по разбору данных, анализаторы логов, висящие в cron-е, довески к статитчным сайтам в виде скрипта отправки формочки на мыло и т.д.
2. Smarty - для небольших сайтов, в разработке которых нет нужды в команде верстальщиков
3. XSLT - более менее крупные проекты
Во 2-ой пункте на самом деле Smarty - это один из вариантов, и если честно, там без разницы что использовать, хоть нативный PHP, поэтому ломать копья по этому поводу: Smarty - это некошерно, или кунфу Zend View лучше чем Fast Template - это бесполезно. Выбирать надо всегда под задачу, а не потому что что то нравится. Это как для решения задачи: поездка по бездорожью, выбирать, что лучше - Ford Focus или Hundai Accent, в то время когда нужен джип. И наоборот - брать Land Cruiser где нужен мотоцикл. В общем, ТС-у рекомендую сначала определиться что он сделать хочет, а потом уже говорить о чем либо предварительно указав рамки применения этого средства. И если он сможет это сделать, прочитав ТЗ на проект - вот тогда он Lead Developer. А пока это как анекдот:
- Грузины лучше, чем армяне !
- Чем это лучше ?
- Чем армяне !
:) а ты предстовляешь что было бы с хаброй, если бы здесь использоалось xslt. основные проблемы xslt - низкая производительность и большие ресурсозатраты. а вот плюсы шаблонизаторов я распишу ниже.
Эм... вы хотите сказать, что модуль, написанный на Си, отконвертит кусок XML-я в HTML медленнее чем интрепретируемый PHP произведет необходимое количество конкантенаций строк ? Сомневаюсь. Если, конечно, для вывода одной страницы с 50-тью комментариями выдавать XML в полмегабайта - то да, он захлебнется. Но во всех других случаях - он уж явно не медленнее любой другой шаблонизатор. А если вы планируете пихать в XSLT логику - то это уже мы не о MVC говорим. Тем более если проблемы производительности возникают из-за шаблонизатора - то значит вы что то не то кешируете :)
Вы забываете, что для XSLT преобразований кто-то еще должен делать XML. Почему вы считаете только затраты на трансформирование XML? Основная масса сайтов работает на базах данных, результат выборки надо преобразовывать в XML. Тут нужна какая-то прокладка чтобы кэшировать XML. Далеко все не так однозначно и у XSLT есть свои минусы и существенные, ровно как и плюсы. Не надо бегать с одной технологией как с флагом, надо выбирать ее под проект и задачи.
Вопрос даже не совсем в производительности... Хотя нормальные БД умеют результаты выборки выдавать в XML, что позволяет обойтись без прокладок, да и если расчитывается сильнонагруженный сервис - то там кеширование результатов (причем на нескольких уровнях) предусматривается изначально, и расчитывать, что "мы возьмем этот шаблонизатор, и все станет шоколадно" - наивно, и никто этим заниматься не будет. А вот то, что серьезный развивающийся проект надо делать максимально удобным для работы с ним команды разработчиков, чтобы потом не приходилось разгребать говнокод - это необходимо. Понятно, что наплодить нечитабельных перлов можно везде, но XSLT на мой взгляд более дуракоустойчивей. По крайней мере, в шаблоне XSLT шансы встретить {php}нереальный гвонокод на PHP{/php} равны нулю :) С другой стороны, один из плюсов XSLT - это кроссплатформенность. Если мне в какой то период времени придется перенести проект или его часть с PHP на JAVA(Pyton, С#,Си и т.д.), то можно быть уверенным, что хотя бы шаблоны переделывать не придется.
если уж разработчик позволяет использовать в шаблонах тег {php}, который можно запретить средствами смарти, то что он сделает на xslt даже страшно подумать.
ести и другие кросплатформенные шаблонизаторы, но их пратически никто не использует, так как подобная необходимость возникает крайне редко
ести и другие кросплатформенные шаблонизаторы, но их пратически никто не использует, так как подобная необходимость возникает крайне редко
>то что он сделает на xslt даже страшно подумать
зря :) если такой "разработчик" смог осилить Смарти только на уровне {php}, то в XSLT он погрязнет на первом же . Уровень вхождения в Смарти и в XSLT все таки разный и разгильдяям второй просто не осилить. Все таки чтобы с процедурного языка перейти на декларативный - нужна некая гибкость ума, а некоторые "девелоперы", ей не обладают. А вообще, если речь ведем о очень крупном проекте (в моей классификации его нет) - то там вообще все заморочено и подходить к ним с обычными мерками на уровне выбора шаблонизатора вообще смысла нет... Если нагрузки планируются такие, что время компиляции шаблона играет роль - то Apache Benchmark вам в зубы и в перед, к тестированию и экспериментам :)
зря :) если такой "разработчик" смог осилить Смарти только на уровне {php}, то в XSLT он погрязнет на первом же . Уровень вхождения в Смарти и в XSLT все таки разный и разгильдяям второй просто не осилить. Все таки чтобы с процедурного языка перейти на декларативный - нужна некая гибкость ума, а некоторые "девелоперы", ей не обладают. А вообще, если речь ведем о очень крупном проекте (в моей классификации его нет) - то там вообще все заморочено и подходить к ним с обычными мерками на уровне выбора шаблонизатора вообще смысла нет... Если нагрузки планируются такие, что время компиляции шаблона играет роль - то Apache Benchmark вам в зубы и в перед, к тестированию и экспериментам :)
хабр съел кусок, сорри:
>м же .
м же <xls:template ...>.
>м же .
м же <xls:template ...>.
красивая сказка о пороге вхождения? бред. я программировал 2 месяца, когда придя на работу обноружил что будет пробовать новый движок на xslt, дали книгу и интренет. уже после обеда я с лёгкостью правил форму. разница со смарти не значительная - вставка значения, те же foreach, if и даже, о боже, php
Я не понял, вы свой пример чему противопоставляете ? Надо понимать, что вы разгильдяй без гибкости ума, который за 4 часа прочитал книжку по XSLT и все освоил ? Или тогда о чем этот спич ? То что неглупые люди занимаются написанием сайтов - это факт. Но из него абсолютно не следует факт, что этим не могут заниматься не столь же одаренные личности. Что касается порога вхождения - он есть. И само количество программистов на PHP - тому свидетельство. Что то я не видел на форумах по Pyton, Ruby и Java тупейших по форме и по содержанию вопросов, которыми почему то изобилуют форумы на PHP. Народ начинает с попсы. Она может плохой или хорошей, но это не суть. А суть в том, что многие сделав старт, считают что они Lead Developer-ы, и задрав нос, кладут на все остальное, останавливаясь в развитии. Поэтому ваш личный пример - не доказывает ничего. В попсе могут тоже быть таланты, ибо не человек для инструмента, а инструмент для человека. Многие этого не понимают, и именно это приводит к холиварам.
Чую мысль не закончена, но это уже настолько напоминает борьбу с ветряными мельницами, что продолжать уже не хочется.
Чую мысль не закончена, но это уже настолько напоминает борьбу с ветряными мельницами, что продолжать уже не хочется.
>Понятно, что наплодить нечитабельных перлов можно везде, но XSLT на мой взгляд более дуракоустойчивей
>если такой "разработчик" смог осилить Смарти только на уровне {php}, то в XSLT он погрязнет на первом же
это к тому, что порог вхождения не сильно отличается от смарти. и код не становится качественне от того используется smarty или xslt и даже php или ruby.
уровень программистов не хороший аргумент при выборе технологий.
>если такой "разработчик" смог осилить Смарти только на уровне {php}, то в XSLT он погрязнет на первом же
это к тому, что порог вхождения не сильно отличается от смарти. и код не становится качественне от того используется smarty или xslt и даже php или ruby.
уровень программистов не хороший аргумент при выборе технологий.
На каком основании вы делаете вывод о "что порог вхождения не сильно отличается от смарти" ? Если провести опрос на хабре - как вы думаете какое будет соотношение людей, которые знают Смарти, но не знают XSLT, знают только XSLT, и знают и то и другое ? Вот когда первых и вторых примерно будет одинаковое количество - тогда можно будет говорить, о том, что уровень входа - одинаковый, потому как люди изначально не парились что изучать и изучить XSLT для них было ничуть не сложнее чем Smarty. С другой стороны, наличие форумов, наподобие вот этого: http://xpoint.ru/forums/internet/XML/for… показывает, что XSLT - это не семечки, и если все что вы в нем используете - это foreach с if и var и имеет аналогичные вещи в Smarty - то это не факт, что все остальное в нем так же тривиально.
Я думаю вероятность встретить гавношаблонный код дергающий пхп функции из xslt-шаблона, увеличится в разы, когда большая часть людей узнает, что вообщем-то можно дергать пхп функции из xslt...
ну если использовать си, то тогда уж лучше blitz. но в любом случае смарти за счёт "компилированых" шаблонов работает быстрее. а вот xml и xslt довольно сильно разрастаются в памяти и если не кеширование, то быть беде. но тоже кеширование в смарти делается элементарно, а при xslt даже кеширование на уровне php недостаточно, придётся доставлять софт и расширения.
я согласен что даже при xslt можно сделать высоконагруженный проект, знаю примеры, но с другими шаблонизаторами это будет быстрее и проще.
кстати, в смарти можно приучить до такого {$form->input('title')} и даже {xslt xml=$xml xsl=$xsl} и генерировать куски именно с помощью удобной техгнологии
я согласен что даже при xslt можно сделать высоконагруженный проект, знаю примеры, но с другими шаблонизаторами это будет быстрее и проще.
кстати, в смарти можно приучить до такого {$form->input('title')} и даже {xslt xml=$xml xsl=$xsl} и генерировать куски именно с помощью удобной техгнологии
Его было бы легче поддерживать. В наше время стоимость лишних 2-3 серверов меньше, чем стоимость верстальщика (в рассчете на год).
Я буквально вчера прикрутил xslt к django. XSLT выигрывает по производительности на 5%. (оптимизирую дальше...)
Я буквально вчера прикрутил xslt к django. XSLT выигрывает по производительности на 5%. (оптимизирую дальше...)
Полностью согласен, жаль не могу плюсик поставить комментарию :)
И Smarty, и Zend всего лишь инструменты. Если делать не высоко нагруженный проект, то на чем писать шаблоны глубоко всеравно, ибо современный сервер скушает и то и другое с приемлемой скоростью. Другое дело если предполагаются высокие нагрузки. Хотя даже при них возможно использование Smarty. Например если "бизнес" требует сделать проект быстро, а на Smarty есть много кода который можно использовать повторно, из-за чего сроки запуска проекта буду существенно меньше. Проблема производительности будет решаться банально увеличением мощности серверов, хотя это и не правильно с точки зрения хоршей архитектуры :)
И Smarty, и Zend всего лишь инструменты. Если делать не высоко нагруженный проект, то на чем писать шаблоны глубоко всеравно, ибо современный сервер скушает и то и другое с приемлемой скоростью. Другое дело если предполагаются высокие нагрузки. Хотя даже при них возможно использование Smarty. Например если "бизнес" требует сделать проект быстро, а на Smarty есть много кода который можно использовать повторно, из-за чего сроки запуска проекта буду существенно меньше. Проблема производительности будет решаться банально увеличением мощности серверов, хотя это и не правильно с точки зрения хоршей архитектуры :)
Интересно:когда нибудь на ступит время,когда все будут сидеть на на cms и делать все через всякие шаблонизаторы.
Согласитесь - разделять логику и представление надо, особенно в средних и крупных проектах, над которыми работает более одного разработчика. Для небольших проектов из десятка файлов и минимальными перспективами на масштабирование можно не использовать такое разделение, но речь щас не о таких проектах конечно же. Лично я считаю, что даже при использовании чистого php - в том наборе php файлов, которые отвечают за отображение, должен быть минимум программной логики, заточенной только на отображение (совсем без нее увы не обойтись, это приведет к раздуванию набора шаблонов и неоправданному усложнению системы в целом). Кроме того надо очень жёстко определять для себя механизм передачи параметров в шаблон - чтобы у разработчика не было соблазка "по быстрому" заюзать какую нибудь переменную, помимо передачи ее через формальный механизм. Ещё один соблазн - опять же "по быстрому" вставить где нибудь в программной части echo минуя шаблоны. От всех таких проблем избавляет smarty. Логику в smarty шаблонах использовать можно, его вполне хватает для нужд верстки. Переменные в шаблоне можно использовать только те, которые переданы assign-ом, это избавляет от возможных ошибок (понадеялись на то что переменная будет вечно, забыли, выкинули ее из логики но используем в шаблоне - типичный баг в случае просто php шаблонов). Echo в модуле тоже особо не попишешь - при грамотной организации иерархии шаблонов это бессмысленно. Но все же добавлю - большинство вышеупомянутых проблем решается руководством проекта и соответствующим уровнем разработчиков, знаю на собственном опыте руководителя.
Я бы предложил такое разделение:
# Baby PHP Developer - вообще не использует PHP шаблонизаторы... Только начал изучать PHP для создания домашней страницы... Потом узнаёт ещё и про БД, делает мелкиее каталоги и домашние страницы для знакомых.
# Junior PHP Developer - восторженно изучает Smarty или другой шаблонизатор для ускорения разработки своих проектов
# PHP Developer - везде использует Smarty, но начинает что-то подозревать, пишет свой шаблонизатор
# Senior PHP Developer - понимает в чем соль и возможно приходит к шаблонизатору аля Zend_View(В новых версияе ещё и Zen_Layout)
# Lead Developer - Думает сначала о нагрузке на сервер и бюджете, в зависимости от этого выбирает нужный путь реализации... Как говорил товарищ Курилов Л.С. всё зависит от поставленной задачи...
P.S.: На сколько я помню Смартси кеширует страницы и приводит их к нативному виду, что увеличивает скорость...
P.P.S.: Для настоящего ускорения работы скриптов можно их компилировать, или использовать примочки сохраняющие скомпилированные обычным способом скрипты в памяти.
# Baby PHP Developer - вообще не использует PHP шаблонизаторы... Только начал изучать PHP для создания домашней страницы... Потом узнаёт ещё и про БД, делает мелкиее каталоги и домашние страницы для знакомых.
# Junior PHP Developer - восторженно изучает Smarty или другой шаблонизатор для ускорения разработки своих проектов
# PHP Developer - везде использует Smarty, но начинает что-то подозревать, пишет свой шаблонизатор
# Senior PHP Developer - понимает в чем соль и возможно приходит к шаблонизатору аля Zend_View(В новых версияе ещё и Zen_Layout)
# Lead Developer - Думает сначала о нагрузке на сервер и бюджете, в зависимости от этого выбирает нужный путь реализации... Как говорил товарищ Курилов Л.С. всё зависит от поставленной задачи...
P.S.: На сколько я помню Смартси кеширует страницы и приводит их к нативному виду, что увеличивает скорость...
P.P.S.: Для настоящего ускорения работы скриптов можно их компилировать, или использовать примочки сохраняющие скомпилированные обычным способом скрипты в памяти.
UFO just landed and posted this here
А мне пофигу. рулит. :)
может хватить поклоняться шаблонам ради разделения логики. Нужно использоать их для облегчения и увеличения скорости разработки. я не понимаю тех, кто считает что замена на {$var} это уже куул. это бессмысленный перевод ресурсов.
о смарти. гораздо важнее то, что в циклических функциях есть счётчик который помогает определить первую и последнюю итерацию. а насколько полезны {html_options}. а есть ещё {popup} которая использует js библиотеку. а ещё куча разныз пре и пост фильтров. это куча готового к реиспользованию кода, который к тому же проверен годами.
о zend_view. первые версии данной приблуды меня не впечатлили, но с появлением яутв_ащкь и развитием zend_layout скорость разработки должна возрасти в разы. но всё же я не использую zend_view за возможность использовать в нём PHP, что не безопасно для некоторых проектов.
о смарти. гораздо важнее то, что в циклических функциях есть счётчик который помогает определить первую и последнюю итерацию. а насколько полезны {html_options}. а есть ещё {popup} которая использует js библиотеку. а ещё куча разныз пре и пост фильтров. это куча готового к реиспользованию кода, который к тому же проверен годами.
о zend_view. первые версии данной приблуды меня не впечатлили, но с появлением яутв_ащкь и развитием zend_layout скорость разработки должна возрасти в разы. но всё же я не использую zend_view за возможность использовать в нём PHP, что не безопасно для некоторых проектов.
Как все на смарти насели... если на минуту забыть про "отделение кода от предоставления", то единственное, что нужно сделать в Smarty-шаблоне для вывода содержимого — это написать банальное {$var}. Не надо мудрить там ни с какими псевдо-циклами. Нужный мне список в программе я оформлю html-тегами (стоп, помидорами не кидать :-)), и на этот кусок кода "повешу" отдельный tpl-файл смарти. Потом приведу внешний вид этого списка к нужному с помощью CSS. Или обьясню это верстальщику. Все.
"PHP
"PHP / Шаблонизаторы"
Ну, думаю, счас почитаю про шаблонизаторы обзорчик хороший. По шаблонизаторам-то не часто встретишь хорошую статью. А тут вона какая картинка прикручена под заголовком - стопудов фундаментальный труд. В предвкушении загрузки мозга полезной информацией, жму на ссылку и начинаю поглощение информации.
"В очередной раз подниму тему Template Engine в PHP. Боюсь, будет холивар..."
Думаю, ну блин молодец автор, сразу с места в карьер, и наперед видит, что тема "живая", что нельзя холиварить. Предупреждает значит, чтоб без холиваров. Ничтяк, думаю, значит будет фактический материал, без предвзятости.
"Так вот - для начала Вы должны у себя в голове разделить логику от представления"
Во, думаю, автор значит не просто прогер, а это настоящий разработчик, ведь умная фраза, правильная, на грани программирования и философии. От этого у мозга еще больше "потекли слюньки" в предвкушении "вкусной" информации. Вот-вот, а я тоже буду знать о шаблонизаторах достаточно много.
Далее критика смарти.
Думаю, ну да, интерпретатор в интерпретаторе, тормознуто. Вобщем откладывается мысль - смарти для нас под вопросом.
"Посмотрите на Zend_View - красивая реализация шаблонизатора с нативным PHP синтаксисом."
Ну да есть такой ЗендВью, видел немного. А дальше? Автор, ау, а дальше?
"P.S. Оглядываясь на свой предыдущий пост о рангах разработчиков, можно сие смапить на PHP:"
Хм, думаю, это что за хрень? С какого это перепуга Senior PHP Developer пишет свой шаблонизатор? Ну да, ладно, нравится автору такая терминология и система рангов, пусть. Вопросы терминологии всегда легко улаживаются и не принципиальны.
Упс! А вот и кончился эта статья. Мозг в ступоре а ля "а в чем н..бка?".
Ладно, решаю почитать комменты, а там ... Это холивар, сынок, велкам!
Ну, думаю, счас почитаю про шаблонизаторы обзорчик хороший. По шаблонизаторам-то не часто встретишь хорошую статью. А тут вона какая картинка прикручена под заголовком - стопудов фундаментальный труд. В предвкушении загрузки мозга полезной информацией, жму на ссылку и начинаю поглощение информации.
"В очередной раз подниму тему Template Engine в PHP. Боюсь, будет холивар..."
Думаю, ну блин молодец автор, сразу с места в карьер, и наперед видит, что тема "живая", что нельзя холиварить. Предупреждает значит, чтоб без холиваров. Ничтяк, думаю, значит будет фактический материал, без предвзятости.
"Так вот - для начала Вы должны у себя в голове разделить логику от представления"
Во, думаю, автор значит не просто прогер, а это настоящий разработчик, ведь умная фраза, правильная, на грани программирования и философии. От этого у мозга еще больше "потекли слюньки" в предвкушении "вкусной" информации. Вот-вот, а я тоже буду знать о шаблонизаторах достаточно много.
Далее критика смарти.
Думаю, ну да, интерпретатор в интерпретаторе, тормознуто. Вобщем откладывается мысль - смарти для нас под вопросом.
"Посмотрите на Zend_View - красивая реализация шаблонизатора с нативным PHP синтаксисом."
Ну да есть такой ЗендВью, видел немного. А дальше? Автор, ау, а дальше?
"P.S. Оглядываясь на свой предыдущий пост о рангах разработчиков, можно сие смапить на PHP:"
Хм, думаю, это что за хрень? С какого это перепуга Senior PHP Developer пишет свой шаблонизатор? Ну да, ладно, нравится автору такая терминология и система рангов, пусть. Вопросы терминологии всегда легко улаживаются и не принципиальны.
Упс! А вот и кончился эта статья. Мозг в ступоре а ля "а в чем н..бка?".
Ладно, решаю почитать комменты, а там ... Это холивар, сынок, велкам!
Также не вижу смысла в смарти.
Теряем в производительности, приобретаем линшний гембель с кешированием шаблонов, отладкой и гибкостью системы, добавляем лишние конфиги(конфиг для смарти), да и вообще усложняем систему на пустом месте и всё ради крайне сомнительной выгоды {$var} vs < ?= $var ? >.
Теряем в производительности, приобретаем линшний гембель с кешированием шаблонов, отладкой и гибкостью системы, добавляем лишние конфиги(конфиг для смарти), да и вообще усложняем систему на пустом месте и всё ради крайне сомнительной выгоды {$var} vs < ?= $var ? >.
Я сейчас использую Zend_View. До этого использовал 3 года Смарти.
Никаких плюсов нативного пхп кода в шаблоне не вижу.
Более того если шорттеги отключены
то код {$user.name}
преврашается в
user->name?>
Также считаю, что многие делают из смарти этакого монстра (благо расширяться код смарти позволяет)
По поводу классификации
Senior PHP Developer пишет свой шаблонизатор - не знаю как в вашей компании (а все знают, что глобальной классификации не существует (или её не используют)) представляют себе Senoir PHP developer - но по моему мнению senior не должен изобретать велосипед или вечный двигатель.
Никаких плюсов нативного пхп кода в шаблоне не вижу.
Более того если шорттеги отключены
то код {$user.name}
преврашается в
user->name?>
Также считаю, что многие делают из смарти этакого монстра (благо расширяться код смарти позволяет)
По поводу классификации
Senior PHP Developer пишет свой шаблонизатор - не знаю как в вашей компании (а все знают, что глобальной классификации не существует (или её не используют)) представляют себе Senoir PHP developer - но по моему мнению senior не должен изобретать велосипед или вечный двигатель.
>> Junior PHP Developer - восторженно изучает Smarty и еже с ними
>> PHP Developer - везде использует Smarty, но начинает что-то подозревать
>> Senior PHP Developer - пишет свой шаблонизатор, понимает в чем соль и возможно приходит к шаблонизатору аля Zend_View
>> Lead Developer - не задумывается о таких мелочах
Фигасе о_О Это получается я сначала был Senior Dev'ом, потом по долгу службы пришлось быть Dev'ом, а теперь я Lead Dev? :) Фигасе, фигасе!
ЗЫ: Никогда не был восторжен Smarty, т.к. не видел смысла в дублировании функционала самого РНР надстройками (да ещё и вводя дополнительный язык разметки/программирования в проект). Получается никогда не был Junior'ом :)
>> PHP Developer - везде использует Smarty, но начинает что-то подозревать
>> Senior PHP Developer - пишет свой шаблонизатор, понимает в чем соль и возможно приходит к шаблонизатору аля Zend_View
>> Lead Developer - не задумывается о таких мелочах
Фигасе о_О Это получается я сначала был Senior Dev'ом, потом по долгу службы пришлось быть Dev'ом, а теперь я Lead Dev? :) Фигасе, фигасе!
ЗЫ: Никогда не был восторжен Smarty, т.к. не видел смысла в дублировании функционала самого РНР надстройками (да ещё и вводя дополнительный язык разметки/программирования в проект). Получается никогда не был Junior'ом :)
Я вот читаю и не могу понять, зачем опять подымать баян аля amd vs intel.
В зависимости от проекта надо пользоваться нужным и удобным инструментарием, вот и все.
Шаблонизаторы, framework-и это всего навсего инструменты.
Надо проекту smarty - без проблем, надо простым php - без проблем. Я всегда говорил - просто надо правильно сразу делать архитектуру, разделять данные и управление, и самое главное не псевдо MVC, а с хорошо продуманным контроллером (единым и не поколебимым :) ) Тогда при выводе (view) вы можете что хочешь с данными делать.
И "исвините мне поуй, и бадонь зачень" (как говорят кубинцы) кто чего использует в своих проектах.
В зависимости от проекта надо пользоваться нужным и удобным инструментарием, вот и все.
Шаблонизаторы, framework-и это всего навсего инструменты.
Надо проекту smarty - без проблем, надо простым php - без проблем. Я всегда говорил - просто надо правильно сразу делать архитектуру, разделять данные и управление, и самое главное не псевдо MVC, а с хорошо продуманным контроллером (единым и не поколебимым :) ) Тогда при выводе (view) вы можете что хочешь с данными делать.
И "исвините мне поуй, и бадонь зачень" (как говорят кубинцы) кто чего использует в своих проектах.
Всё же зависит от ситуации. Пример: была необходимость, чтобы страничку могли редактировать люди, которые совершенно не разбираются ни в программировании, ни в верстке. Чтобы решить это был добавлен Смарти. В итоге например список файлов выглядит примерно вот так:
...
Всем интуитивно понятно, что тут нужно исправить, если нужно. Это статика, меняется редко: прекрасно кэшируется средствами того же Смарти. Проблем и вопросов со стороны тех, кто вносит в файлы правки - 0.
{assign var="page_title" value="Манга Death Note"}
{volume part="Том шестой." name="Компромисс." img="img/covers/deathnote_v6.jpg"}
{file name="Преемник." dslink="DeathNote-c044.rar" size="3.0 Mb."}{/file}
{file name="Нелепость." dslink="DeathNote-c045.rar" size="3.4 Mb."}{/file}
{file name="Непригодная." dslink="DeathNote-c046.rar" size="4.2 Mb."}{/file}
{file name="Забегая вперед." dslink="DeathNote-c047.rar" size="3.0 Mb."}{/file}
{file name="Сделка." dslink="DeathNote-c048.rar" size="3.3 Mb."}{/file}
{file name="Цветок в горшке." dslink="DeathNote-c049.rar" size="5.4 Mb."}{/file}
{file name="Ёцуба." dslink="DeathNote-c050.rar" size="3.6 Mb."}{/file}
{file name="Источник." dslink="DeathNote-c051.rar" size="3.6 Mb."}{/file}
{file name="В мгновение ока." dslink="DeathNote-c052.rar" size="7.7 Mb."}{/file}
{/volume}
...
Всем интуитивно понятно, что тут нужно исправить, если нужно. Это статика, меняется редко: прекрасно кэшируется средствами того же Смарти. Проблем и вопросов со стороны тех, кто вносит в файлы правки - 0.
Как этот топик мог попасть на главную? или даже в раздел PHP?
Какая его полезность?
Очередной плевок в смарти, которых тысячи
красивая картинка, афигеть
2 абзаца заезженной темы, афигеть
вывод гениальный — зенд_вью, афигеть
Какая его полезность?
Очередной плевок в смарти, которых тысячи
красивая картинка, афигеть
2 абзаца заезженной темы, афигеть
вывод гениальный — зенд_вью, афигеть
Еще один минус Smarty - это PHP4, который после 08.08.08 даже лататься не будет... - наконец-то его поддерживать не станут, ато до сих пор приходится встречать заказчиков которые говорят а у меня на сервере стоит 4-я версия, пиши для 4-й.
Поддерживаю критику шаблонизаторов - как менеджер проектов одним из основных условий исполнителям ставлю НЕиспользование этих псевдо-наворотов. Их использование очевидным образом отражается на скорости, не только конечных проектов, но самого процесса разработки, в худшую сторону (по крайней мере, по моему личному опыту). Времена, когда к разработкам привлекались верстальщики без базовой компетенции хотя-бы в пхп, на мой взгляд, прошли, лишние процедуры по отделению логики от представления, на самом деле, только отнимают полезный временной ресурс.
По поводу пользы для верстальщиков. Убейте меня, но если есть три человека:
1) Дизаинер
2) Верстальщик
3) Программист
То из них о существовании {$user->id} знает только программист и я не понимаю нахрена верстальщика загружать вниканием в архитектуру и структуры проекта, если его задача нарезать картинку и отдать программисту. Ну а если верстальщик и программист совмещенны в одном человеке, то тогда тут только дело вкуса. Но, как по мне, я не понимаю зачем нужен шаблонизатор, если php справляется с этой функцией ничем не хуже. Только разве для того, чтобы похвастаться? Да и использование темплеитов не позволяет разделять логику от отображения, а _заставляет_ это делать, а это не учит программиста, а дресирует.
1) Дизаинер
2) Верстальщик
3) Программист
То из них о существовании {$user->id} знает только программист и я не понимаю нахрена верстальщика загружать вниканием в архитектуру и структуры проекта, если его задача нарезать картинку и отдать программисту. Ну а если верстальщик и программист совмещенны в одном человеке, то тогда тут только дело вкуса. Но, как по мне, я не понимаю зачем нужен шаблонизатор, если php справляется с этой функцией ничем не хуже. Только разве для того, чтобы похвастаться? Да и использование темплеитов не позволяет разделять логику от отображения, а _заставляет_ это делать, а это не учит программиста, а дресирует.
Мда... читаю и диву даюсь. Куча коментов инфы нифига нету. Такое ощущение, что каждый стремиться написать что нибудь, чтобы получить плюсик. В итоге я десять раз видел что смарти компилирует код в нативный php.
Как такое г. смогло вылезти на главную.
Обычно я не комментирую подобного рода статьи, потому что комментировать особо нечего. Но тут меня заставило это сделать классификация девелоперов. Если так классифицируют PHP девелоперов у такого языка великое будущее.
Скорость, скорость.... поищите на Хабре статью про подобного рода "выигрыши" в PHP, и сразу всё станет ясно.
Как такое г. смогло вылезти на главную.
Обычно я не комментирую подобного рода статьи, потому что комментировать особо нечего. Но тут меня заставило это сделать классификация девелоперов. Если так классифицируют PHP девелоперов у такого языка великое будущее.
Скорость, скорость.... поищите на Хабре статью про подобного рода "выигрыши" в PHP, и сразу всё станет ясно.
PHP Guru - он думает, что думает о коде,
а на самом деле код думает о Гуру :)
Junior PHP Developer - думает, что думает о коде,
а на самом деле за него всё давно уже придумали :)
а на самом деле код думает о Гуру :)
Junior PHP Developer - думает, что думает о коде,
а на самом деле за него всё давно уже придумали :)
Никогда не понимал, зачем делать интерпретатор на интерпретаторе. Нативный PHP прекрасно юзается в шаблонах, наши верстальщики принимают на ура. Просто разделять нужно логически, а не сменой синтаксиса (в данном случае). На самом деле, чаще всего достаточно echo, isset и foreach.
Не понимаю, из-за чего весь сыр-бор - надо шаблонизатор, можно и написать, или str_replace отменили?
Дайте пожалуйста ссылки на материалы про xslt для ламеров (желательно на русском).
Находил много, но слишком сложные для понимания в 3 часа ночи (мое время для познания и впитывания нового).
Вообщем хочу изучить всю цепочку php->(xslt->xml->)кеш->html
Спасибо.
Находил много, но слишком сложные для понимания в 3 часа ночи (мое время для познания и впитывания нового).
Вообщем хочу изучить всю цепочку php->(xslt->xml->)кеш->html
Спасибо.
Мне пока хватает просейшего шаблонизатора, который умеет заменять @something@ в шаблоне на то, что находится в переменной $this->something или на то, что вернет метод $this->something() в классе, который обрабатывает шаблон. Есть рекурсия - @+something@, которая предполагает, что $this->something - тоже шаблон, имеющий выражения вида @...@
Работает быстро и удобно. Иногда, правда, не хватает чего-то типа if
Работает быстро и удобно. Иногда, правда, не хватает чего-то типа if
Когда то на заре своей работы в WEB среде я написал свой шаблонизатор, парсился регспами, вставляя заместо себя модули, подключаемые к шаблонизатору... Было круто, объектно и удобно...
Потом проникся XML+XSLT, потом много чем еще.
Исходя из своего опыта могу сказать следующее, по пунктам:
1) Если требуется "простенький" шаблонизатор, надо юзать php и не морочить себе голову, ибо он очень просто решает большинство проблем, код приемственен и ему проще обучить, чем обучать php + шаблонизатор ( в этом случае к знаниям php + чтотоSQL + html + css добавляется необходимость знания шаблонизатора
2) Если требуется MVC, то лучше всего юзать XML + XSL - ибо это по стандарту и ОЧЕНЬ мощно. Со скоростью проблем нет, чтобы там не говорили. Но стоит юзать лишь на PHP >=5 ( изза процессора преобразований, ибо саблотрон это жесть с большой буквы )
3) Если требуется модульность, что бывает в случае, когда у вас мощная CMS и XML-ом вот ну ни как не обойтись ( очень мало вероятно при грамотном подходе и с умением вставлять результат выполнения ф-й на PHP ) то тогда да - шаблонизатор.
Единтсвенно, когда шаблонизатор может быть более оправдан чем XSL преобразование - это в случае ОЧЕНЬ большого и сложного проекта, где обширная CMS и много людей, отвечающих за программинг например, ибо уменее правильно писать на XSL - это достаточно редкий скилл. XSL по своей витиеватости очень похож на регекспы и башка частенько трещит у неподготовленного ( да и у подготовленного тоже ). В этом случае кастомный вариант лучше - ибо он обычно четко структизирован и документирован, и имеет меньше сущностей - т.е. код на нем для данной группы разработчиков будет более легким и лаконичным.
Однако я против "стандартных" тепмлейторов, ибо считаю что под серъезный проект лучше написать "свой" кстомный. Почему? изза лаконичности и заточенности. Всежтаки публичные шаблонизаторы не отличаются лаконичностью, ибо уходят в сторону универсальности. И это правильно ;)
Потом проникся XML+XSLT, потом много чем еще.
Исходя из своего опыта могу сказать следующее, по пунктам:
1) Если требуется "простенький" шаблонизатор, надо юзать php и не морочить себе голову, ибо он очень просто решает большинство проблем, код приемственен и ему проще обучить, чем обучать php + шаблонизатор ( в этом случае к знаниям php + чтотоSQL + html + css добавляется необходимость знания шаблонизатора
2) Если требуется MVC, то лучше всего юзать XML + XSL - ибо это по стандарту и ОЧЕНЬ мощно. Со скоростью проблем нет, чтобы там не говорили. Но стоит юзать лишь на PHP >=5 ( изза процессора преобразований, ибо саблотрон это жесть с большой буквы )
3) Если требуется модульность, что бывает в случае, когда у вас мощная CMS и XML-ом вот ну ни как не обойтись ( очень мало вероятно при грамотном подходе и с умением вставлять результат выполнения ф-й на PHP ) то тогда да - шаблонизатор.
Единтсвенно, когда шаблонизатор может быть более оправдан чем XSL преобразование - это в случае ОЧЕНЬ большого и сложного проекта, где обширная CMS и много людей, отвечающих за программинг например, ибо уменее правильно писать на XSL - это достаточно редкий скилл. XSL по своей витиеватости очень похож на регекспы и башка частенько трещит у неподготовленного ( да и у подготовленного тоже ). В этом случае кастомный вариант лучше - ибо он обычно четко структизирован и документирован, и имеет меньше сущностей - т.е. код на нем для данной группы разработчиков будет более легким и лаконичным.
Однако я против "стандартных" тепмлейторов, ибо считаю что под серъезный проект лучше написать "свой" кстомный. Почему? изза лаконичности и заточенности. Всежтаки публичные шаблонизаторы не отличаются лаконичностью, ибо уходят в сторону универсальности. И это правильно ;)
Холивар удался :)
З.Ы. не считаю вопрос шаблонизатора особо важным для PHP-разработчика. Он должен писать так, чтобы его код почти не зависел от того, какой шаблонизатор используется. Важным этот вопрос становится, когда PHP-программер сам пишет шаблоны для себя, вместо дизайнера.
З.Ы. не считаю вопрос шаблонизатора особо важным для PHP-разработчика. Он должен писать так, чтобы его код почти не зависел от того, какой шаблонизатор используется. Важным этот вопрос становится, когда PHP-программер сам пишет шаблоны для себя, вместо дизайнера.
Разделение логики и представления? А чем HTML не логика? Вот CSS — это представление, да.
Видимо здесь собрались разработчики, которые делаю сайт "от и до". Не забывайте, что в команде могут быть еще верстальщики (front-end разработчики), которые вообще могут не знать php и любые другие серверные технологии и их задача работать только с клиентской частью - html, css, js.
Так вот для них шаблоны как раз и предназначены шаблоны! Разработчик серверной части описывает всю логику и выводит окончательные результаты в переменные со своей структурой, а верстальщик уже используя смарти или что-то другое для отображения переменных, которые были получены из серверного скрипта. И верстальщику вовсе не обязательно знать каким образом были получены эти данные и даже не обязательно знать на какой платформе работает сайт! Единственное что ему надо знать, так это структуру переменной, ну и как её визуализировать.
Так вот для них шаблоны как раз и предназначены шаблоны! Разработчик серверной части описывает всю логику и выводит окончательные результаты в переменные со своей структурой, а верстальщик уже используя смарти или что-то другое для отображения переменных, которые были получены из серверного скрипта. И верстальщику вовсе не обязательно знать каким образом были получены эти данные и даже не обязательно знать на какой платформе работает сайт! Единственное что ему надо знать, так это структуру переменной, ну и как её визуализировать.
Sign up to leave a comment.
Шаблонизаторы