Comments 76
Как сторонник XSLT, стою в сторонке и не вмешиваюсь ))
сторонник php_templates / blitz стоит в сторонке и курит. в его голове крутится мысль о том, что главное чтобы разработчику было удобно и проект работал как положено, а blitz он использует или смарти не так уж и важно :)
UFO just landed and posted this here
… в производительность 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
Зачем копипаст?
Хотя если кого-то интересует могу про основы написать.
UFO just landed and posted this here
В Споре рождается истина. Зря тему закрыли ^_^
UFO just landed and posted this here
по 5-му пункту вы высказались весьма безосновательно
много резких слов, и ни одного факта
много резких слов, и ни одного факта
UFO just landed and posted this here
Чесно говоря не вижу проблем никаких. Лично я использую symfony и нативные шаблоны. У меня полное управление кешированием и все что мне нужно. Верстальщик разобрался с шаблонным синтаксисом за пару минут.
вы наверное не поняли: тут изложены причины споров, а вот отстаивать свою точку зрения я предлагаю вам тут: HolyWar: Шаблонизаторы. Нужны ли они? состоятельны ли они? Форум.
Цель всего этого показать, что люди всегда спорят, минусуют, вместо того чтоб просто оценить инструментарий в контексте ЕГО использования.
Цель всего этого показать, что люди всегда спорят, минусуют, вместо того чтоб просто оценить инструментарий в контексте ЕГО использования.
UFO just landed and posted this here
вот вы в топике 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 :) Верить/не верить, я об этом особо не парюсь, потому как в последнее время с ним работать не приходится, поэтому в данный момент он мне интересен просто как язык преобразований, а не как шаблонизатор. Иногда на нем прямо очень красивые решения можно написать, от создания которых получаешь удовольствие.
Какой прекрасный топик! Автор — спасибо что потратили на это свое время!
UFO just landed and posted this here
Вот не таким уж и хорошим, не надо совсем идеализировать :) Так, например, поблочно кэшировать (т.е. занести в строковую переменную) без гемора (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 тоже будут иметь достаточно красивый код.
UFO just landed and posted this here
вот вы очень хорошо сказали, что среда разработки стимулирует писать тот или иной код. Среди пхп программистов многие хвастаются например тем, что пишут в блокноте, ИМХО это недостаток. Недавно Нетбинс (родная 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 (порт с жабы на православный хаскель).
Sign up to leave a comment.
Споры о шаблонизаторах: троллинг или умные мысли?