Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 138
Круто. На смартиевском форуме радуются :)
www.phpinsider.com/smarty-forum/viewtopic.php?t=14168
www.phpinsider.com/smarty-forum/viewtopic.php?t=14168
Вы написали что-то лучше? Покажите!
К чему сотрясать воздух?
К чему сотрясать воздух?
а так
{html_select_date prefix=«StartDate» time=$time start_year="-5" end_year="+1" display_days=false}
{$articleTitle|escape|nl2br}{$articleTitle}
именно этим кодом и занмаются лишние килобайты. я веру, что твоему заказчику наплевать сколько времени ты потратишь на его проект, но моему — нет.
плюс поддержка значительно улучшается, никому не нужно для правки шаблона лезть в твой шаблонизатор или бизнес логику.
{html_select_date prefix=«StartDate» time=$time start_year="-5" end_year="+1" display_days=false}
{$articleTitle|escape|nl2br}{$articleTitle}
именно этим кодом и занмаются лишние килобайты. я веру, что твоему заказчику наплевать сколько времени ты потратишь на его проект, но моему — нет.
плюс поддержка значительно улучшается, никому не нужно для правки шаблона лезть в твой шаблонизатор или бизнес логику.
В итоге в шаблонах прописывается логика… а это плохо…
Это кто сказал?
Боюсь, Вы неправильно запомнили. Или не до конца поняли. В любом случае, в этом тезисе не хватает одного слова. Всего одного, но крайне важного, из-за которого смысл сильно меняется. Итак, правильный ответ — «в шаблоне не должно быть логики приложения».
А от условностей типа раскраски таблицы «зеброй», как писал классик, вреда никакого, зато пользы — вагон.
А от условностей типа раскраски таблицы «зеброй», как писал классик, вреда никакого, зато пользы — вагон.
Ну да, всё правильно. Логика отображения должна быть в шаблоне.
логика отображения в бизнес логике — это плохо.
>в шаблоне вы просто должны это вывести на экран…
тогда теряется весь смысл view, лучше уж эхо прям в коде делать, тогда при редактировании придётся менять только один файл.
ужасное недопонимание mvc.
>в шаблоне вы просто должны это вывести на экран…
тогда теряется весь смысл view, лучше уж эхо прям в коде делать, тогда при редактировании придётся менять только один файл.
ужасное недопонимание mvc.
Плюс если вместо меня проект будет поддерживать другой программист, ему не нужно будет ломать голову тонкостями доморощенного шаблонизатора.
Вряд ли самописный шаблонизатор будет по документации сравнится со Smarty
Вряд ли самописный шаблонизатор будет по документации сравнится со Smarty
Чудовищно.
Кстати, дабы Вы не питали иллюзий: большая часть классов на phpclasses.org — говнокод. И класс, приведённый Вами выше — не исключение :)
Кстати, дабы Вы не питали иллюзий: большая часть классов на phpclasses.org — говнокод. И класс, приведённый Вами выше — не исключение :)
Мне тоже smarty не интересен. так будте любезны и не засоряйте топик.
а что тебя в 800 кБ смущает?
смарти на многое способен, и возможности должны же где-то реализовываться
если тебе не нравится — не используй, но в минус записывать то, что он весит больше твоего шаблонизатора по меньшей мере некорректно
ноутбук весит гораздо больше калькулятора, но от этого он не хуже
если тебе не нравится — не используй, но в минус записывать то, что он весит больше твоего шаблонизатора по меньшей мере некорректно
ноутбук весит гораздо больше калькулятора, но от этого он не хуже
Большой вес — это очень серьезный недостаток.
Дело в том, что для того, что бы использовать smarty надо сделать его Include, а значит php надо обработать, распарсить и проверить на ошибки 800кб. Что серьезно замедляет работу системы. Есть конечно Zend Optimizer и и разные там EAccelerator-ы, но они используются далеко не повсеместно.
Дело в том, что для того, что бы использовать smarty надо сделать его Include, а значит php надо обработать, распарсить и проверить на ошибки 800кб. Что серьезно замедляет работу системы. Есть конечно Zend Optimizer и и разные там EAccelerator-ы, но они используются далеко не повсеместно.
Zend Framework в распак занимает что-то в районе 50 метров. И ничего, пользуются ;)
Мысль правильно высказал человек под странным ником cccc — habrahabr.ru/blogs/php/42810/#comment_1057645
Вам тоже советую прочитать :)
Вам тоже советую прочитать :)
Потому что пользуются не всеми 50-ю метрами, а только нужными классами.
Со Смарти, поверьте, будет то же самое. Об этом уже писали.
По-моему они уже опоздали. В своё время (около 2-х лет назад) я устал доказывать, что Smarty можно и нужно использовать в проектах. Теперь уже привык к Zend_View, так что особого желания использовать Smarty уже нет.
совместимости со smarty v2 небудет?
Совместимости чего? Интерфейс вроде практически не поменялся. Синтаксис шаблонов, думаю, тоже не претерпел существенных изменений. А плагины, конечно, придётся переписывать. Муторно, конечно, но ничего сложного :)
Вот тут groups.google.com/group/smarty-developers/browse_thread/thread/c29ae569842882cd немного про синтаксис:
PHP: <?= $foo ?>
Smarty: {$foo} // same as Smarty 2
PHP: <?= $foo['bar'] ?>
Smarty: {$foo['bar']} // no more {$foo.bar}
PHP: <?= $foo[$bar][$foo['bar']] ?>
Smarty: {$foo[$bar][$foo['bar']] ?> // identical to PHP
PHP: <?php foreach($foo as $bar) {… } ?>
Smarty: {foreach $foo as $bar}… {/foreach} // just a delimiter
adjustment
PHP: <?php for($x = 0; $x<$y; $x++) {… } ?>
Smarty: {for $x=0; $x<$y; $x++}… {/for} // get rid of {section}
PHP: <?php if($foo == $bar && $blah !== 'ziggy') {… } ?>
Smarty: {if $foo == $bar && $blah !== 'ziggy'}… {/if}
PHP: <?= $foo ?>
Smarty: {$foo} // same as Smarty 2
PHP: <?= $foo['bar'] ?>
Smarty: {$foo['bar']} // no more {$foo.bar}
PHP: <?= $foo[$bar][$foo['bar']] ?>
Smarty: {$foo[$bar][$foo['bar']] ?> // identical to PHP
PHP: <?php foreach($foo as $bar) {… } ?>
Smarty: {foreach $foo as $bar}… {/foreach} // just a delimiter
adjustment
PHP: <?php for($x = 0; $x<$y; $x++) {… } ?>
Smarty: {for $x=0; $x<$y; $x++}… {/for} // get rid of {section}
PHP: <?php if($foo == $bar && $blah !== 'ziggy') {… } ?>
Smarty: {if $foo == $bar && $blah !== 'ziggy'}… {/if}
function php_template($filename, $values) {
extract($values);
ob_start();
include $filename;
$result = ob_get_contents();
ob_end_clean();
return $result;
}
extract($values);
ob_start();
include $filename;
$result = ob_get_contents();
ob_end_clean();
return $result;
}
Да, для домашней странички Васи Пупкина больше и не надо. Но проблема в том, что далеко не все проекты по сложности сравнимы с вышеозначенной страничкой
Говоришь, по сложности…
Неужели что-то, что есть в шаблонизаторе Smarty, не может шаблонизвтор PHP?
Неужели что-то, что есть в шаблонизаторе Smarty, не может шаблонизвтор PHP?
Постановка вопроса аналогична следующему:
Что такого есть в C++ или C# чего не может Ассемблер? ))
Что такого есть в C++ или C# чего не может Ассемблер? ))
Ничего подобного. Я просто предложил ему указать отличия между *шаблонизаторами*.
PHP я имел ввиду именно в роли шаблонизатора. О чем и написал.
PHP я имел ввиду именно в роли шаблонизатора. О чем и написал.
а человек предложил указать различия между *языками программирования*
ассемблер он имел ввиду именно в роли языка программирования :-)
ассемблер он имел ввиду именно в роли языка программирования :-)
Как ЯП, асм имеет кучу отличий от ЯВУ, как минимум отличается уровнем. И для большинства задач нужен именно высокоуровневый ЯП. Поэтому асм плохо подходит.
> Что такого есть в C++ или C# чего не может Ассемблер? ))
Возможность писать высокоуровневый код, абстракция.
А смарти и шаблонизатор пхп не отличаются уровнем, код шаблонов практически идентичен(разница в базовом синтаксисе). Примеры показать?
Разница — синтаксис.
> Что такого есть в C++ или C# чего не может Ассемблер? ))
Возможность писать высокоуровневый код, абстракция.
А смарти и шаблонизатор пхп не отличаются уровнем, код шаблонов практически идентичен(разница в базовом синтаксисе). Примеры показать?
Разница — синтаксис.
Зачем показывать? Очередной раз смотреть на
<?php echo $var ?> vs {$var}? :) Это уже не смешно как-то. Если бы только в этом была идея Смарти, его бы и не использовал никто.<?=$var?> все же.
short tags всегда включить можно. Бесплатные хостинги не рассматриваем.
short tags всегда включить можно. Бесплатные хостинги не рассматриваем.
На всех моих серверах short_open_tags всегда выключены. Принципиально.
Но не о том речь. Смотреть на спор про
Но не о том речь. Смотреть на спор про
{} и <? ?> уже поднадоело. Я в соседнем треде отписался, ознакомьтесь, если хотите.На многих серверах и system отключены, и сокетов нет… Не будешь же ты такие сервера ставить?
> Принципиально.
Принципиальные админы у моих заказчиков либо поступаются принципами, либо ищут новое место работы ;)
> Принципиально.
Принципиальные админы у моих заказчиков либо поступаются принципами, либо ищут новое место работы ;)
Суровые у Вас заказчики :)
Просто реалисты — зачем им потокать необоснованным принципам, когда эти принципы идут им во вред(снижают читабельность шаблона)?
А про system — то работать видео в пхп можно только через него. Но на большинства шаред-хостингах он запрещен. По такой ллогике работать с видео — «это фу».
А про system — то работать видео в пхп можно только через него. Но на большинства шаред-хостингах он запрещен. По такой ллогике работать с видео — «это фу».
Со Смарти, напомню, таких проблем не возникло бы :)
А насчёт читабельности pure-шаблонов я свою точку зрения высказывал, повторяться неохота :)
Лично у нас исключительно собственные сервера, и там system не запрещён ;)
А видео в PHP можно ворочать и без system. Например, есть расширение ffmpeg. А некоторые операции типа определения продолжительности видеоролика могут делаться обычным чтением потока :)
А насчёт читабельности pure-шаблонов я свою точку зрения высказывал, повторяться неохота :)
А про system — то работать видео в пхп можно только через него. Но на большинства шаред-хостингах он запрещен. По такой ллогике работать с видео — «это фу».
Лично у нас исключительно собственные сервера, и там system не запрещён ;)
А видео в PHP можно ворочать и без system. Например, есть расширение ffmpeg. А некоторые операции типа определения продолжительности видеоролика могут делаться обычным чтением потока :)
А register_globals с magic_quotes_gpc вы тоже используете?
short_open_tags с asp_tags такой-же оттавизм, как и вышестоящие директивы.
short_open_tags с asp_tags такой-же оттавизм, как и вышестоящие директивы.
Шаблонизатор PHP и шаблонизатор Smarty по сути просто разные уровни абстрации.
Кому то может удобно и на Ассемблере программы писать, а кому-то быстрее и удобнее на языке более высокого уровня в нормальной IDE.
Кому то может удобно и на Ассемблере программы писать, а кому-то быстрее и удобнее на языке более высокого уровня в нормальной IDE.
Выше уже сказали, что смарти реально жрет не 800кб, а около 34. Да и вообще я бы не стал считать смарти отдельным уровнем, т. к. по сути типичный запуск смарти состоит из инклюда php-файла в который скомпилирован шаблон (если его нет, тогда он компилируется, но это редко и не в счет). А теперь давайте подумаем, что быстрее заинклюдить php-файл или в своем простеньком шаблонизаторе распарсить синтаксис при помощи str_replace (или, упаси боже, preg_replace) в реальном времени?
И почему разный? Мне самому интересно, почему)
Просто ничуть не сложнее его юзать — различие небольшие в синтаксисе управляющих конструкций, да вместо { } писать <?= ?>.
Еще раз: я про шаблонизатор PHP, а не ЯП PHP.
Просто ничуть не сложнее его юзать — различие небольшие в синтаксисе управляющих конструкций, да вместо { } писать <?= ?>.
Еще раз: я про шаблонизатор PHP, а не ЯП PHP.
Позвольте позанудствовать:
ru2.php.net/language.basic-syntaxСледует избегать использования коротких тегов при разработке приложений или библиотек, предназначенных для распространения или размещения на PHP-серверах, не находящихся под вашим контролем, так как короткие теги могут не поддерживаться на целевом сервере. Для создания переносимого, совместимого кода, не используйте короткие теги.
Хм… коммент отправился недописанным. Просто получается, что вместо пары фигурных скобок в обычном случае следует писать
<?php echo ... ?>, что иногда при большом количестве переменных надоедает :)
Сервер находится под контролем человека, разворачивающего там приложение.
Конечно, если это не фри хостинг, но мои скрипты на них не будут исполняться никогда.
Конечно, если это не фри хостинг, но мои скрипты на них не будут исполняться никогда.
1 — интерфейс смарти проще воспринимается, дизайнеры не роются в коде как таковом
2 — избавляемся от лишних тегов, заменяемых фигурными скобками
3 — на скорость выполнения практически не влияет (всеравно на выходе пхп код получается)
хотябы эти 3 пункта достойны того чтоб взглянуть в его сторону
пхп шаблонизатор бесспорно мощней, но я не хочу сорить в хтмл-е кодом пхп, а бывают ситуации когда и в шаблон много логики попадает
2 — избавляемся от лишних тегов, заменяемых фигурными скобками
3 — на скорость выполнения практически не влияет (всеравно на выходе пхп код получается)
хотябы эти 3 пункта достойны того чтоб взглянуть в его сторону
пхп шаблонизатор бесспорно мощней, но я не хочу сорить в хтмл-е кодом пхп, а бывают ситуации когда и в шаблон много логики попадает
1. И в шаблонизаторе PHP они нен роются в коде. В шаблонизаторе потому что НЕТ кода. В нем может быть максимум логика отображения.
2. А чем хуже <? ?> чем {}? Религия <? ?> не позволяет юзать?
3. Допустим. Но я что-то говорил про скорость?)
> но я не хочу сорить в хтмл-е кодом пхп
А хочешь сорить «кодом» смарти? ) У них код одного и того же уровня. У шаблонизаторов.
2. А чем хуже <? ?> чем {}? Религия <? ?> не позволяет юзать?
3. Допустим. Но я что-то говорил про скорость?)
> но я не хочу сорить в хтмл-е кодом пхп
А хочешь сорить «кодом» смарти? ) У них код одного и того же уровня. У шаблонизаторов.
Ну вот опять опять эти чёртовы скобочки… Неужели никто дальше их просто не смотрит?
Давайте расширим кругозор. Вот задачка, которая в той или иной вариации встречается в любом проекте: произвольную строку пропустить через несколько фильров:
Как эта задача будет выглядеть на чистом пхп? Примерно вот так:
Не запарились считать скобочки в правой части выражения? Я вот запарился, пока набирал. Ещё и не уверен, что набрал правильно. Следующий аспект — фильты приходится располагать в обратном порядке. Вам удобно читать подобную арабскую вязь? Лично мне — нет.
Смотрим на синтаксис Смарти:
Здесь фильтры идут в том порядке, в котором надо их применять. Никаких прилипающих друг ко другу скобочек нет и в помине. И что немаловажно, разработчики, знакомые с *bix (хотя почему только с *nix? На винде нечто подобное есть), заметят аналог с консолью и потоками.
Это лишь один из примеров синтаксического сахара.
P.S. никто, надеюсь, не будет спорить, что это именно логика отображения?
Давайте расширим кругозор. Вот задачка, которая в той или иной вариации встречается в любом проекте: произвольную строку пропустить через несколько фильров:
strtolower(), strip_tags(), trim(), nl2br() и некую абстрактную hilight_url(), которая делает сами понимаете чего.Как эта задача будет выглядеть на чистом пхп? Примерно вот так:
<?php echo highlight_url(nl2br(trim(strip_tags(strtolower($var))))); ?>Не запарились считать скобочки в правой части выражения? Я вот запарился, пока набирал. Ещё и не уверен, что набрал правильно. Следующий аспект — фильты приходится располагать в обратном порядке. Вам удобно читать подобную арабскую вязь? Лично мне — нет.
Смотрим на синтаксис Смарти:
{$var | strlower | strip_tags | trim | nl2br | hilite_url }Здесь фильтры идут в том порядке, в котором надо их применять. Никаких прилипающих друг ко другу скобочек нет и в помине. И что немаловажно, разработчики, знакомые с *bix (хотя почему только с *nix? На винде нечто подобное есть), заметят аналог с консолью и потоками.
Это лишь один из примеров синтаксического сахара.
P.S. никто, надеюсь, не будет спорить, что это именно логика отображения?
Исправление:
Конечно же, не hilite_url, а hilight_url:
Опечатался впопыхах :)
И дополнение: я умышленно использовал в качестве фильтров имена строковых функций PHP. Можно было бы комбинировать предопределённые плагины-модификаторы, тогда результат был бы ещё короче.
Конечно же, не hilite_url, а hilight_url:
{$var | strlower | strip_tags | trim | nl2br | hilight_url }Опечатался впопыхах :)
И дополнение: я умышленно использовал в качестве фильтров имена строковых функций PHP. Можно было бы комбинировать предопределённые плагины-модификаторы, тогда результат был бы ещё короче.
Как сказать, а по мне это логика приложения. По одной простой причине — поменяйте шаблонизатор на другой и вам придётся переписать не только шаблоны, но и всю эту логику отображения. В случае простого вывода уже готовых данных из уровня приложения ваш шаблон примет вид
{$arr['baz']} что заменой с регулярным выражением преобразовывается почти в любой другой формат на автомате, остаётся только проконтролировать и подправить отдельные места.
Я уже не говорю о вёрстке на XLST и. т. д. Нужно быть гибким и понимать, что при смене работы не факт, что придётся использовать Smarty.
Да и к тому же, если у вас один модуль выводит данные как на страницу, так и в RSS? Или экспортирует данные в какой-то другой формат? Вы заколебётесь в каждом из шаблонов следить за тем, что у вас данные были правильно и идентично обработаны — рано или поздно кто-нить допустит ошибку (теория вероятности, ага. Так же законы Мерфи.), что может вылиться в очень серьёзные последствия.
К тому же, извините меня, но кому кому, а дизайнеру смотреть на эти конструкции типа {$var | strlower | strip_tags | trim | nl2br | hilite_url } абсолютно не прикольно. Даже мне, программисту, смотреть на это абсолютно в падлу в большом шаблоне, потому что оно путается, сливается, принимает вид двух этажных конструкций, вводит кучу дополнительных переменных (привет memory usage! Никогда не сталкивались с ошибкой Memory limit? Какой нить умник впихнёт кучу данных в переменную на мегабайт, потом это всё копируется движком smarty и получиться уже не 1, а 2-3 мегабайта).
Именно из-за таких подходов к программированию большинство PHP программистов не получают выше средней планки. Они не умеют думать о том, что железка тоже стоит денег, что элементарные знания по специальностям компьютерных наук могут очень сильно помочь, что приходит понимания работы многих механизмов самого PHP (частенько даже визуально хороший код страдает от того, что либо человек без образования IT, либо спал на лекциях). Что упрощая приложение путём отказа от некоторых вещей, 100% на ура заменяемых другими, более лёгкими и переход на которые ограничивает только собственная упёртость и религия, можно отказаться от пары дополнительных серверов. Что подключение дополнительных файлов тоже тормозит и может приводить к весьма сильным тормозам (кто читает Internals, тот знает к чему может приводить через меру раздутый или вообще не установленный include path и неправильное использование относительных путей, о чём многие даже не подозревают. hint: 30% разница в общей скорости обработки, дальше ищите сами, хотя сомневаюсь что большинство это хоть как-то забеспокоит).
Хороших программистов мало, настоящих программистов и того меньше.
{$arr['baz']} что заменой с регулярным выражением преобразовывается почти в любой другой формат на автомате, остаётся только проконтролировать и подправить отдельные места.
Я уже не говорю о вёрстке на XLST и. т. д. Нужно быть гибким и понимать, что при смене работы не факт, что придётся использовать Smarty.
Да и к тому же, если у вас один модуль выводит данные как на страницу, так и в RSS? Или экспортирует данные в какой-то другой формат? Вы заколебётесь в каждом из шаблонов следить за тем, что у вас данные были правильно и идентично обработаны — рано или поздно кто-нить допустит ошибку (теория вероятности, ага. Так же законы Мерфи.), что может вылиться в очень серьёзные последствия.
К тому же, извините меня, но кому кому, а дизайнеру смотреть на эти конструкции типа {$var | strlower | strip_tags | trim | nl2br | hilite_url } абсолютно не прикольно. Даже мне, программисту, смотреть на это абсолютно в падлу в большом шаблоне, потому что оно путается, сливается, принимает вид двух этажных конструкций, вводит кучу дополнительных переменных (привет memory usage! Никогда не сталкивались с ошибкой Memory limit? Какой нить умник впихнёт кучу данных в переменную на мегабайт, потом это всё копируется движком smarty и получиться уже не 1, а 2-3 мегабайта).
Именно из-за таких подходов к программированию большинство PHP программистов не получают выше средней планки. Они не умеют думать о том, что железка тоже стоит денег, что элементарные знания по специальностям компьютерных наук могут очень сильно помочь, что приходит понимания работы многих механизмов самого PHP (частенько даже визуально хороший код страдает от того, что либо человек без образования IT, либо спал на лекциях). Что упрощая приложение путём отказа от некоторых вещей, 100% на ура заменяемых другими, более лёгкими и переход на которые ограничивает только собственная упёртость и религия, можно отказаться от пары дополнительных серверов. Что подключение дополнительных файлов тоже тормозит и может приводить к весьма сильным тормозам (кто читает Internals, тот знает к чему может приводить через меру раздутый или вообще не установленный include path и неправильное использование относительных путей, о чём многие даже не подозревают. hint: 30% разница в общей скорости обработки, дальше ищите сами, хотя сомневаюсь что большинство это хоть как-то забеспокоит).
Хороших программистов мало, настоящих программистов и того меньше.
{$var | strlower | strip_tags | trim | nl2br | hilite_url } можно заменить на {$var | my_modifier }.
Рендерить RSS или любой другой формат так же можно на Smarty без проблем (я не говорю, что нужно, я говорю что можно!).
В архитектуре MVC отображение отделено от логики приложения специально, чтобы можно было в одном случае показать так, в другом — иначе. Если вы сделаете $var = htmlspecialchars($var); в контроллере (или не дай бох в модели) и передадите в шаблон уже сконвертированное значение, то при необходимости конвертирвоать его иначе для вывода (например, urlencode($var)) руки у вас уже будут связаны. Резюме: все обработки значений, которые нужны только для отображения, должны быть в отображении, т. е. в шаблоне (при этом не важно, шаблон это Smarty или php-файл).
Рендерить RSS или любой другой формат так же можно на Smarty без проблем (я не говорю, что нужно, я говорю что можно!).
В архитектуре MVC отображение отделено от логики приложения специально, чтобы можно было в одном случае показать так, в другом — иначе. Если вы сделаете $var = htmlspecialchars($var); в контроллере (или не дай бох в модели) и передадите в шаблон уже сконвертированное значение, то при необходимости конвертирвоать его иначе для вывода (например, urlencode($var)) руки у вас уже будут связаны. Резюме: все обработки значений, которые нужны только для отображения, должны быть в отображении, т. е. в шаблоне (при этом не важно, шаблон это Smarty или php-файл).
Как сказать, а по мне это логика приложения. По одной простой причине — поменяйте шаблонизатор на другой и вам придётся переписать не только шаблоны, но и всю эту логику отображения.
Оставлю без комментариев, пожалуй :)
Да и к тому же, если у вас один модуль выводит данные как на страницу, так и в RSS? Или экспортирует данные в какой-то другой формат?
Эту логику должен решать слой View. Но шаблонизатор, как правило, представляет собой не View, а лишь одну из его составляющих, которая генерирует исключительно HTML. Но ведь бывают и грамотные подходы ;)
К тому же, извините меня, но кому кому, а дизайнеру смотреть на эти конструкции типа {$var | strlower | strip_tags | trim | nl2br | hilite_url } абсолютно не прикольно...
Думаете, дизайнеру (хотя Вы, наверное, имели в виду верстальщика) намного прикольнее смотреть на
<?php echo highlight_url(nl2br(trim(strip_tags(strtolower($var))))); ?>? :)(привет memory usage! Никогда не сталкивались с ошибкой Memory limit? Какой нить умник впихнёт кучу данных в переменную на мегабайт, потом это всё копируется движком smarty и получиться уже не 1, а 2-3 мегабайта).
Не вижу логики. Если в переменную Смарти загнать 1Мб, то почему нельзя этого сделать на шаблонизаторе, который использует чистый пхп? В нём что, нет средств для присваивания переменной? :)
И откуда, кстати, такие цифры о Смарти (я про 2-3 мегабайта)?
Тираду насчёт никчёмности программистов комментировать тоже не буду, оставлю на Вашей совести. Лишь пожелаю для общего развития поучаствовать в командной разработке сложного проекта :)
Думаете, дизайнеру (хотя Вы, наверное, имели в виду верстальщика) намного прикольнее смотреть на <?php echo highlight_url(nl2br(trim(strip_tags(strtolower($var))))); ?>? :)
Всё что он увидит, это
<?php echo get('var')?>, а то и просто <?=get('var')?>
Не вижу логики. Если в переменную Смарти загнать 1Мб, то почему нельзя этого сделать на шаблонизаторе, который использует чистый пхп? В нём что, нет средств для присваивания переменной? :)
В шаблоне с native php вы никогда не сделаете так:
<? $items = get('items');
foreach ($items as $key => $val) { ?>
…
<?}?>
Именно так поступает Smarty, я же пишу так:
<? foreach (get('items') as $key => $val) {?>
…
<?}?>
Цифра взята для примера, просто илюстрация как разрастается кол-во используемой памяти.
Вот откуда такая манера — если оппонент исповедует другой подход, значит он тупой, никогда не работал в комманде, и вообще страдает фигнёй?
1). Мой рабочий стаж составляет более 5 лет, у меня среднее специальное образование по специальности «Программист-техник» и третий курс (из 4) ВУЗа бакалавра кафедры компьюторных наук. Всю жизнь интересовался комьпюторами. Я читаю PHP Internal list и довольно сносно разбираюсь как работает PHP из нутри, в перспективе собираюсь писать вещи на уровне C для PHP. Я хорошо знаю MySQL и работал с MySQL NDB Cluster. Имею достаточно большой опыт в создании больших и сильно нагруженных проектов, некоторые из которых прекрасно работают силами одного нормального сервера.
2). Я практически никогда не работал в одиночку. Мне так же посчасливилось из-за знакомств попадать на работу в конторы, где работали люди с уровнем и опытом превосходящим наш как минимум на десяток лет (самый матёрый был коллега с опытом в PHP с момента его создания, C/C++ под *nix и немного Win32, Java и прочей мелочёвкой, с общим опытом программтирования более 15 лет — уж в чъей репутации и мнении я не сомневаюсь, так это в его. И он никогда не отметал идеи и подходы на корню. А если я и ошибался, то всегда хорошо аргуентировал и разъяснял почему я не прав).
2а). Последние 3 года я работаю в коммандах с кол-вом людей 5+.
в пхп 6, на сколько я слышал, откажутся от <? ?> и от <?= ?>
Покажи свою реализацию призон?)
А кеш… ну впринципе в шаблон его подключить — хорошая идея, я его просто вне шаблона юзал)
А кеш… ну впринципе в шаблон его подключить — хорошая идея, я его просто вне шаблона юзал)
Покажи свою реализацию призон?)
А кеш… ну впринципе в шаблон его подключить — хорошая идея, я его просто вне шаблона юзал)
А кеш… ну впринципе в шаблон его подключить — хорошая идея, я его просто вне шаблона юзал)
Покажи свою реализацию призон?)
А кеш… ну впринципе в шаблон его подключить — хорошая идея, я его просто вне шаблона юзал)
А кеш… ну впринципе в шаблон его подключить — хорошая идея, я его просто вне шаблона юзал)
нер, ты в асе молчишь, поэтому тут напишу. EXTR_SKIP не забыл? дыра или убейте меня кто-нибудь..? ;)
Smarty провоцирует на логику в шаблонах. Количество минусов и плюсов к этому замечанию будет походу отражать. По мне так некузяво это, если есть логическая ошибка — то и искать её стоить в контроллере, а не в шаблоне, зачем две точки отказа? В два раза больше охота программить?
тьфу, дебажить.
бывают моменты когда проще вынести кусочек логики в шаблон
Ну так за это по яйцам надо бить, потому, что заставляешь тех, кто после тебя вкалывать вдвое.
Лучший компромисс, вместо этой игрушечной smarty — это строгий шаблон, который тебе ещё и error даёт если, что не так (Blitz Templates),
логика — ну ладно, ок, на уровне if, да и то хз. Если с нуля, из-за этого if приходится лезть в переменные контроллера. А так — мило дело, переколбасил шаблон на первоклашечном уровне и ок, фсё супер даже через полгода поддержки, даже не вспотел.
Лучший компромисс, вместо этой игрушечной smarty — это строгий шаблон, который тебе ещё и error даёт если, что не так (Blitz Templates),
логика — ну ладно, ок, на уровне if, да и то хз. Если с нуля, из-за этого if приходится лезть в переменные контроллера. А так — мило дело, переколбасил шаблон на первоклашечном уровне и ок, фсё супер даже через полгода поддержки, даже не вспотел.
а почему почему логики не должно быть в шаблонах? логика отображения обязана присутствовать в шаблонах.
допустим обычный вывод комментария для правки вверху как он выглядел, а внизу поле для правки
или ы предлогаете дублироать данные на все случаи в бизнес логике?
допустим обычный вывод комментария для правки вверху как он выглядел, а внизу поле для правки
или ы предлогаете дублироать данные на все случаи в бизнес логике?
У Smarty есть сильные стороны в виде плагинов, просто это запутано.
Я предлагаю (вернее не предлагаю, это старая тема) контроллер, который принял темплейт и крутит им как хочет. Да и на Хабре так, но это дело десятое, я хз как они это понимают.
Я не очень понял по поводу обычного вывода комментария, ну он так и будет обычно выведен.
Только упрощенно, например,
{{ BEGIN comment }}
{{$comment_date}} {{$comment_name}}…
{{ END comment }}
А если движок подразумевает собой множество тем (дубликаты темплейтов с их логикой?) Яркий пример — это полностью пизданутый shop-script. В каждой из них таскать умные штуки? Можно сделать проще и быстрее. Не, тут каждый, кто во что горазд, но мне как-то неохота. И ещё раз повторю — если у меня ошибка — то я точно знаю где она. Модуль такой-то, строка такая-то и точка — иду в такой-то модуль и не думаю о шаблоне вообще, в шаблоне я если скобки не закрыл, то он ругнётся полным остановом. Бывают ошибки вроде перепутал имена переменных, но очень редко.
Я думал о том, что это устаревший подход, но неоднократно убеждался в обратном. Хотя это если философски от подхода зависит. Smarty way — это целая местечковая наука. Но reusability code я предпочту делать не плагинами smarty, а местными решениями — модуль+его шаблон. А хз — что они там наделают, своя льняная рубаха ближе к телу.
Я предлагаю (вернее не предлагаю, это старая тема) контроллер, который принял темплейт и крутит им как хочет. Да и на Хабре так, но это дело десятое, я хз как они это понимают.
Я не очень понял по поводу обычного вывода комментария, ну он так и будет обычно выведен.
Только упрощенно, например,
{{ BEGIN comment }}
{{$comment_date}} {{$comment_name}}…
{{ END comment }}
А если движок подразумевает собой множество тем (дубликаты темплейтов с их логикой?) Яркий пример — это полностью пизданутый shop-script. В каждой из них таскать умные штуки? Можно сделать проще и быстрее. Не, тут каждый, кто во что горазд, но мне как-то неохота. И ещё раз повторю — если у меня ошибка — то я точно знаю где она. Модуль такой-то, строка такая-то и точка — иду в такой-то модуль и не думаю о шаблоне вообще, в шаблоне я если скобки не закрыл, то он ругнётся полным остановом. Бывают ошибки вроде перепутал имена переменных, но очень редко.
Я думал о том, что это устаревший подход, но неоднократно убеждался в обратном. Хотя это если философски от подхода зависит. Smarty way — это целая местечковая наука. Но reusability code я предпочту делать не плагинами smarty, а местными решениями — модуль+его шаблон. А хз — что они там наделают, своя льняная рубаха ближе к телу.
ой, хабр съел мой код
там пример, когда в div выводится переменная, nl2br($comment), а в textarea просто $comment.
либо ещё пример с меню, когда мне достаточно выплюнуть многомерный массив, а дизайнер сам решает как его отобразить, выводить ли все субменю или только субменю активного пункта и т. д. и т. п. зачем генерить десяток менюх и десяток шаблонов, если достаточно десятка шаблонов и одного метода генерации, пускай даже иногда избыточного.
там пример, когда в div выводится переменная, nl2br($comment), а в textarea просто $comment.
либо ещё пример с меню, когда мне достаточно выплюнуть многомерный массив, а дизайнер сам решает как его отобразить, выводить ли все субменю или только субменю активного пункта и т. д. и т. п. зачем генерить десяток менюх и десяток шаблонов, если достаточно десятка шаблонов и одного метода генерации, пускай даже иногда избыточного.
Я не очень уверен в эффективности многомерных массивов по их отображению на шаблон. Какбе сомневаюсь по поводу работы дизайнера в этом вопросе. Он может очень продвинут? Тогда другой вопрос.
Десигнер может классами css решать, или на крайняк, если уж так пошло, отдать ему пару функций или классов в виде callback из template
типа как в bitrix, Application::showmenu(«a», «b»), но строго определённых. Это справедливое замечание, я бы плюс поставил, тока не хватает бонусов, меня за агрессивную подачу материала постоянно минусуют, вот исправляюсь, но всё равно в минусе=)
Просто bitrix way мне кажется менее безопасен, но более хостингонезависим.
Отдавать десигнеру как решению строго документированные вещи — типа Visual::ShowMenu(params....), такие штуки правда бывают нужны, поймали. В Blitz Templates, которые я пропагандирую, это тривиально, определил свой callback и дело в шляпе. (За рекламу надо мне бонус!)))))
Десигнер может классами css решать, или на крайняк, если уж так пошло, отдать ему пару функций или классов в виде callback из template
типа как в bitrix, Application::showmenu(«a», «b»), но строго определённых. Это справедливое замечание, я бы плюс поставил, тока не хватает бонусов, меня за агрессивную подачу материала постоянно минусуют, вот исправляюсь, но всё равно в минусе=)
Просто bitrix way мне кажется менее безопасен, но более хостингонезависим.
Отдавать десигнеру как решению строго документированные вещи — типа Visual::ShowMenu(params....), такие штуки правда бывают нужны, поймали. В Blitz Templates, которые я пропагандирую, это тривиально, определил свой callback и дело в шляпе. (За рекламу надо мне бонус!)))))
Есть ещё другой путь — xml:xslt трансформация, очень часто оно подается как стандарт, враки. Для Яндекса оно может и хорошо, когда полная стандартизация нужна, набрать кучу людей, которые его только верстают, платят им за это, у них в принципе, xml на выходе, но в итоге это встанет просто тупо дороже, это для золотонебесных людей. Это лучше всего на самом деле, просто я не люблю. Отдаёшь всегда xml strict document, а как его там завернут уже — это проблема верстальшиков. В pda или куда там ещё, но это не для меня, как для разработчика и верстака в одном, допускающего ляпы в валидной верстке, но зато я «дофига клепаю для себя и хер на них всех клал» Тут уж кто во что горазд. Мне нужны бабки, а не понты.
Давайте ещё поясню — начнут увольнять людей из Яндекса того же (ну кто-то сверху пукнул, у меня так на ТВ-6 было когда-то), где это стандарт и верстаки на вес золота, хотя платят им копейки. Ну и куда они пойдут, они же не универсальны нифига, это какбе не верстаки в общем получаются, а плотники супротив столяра. Не знаю, доходчиво ли я пояснил, хотя этих плотников всегда не хватает — но они слегонца туповаты, вернее они умные, но зануды.
в xsl есть куча логики, там и if, for, while и инклуды и возможность вставки php ;).
правда, я предпочитаю exslt, там ещё больше _логики_ _отображения_
я php программист и для меня главное выплюнуть данные на отображение, а там пускай верстальщик разбирается, либо я через месяц-другой. кстати, {debug} суперфича для вёрстки, а которой забывают в самопалах.
правда, я предпочитаю exslt, там ещё больше _логики_ _отображения_
я php программист и для меня главное выплюнуть данные на отображение, а там пускай верстальщик разбирается, либо я через месяц-другой. кстати, {debug} суперфича для вёрстки, а которой забывают в самопалах.
Ребята=) Мы тут в 5 утра сидим! Это хардкор=)
Да, про {debug} забыл, но немного другое пользую — xdebug с профайлингом + переопределение DevErrorHandler, наверное это по старпёрски.
Да, про {debug} забыл, но немного другое пользую — xdebug с профайлингом + переопределение DevErrorHandler, наверное это по старпёрски.
>Ребята=) Мы тут в 5 утра сидим! Это хардкор=)
тяжела и неказиста жизнь простого программиста
тяжела и неказиста жизнь простого программиста
Я кино смотрю (Облако-Рай), к счастью не работаю ни на кого, всех в сраку! в сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув сракув баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе баблосебе
Ну то есть если по-простому это какбе диверсификация, строишь дорогу, чтобы по ней ездили, а не расставляли железные кругляши, а светофоры отдай людям.
А я думал, что проект заглох. Его даже с php.net убрали.
Очень рад, что вышла новая версия, избавившаяся от недостатков Smarty2.
По поводу Zend_View — не все используют Zend Framework. А конкуренция — это всегда хорошо.
Очень рад, что вышла новая версия, избавившаяся от недостатков Smarty2.
По поводу Zend_View — не все используют Zend Framework. А конкуренция — это всегда хорошо.
дождёмся stable версии, сильно надеюсь на <800 кб кода :)
исправьте пожалуйста в тексте 'лицензии «GP»' на «LGPL»
Молодцы, не ожидал.
Несколько проектов на smarty, попробую теперь и новую версию.
Несколько проектов на smarty, попробую теперь и новую версию.
А что есть «нативные PHP шаблоны»?
Smarty не люблю юзаю свой мега простой класс для шабов, но очень часто встречаеться в чужих проэктах поэтому рад 3 ветке на 5ке
Интересно, что за мания пихать ООП там, где он не нужен? Ну переписали под php>5 с ООП — ладно, дело хозяйское(и в принципе правильное). Но плагины нафига в классы? Что такого они могут в отдельном классе чего не могли раньше в зареганой функции? Что б переписать свои плагины под ООП и восторгаться — не хухры- мухры а классы!?!? ИМХО, фанатизм излишний
Для того, чтобы загнать разработчика плагина в какие-то рамки (чтобы он играл «по правилам»). Для этого используются интерфейсы и абстрактные классы. А то начинается написание супер-мега плагинов размером больше самого Смарти, умеющих отображать данные, варить кофе и звонить по телефону.
Плагины перевести на классы стоило хотя бы из-за ленивой загрузки :)
А что касается «где не нужен»… А почему не нужен, собственно? Старый подход с именованием плагинов по сути являлся интерфейсом :) Почему бы не сделать то же самое, но полагаться уже не на разработчика (человеческий фактор, знаете ли, можно что-то забыть), а на сам язык? :)
А что касается «где не нужен»… А почему не нужен, собственно? Старый подход с именованием плагинов по сути являлся интерфейсом :) Почему бы не сделать то же самое, но полагаться уже не на разработчика (человеческий фактор, знаете ли, можно что-то забыть), а на сам язык? :)
а вы случайно иногда не восклицаете «наплодили тут классов»?
«Все требуемые элементы, исключённые из ядра, подгружаются лишь по мере необходимости (lazy loading)» — вот это хорошо =)
А по поводу размера, так тож плагины и прочие приблуды, которые лежат себе спокойно на диске, пока их не трогают, главное чтобы память и проц не отжирал сильно.
А по поводу размера, так тож плагины и прочие приблуды, которые лежат себе спокойно на диске, пока их не трогают, главное чтобы память и проц не отжирал сильно.
ха, только что сделал checkout куча ошибок и ничего не палит, надеюсь временно, а то я задолбался безрезультатно копаться в регулярках, чтобы сделать поддержку разыменования.
cool, будем тестить…
В сравнении с предшественницей в простейшем применении отьедает оперативной памяти на 300 кб больше. Надо будет проверить разницу в показателях на каком-нибудь нетривиальном шаблоне.
По времени же потери совершенно незначительные.
Сугубо субьективно, разумеется )
По времени же потери совершенно незначительные.
Сугубо субьективно, разумеется )
спасибо за обзор. теперь все ждём официальную документацию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел alpha-релиз Smarty 3