Комментарии 76
Как сторонник XSLT, стою в сторонке и не вмешиваюсь ))
сторонник php_templates / blitz стоит в сторонке и курит. в его голове крутится мысль о том, что главное чтобы разработчику было удобно и проект работал как положено, а blitz он использует или смарти не так уж и важно :)
НЛО прилетело и опубликовало эту надпись здесь
… в производительность XSLT.
Потому что разделение логики с отображением — подразумевается. А чистота и ясность — прилагаются.
Потому что разделение логики с отображением — подразумевается. А чистота и ясность — прилагаются.
2) Как стороник XSLT, XSLT максимально позволяет выполнить требование:
Нужно разделить бизнес-логику и логику представления
Так как, ему даже не важно на чом написали бизнес-логику Будь-то PHP, ASP или любой другой язык…
Нужно разделить бизнес-логику и логику представления
Так как, ему даже не важно на чом написали бизнес-логику Будь-то PHP, ASP или любой другой язык…
Подвиньтесь, стану рядом :)
А то народу много, а сторонка маленькая.
А то народу много, а сторонка маленькая.
Присоединяюсь. XSLT — наше всё!
Как практикующий сторонник XSLT сказал бы, но воздержусь ибо сторонка вроде не вмешивается… она просто стоит и работает ;)
по XSLT вы бы собрались да с примерами все рассказали б в виде статьи
Я бы, с удовольствием, но, к сожелению, здесь опубликовать не могу из-за кармы — люблю поспорить ;)
Может быть я какнидь опубликую статейку в блоге и выложу сюда ссылку, я думаю кол-во приверженцев возрастет в разы :)
Вообще XSLT обаладет инетересной чертой — стоит пглядеть на него — как какжется что он какой-то «угловатый» и ограниченный, но стоит его попробовать на реальном проекте, попробывать всю мощь XPath и осей — как бесконечно в него влюбляешься. Есть у него главная черта, которой очень мало в других языках ( не в обиду будет никому сказано ) — это его лаконичность.
Вот люблю я лаконичные языки вроде регспов и xslt, хотя иногда конечно эта лаконичность заставляет понапрягать мозг — ну дак так даже интереснее, тем более что всеж таки большинство шаттных проблем решаются вполне без напрягов, да и большинство шаблонизаторов поддерживают вызов процедур внешнего языка, если уж вообще никак.
Может быть я какнидь опубликую статейку в блоге и выложу сюда ссылку, я думаю кол-во приверженцев возрастет в разы :)
Вообще XSLT обаладет инетересной чертой — стоит пглядеть на него — как какжется что он какой-то «угловатый» и ограниченный, но стоит его попробовать на реальном проекте, попробывать всю мощь XPath и осей — как бесконечно в него влюбляешься. Есть у него главная черта, которой очень мало в других языках ( не в обиду будет никому сказано ) — это его лаконичность.
Вот люблю я лаконичные языки вроде регспов и xslt, хотя иногда конечно эта лаконичность заставляет понапрягать мозг — ну дак так даже интереснее, тем более что всеж таки большинство шаттных проблем решаются вполне без напрягов, да и большинство шаблонизаторов поддерживают вызов процедур внешнего языка, если уж вообще никак.
Есть отличный ресурс www.zvon.org/xxl/XSLTutorial/Output/
А вот отличный перевод www.raleigh.ru/XML/XSLTutorial/contents.htm
Зачем копипаст?
Хотя если кого-то интересует могу про основы написать.
А вот отличный перевод www.raleigh.ru/XML/XSLTutorial/contents.htm
Зачем копипаст?
Хотя если кого-то интересует могу про основы написать.
НЛО прилетело и опубликовало эту надпись здесь
В Споре рождается истина. Зря тему закрыли ^_^
НЛО прилетело и опубликовало эту надпись здесь
по 5-му пункту вы высказались весьма безосновательно
много резких слов, и ни одного факта
много резких слов, и ни одного факта
НЛО прилетело и опубликовало эту надпись здесь
Чесно говоря не вижу проблем никаких. Лично я использую symfony и нативные шаблоны. У меня полное управление кешированием и все что мне нужно. Верстальщик разобрался с шаблонным синтаксисом за пару минут.
вы наверное не поняли: тут изложены причины споров, а вот отстаивать свою точку зрения я предлагаю вам тут: HolyWar: Шаблонизаторы. Нужны ли они? состоятельны ли они? Форум.
Цель всего этого показать, что люди всегда спорят, минусуют, вместо того чтоб просто оценить инструментарий в контексте ЕГО использования.
Цель всего этого показать, что люди всегда спорят, минусуют, вместо того чтоб просто оценить инструментарий в контексте ЕГО использования.
НЛО прилетело и опубликовало эту надпись здесь
вот вы в топике HolyWar: Шаблонизаторы. Нужны ли они? состоятельны ли они? Форум. задайте вопрос — я вам отвечу как решать эти проблемы.
Между прочим, цепочки вызовов методов не есть хорошо в отображении. Как решение, лучше будет создать класс например productOrder и добавить туда необходимые для отображения методы: {$productOrder->getUserFirstName()}
из mzz
* Smarty_Compiler.class.php:
метод Smarty_Compiler::_parse_attrs(), строки 1577-1579:
if (i18n::isName($trimmed = trim($token, '"'))) {
$token = '"'. smarty_prefilter_i18n('{'. $trimmed. '}', $smarty). '"';
}
строки 163-164:
$this->_obj_start_regexp = '(?:'. $this->_dvar_regexp. '(?:'. $this->_obj_ext_regexp. ')+)';
$this->_obj_call_regexp = '(?:'. $this->_obj_start_regexp. '(?:'. $this->_obj_params_regexp. ')?(?:'. $this->_dvar_math_regexp. '(?:'. $this->_num_const_regexp. '|'. $this->_dvar_math_var_regexp. ')*)?)';
заменены для поддержки вызова метода через другие объекты (*->*->*...) на:
$this->_obj_start_regexp = '(?:'. $this->_dvar_regexp. '(?:'. $this->_obj_ext_regexp. '(?:'.$this->_obj_params_regexp.')?)+)';
$this->_obj_call_regexp = '(?:'. $this->_obj_start_regexp. '(?:'. $this->_dvar_math_regexp. '(?:'. $this->_num_const_regexp .'|'. $this->_dvar_math_var_regexp. ')*)?)';
* Smarty_Compiler.class.php:
метод Smarty_Compiler::_parse_attrs(), строки 1577-1579:
if (i18n::isName($trimmed = trim($token, '"'))) {
$token = '"'. smarty_prefilter_i18n('{'. $trimmed. '}', $smarty). '"';
}
строки 163-164:
$this->_obj_start_regexp = '(?:'. $this->_dvar_regexp. '(?:'. $this->_obj_ext_regexp. ')+)';
$this->_obj_call_regexp = '(?:'. $this->_obj_start_regexp. '(?:'. $this->_obj_params_regexp. ')?(?:'. $this->_dvar_math_regexp. '(?:'. $this->_num_const_regexp. '|'. $this->_dvar_math_var_regexp. ')*)?)';
заменены для поддержки вызова метода через другие объекты (*->*->*...) на:
$this->_obj_start_regexp = '(?:'. $this->_dvar_regexp. '(?:'. $this->_obj_ext_regexp. '(?:'.$this->_obj_params_regexp.')?)+)';
$this->_obj_call_regexp = '(?:'. $this->_obj_start_regexp. '(?:'. $this->_dvar_math_regexp. '(?:'. $this->_num_const_regexp .'|'. $this->_dvar_math_var_regexp. ')*)?)';
А как люди начинают «верить» в XSLT? (я тоже хочу =)
Когда им говорят: «А здесь у нас XSLT.» И вариантов не предлагают.
А я просто начинал работать с XSLT, но не как с шаблонизатором.
А когда дошел до его использования шаблонизатором, очень даже понравилось удобство использования. А когда пришлось и с другими шаблонизаторами разбираться, еще больше понравилось удобство XSLT :) Верить/не верить, я об этом особо не парюсь, потому как в последнее время с ним работать не приходится, поэтому в данный момент он мне интересен просто как язык преобразований, а не как шаблонизатор. Иногда на нем прямо очень красивые решения можно написать, от создания которых получаешь удовольствие.
А когда дошел до его использования шаблонизатором, очень даже понравилось удобство использования. А когда пришлось и с другими шаблонизаторами разбираться, еще больше понравилось удобство XSLT :) Верить/не верить, я об этом особо не парюсь, потому как в последнее время с ним работать не приходится, поэтому в данный момент он мне интересен просто как язык преобразований, а не как шаблонизатор. Иногда на нем прямо очень красивые решения можно написать, от создания которых получаешь удовольствие.
Какой прекрасный топик! Автор — спасибо что потратили на это свое время!
НЛО прилетело и опубликовало эту надпись здесь
Вот не таким уж и хорошим, не надо совсем идеализировать :) Так, например, поблочно кэшировать (т.е. занести в строковую переменную) без гемора (eval'а или ob_start) не получится. Да и вседозволенность для шаблонизатора не плюс.
Но так как в XSLT мы пока только верим, то лучше PHP в некоторых случаях (пока) конечно нет. Да и то, если грамотно (по MVC) это делать.
Но так как в XSLT мы пока только верим, то лучше PHP в некоторых случаях (пока) конечно нет. Да и то, если грамотно (по MVC) это делать.
Как-то обычно для кусочного блочного кеширования надо echo/print заменить на $block .=…
Вроде без гемора. Не?
Вроде без гемора. Не?
не, переписывать все вызовы нада. не автоматизировано
Сам подход — использовать $block .=… — ущербный (и echo/print туда же). Для темплейт (где html кода обычно больше чем управляющих комманд) в php есть альтернативный синтаксис:
<? foreach($records as $record): ?>
<tr>
<td><?=$record['title']?></td>
<td><?=$record['text']?></td>
</tr>
<? endforeach ?>
<? foreach($records as $record): ?>
<tr>
<td><?=$record['title']?></td>
<td><?=$record['text']?></td>
</tr>
<? endforeach ?>
масло масленное
И к чему эта тавтология?
к тому что <?=$record['text']?> тоже самое что и <? echo $record['text'];?> а то что вы говорите про ущербность означает что вы не понимаете проблематики буферизации вывода
Разумеется оба делают echo. Только такой синтаксис немножно все же отличается от:
foreach($records as $record) {
echo "";
echo "". $record['title']. "".
. "". $record['text']. "";
echo "";
}
Проблемы буферизации те же. Только проблем у верстальщика немного меньше.
И вообще, я с вами спорить не хочу, потому что не вижу о чем :)
foreach($records as $record) {
echo "";
echo "". $record['title']. "".
. "". $record['text']. "";
echo "";
}
Проблемы буферизации те же. Только проблем у верстальщика немного меньше.
И вообще, я с вами спорить не хочу, потому что не вижу о чем :)
2 developer, ты бы ещё отделил шаблоны и view, а то смешно сравнивать смарти или Zend_view с кешированием и плагинами и str_replace
А вот как при помощи шаблона вывести дерево ака Nested Sets.?
Желательно, что б не на смарти
Желательно, что б не на смарти
Ни чего нет лучше Проверено жизненным опытом
не все равно как дом строить? главное же чтобы стоял. все остальное от лукавого… :)
Вы так и не успокоились :)
Результаты голосований некорректны, по многим причинам. О некоторых из них я имхо промолчу.
Я даже спорить не буду. Этап споров по шаблонизаторах (в php) я прошел лет 5 назад. Даже пользовался ими, и даже писал. ;)
Кто как хочет так и заблуждается :)
Я еще раз повторю, верить «этому» голосованию нельзя ;)
Результаты голосований некорректны, по многим причинам. О некоторых из них я имхо промолчу.
Я даже спорить не буду. Этап споров по шаблонизаторах (в php) я прошел лет 5 назад. Даже пользовался ими, и даже писал. ;)
Кто как хочет так и заблуждается :)
Я еще раз повторю, верить «этому» голосованию нельзя ;)
нехорошо вы говорите.
С одной стороны говорите свое мнение, а с другой стороны не хотите аргументировать. Вы поймите, что для зрителя этой странички вы всеголиш зеленый квалратик (ну я индус с перьями, например), так вот если делаете утверждение — проявляйте уважение и аргументируйте и не смайлами пожалуйста.
это голосование показывает степень интереса к шаблонизаторам на хабра сообществе и в такойм констексте ИМХО оно верно
С одной стороны говорите свое мнение, а с другой стороны не хотите аргументировать. Вы поймите, что для зрителя этой странички вы всеголиш зеленый квалратик (ну я индус с перьями, например), так вот если делаете утверждение — проявляйте уважение и аргументируйте и не смайлами пожалуйста.
это голосование показывает степень интереса к шаблонизаторам на хабра сообществе и в такойм констексте ИМХО оно верно
XSLT — магические слова! В них хочется верить!
это мне напоминает холивары windows vs linux и xp vs vista :)
Такие споры в среде PHP-кодеров возникают из-за того, что большинство спорящих кроме PHP ничего не видели. А PHP-таки ужос и приучает к раздолбайству, если с него начинать и им же заканчивать.
язык ни к чему не приучает. раздолбайство можно найти в любом проекте на любом языке.
Очень даже приучает. Люди начавшие свой программистский путь с паскаля в большинстве своём пишут более качественный и красивый код чем те, кто начал с PHP+HTML. Люди начавшие с Java и прошедшие через JSTL смотрят на все эти споры как на ссоры в детской песочнице, ибо все враждующие стороны, в большинстве случаев, пишут какой-то тупак.
так правильно, дело не в языке, а в том, что их никто не обучает писать красивый код.
Jav’истов приучает писать красивый код среда разработки, а не сам язык Java. PHP-исты пишущие, например, в Eclipse/ZendStudio тоже будут иметь достаточно красивый код.
Jav’истов приучает писать красивый код среда разработки, а не сам язык Java. PHP-исты пишущие, например, в Eclipse/ZendStudio тоже будут иметь достаточно красивый код.
НЛО прилетело и опубликовало эту надпись здесь
вот вы очень хорошо сказали, что среда разработки стимулирует писать тот или иной код. Среди пхп программистов многие хвастаются например тем, что пишут в блокноте, ИМХО это недостаток. Недавно Нетбинс (родная IDE Java) анонсировала поддержку PHP не уверен что у них там лучше чем у зенд, но намерен проверить ведь круче чем в NetBeans IDE нигде нет возможностей для рефакторинга.
www.netbeans.org/features/php/index.html
www.netbeans.org/features/php/index.html
имхо, единственный шаблонизатор, который мне понравился, и который по-моему, не доставляет хлопот дизайнеру, был PHPTal
Блять. Опять этот мифический дизайнер. В фотошопе он теги расставляет.
Ты сначала узнай, что такое дизайнер, а потом рассуждай, что ему хлопоты доставляет.
Ты сначала узнай, что такое дизайнер, а потом рассуждай, что ему хлопоты доставляет.
=) улыбнуло. я уж представил просто такой средне статистический высоконагруженный проект, который делают экстраспецы:
первое: Наш проЙЭкт настолько HILoad, что мы реально замарачиваемся и меняем все принты на эхи, и никаких контенинаций!!! не дай бохИ! ведь все нужно через запятую передать в эхи-это жутко принципиально!
второе: интерфейсы для лохов, их запрещено использовать по идеалогическим выскоскоростным идеалам! Вот дайте нам множественное наследование и обязательно оператор goto тогда мы покажем вам супер пупер мега оптимизацию!
третье: нам обязательно нужен Дизайнер и он будет работать с шаблонизатором, но поскольку PHP это язык шаблонов, то мы будем использовать тока PHP-Native. А да так мы еще и получим супер оптимизацию ведь мы не придумываем лишних абстракций!
Задачи кеширования мы будем решать сразу и заранее! то что нет нагрузки не проблемма- закешируем так что будет! кешируй нафиг все и сразу. Кто сказал что затраты на поддержание кеша больше чем выйгрыш? да он ламер.
короче достаточно почитать топики/коменты и станет весело
первое: Наш проЙЭкт настолько HILoad, что мы реально замарачиваемся и меняем все принты на эхи, и никаких контенинаций!!! не дай бохИ! ведь все нужно через запятую передать в эхи-это жутко принципиально!
второе: интерфейсы для лохов, их запрещено использовать по идеалогическим выскоскоростным идеалам! Вот дайте нам множественное наследование и обязательно оператор goto тогда мы покажем вам супер пупер мега оптимизацию!
третье: нам обязательно нужен Дизайнер и он будет работать с шаблонизатором, но поскольку PHP это язык шаблонов, то мы будем использовать тока PHP-Native. А да так мы еще и получим супер оптимизацию ведь мы не придумываем лишних абстракций!
Задачи кеширования мы будем решать сразу и заранее! то что нет нагрузки не проблемма- закешируем так что будет! кешируй нафиг все и сразу. Кто сказал что затраты на поддержание кеша больше чем выйгрыш? да он ламер.
короче достаточно почитать топики/коменты и станет весело
Неужели никто не упомянул StringTemplate от Terrence Parr? Самый лучший шоблойнезатор, разделяет содержимое от представление как котлеты от мух.
Лучше только HStringTemplate (порт с жабы на православный хаскель).
Лучше только HStringTemplate (порт с жабы на православный хаскель).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Споры о шаблонизаторах: троллинг или умные мысли?