Комментарии 96
Smartyклон?! :) «Show me the code!» похоже на смарти
в целом интересно, хотя давно не использую такого рода шаблонизаторы, именно по тому, что «медленнее чистого РНР».
К сожалению pure PHP шаблоны плохочитаемы.
Абсолютно нормально читаемы. или {} лучше чем <? ?> ?? Это смешно ;)
> или {} лучше чем <? ?>
{$val} содержит меньше синтаксического мусора, чем <? echo $val; ?>, а уж тем более, чем у <? echo $this->val; ?>
Когда таких параметров становятся десятки, в одном случае мы видим аккуратный HTML с вставками, в другом — тонну закорючек :)
…
Мне, как бы, сейчас приходится и на Smarty шаблоны использовать, и на PHP, благо, фреймворку моему пофиг, какой вид юзать, использование унифицировано. Так вот, Smarty — на голову компактнее и нагляднее. И PHP используется только когда или уж совсем скорость критична, или когда логика очень сложная и 3/4 шаблона — из кода состоит :D
…
А так — надо будет сабж прикрутить, оценить. Синтаксис там чуть более громоздкий, чем у Smarty, но терпимый. М.б. некоторые компоненты с большим числом вложений, на него переведу, если эффективен окажется.
{$val} содержит меньше синтаксического мусора, чем <? echo $val; ?>, а уж тем более, чем у <? echo $this->val; ?>
Когда таких параметров становятся десятки, в одном случае мы видим аккуратный HTML с вставками, в другом — тонну закорючек :)
…
Мне, как бы, сейчас приходится и на Smarty шаблоны использовать, и на PHP, благо, фреймворку моему пофиг, какой вид юзать, использование унифицировано. Так вот, Smarty — на голову компактнее и нагляднее. И PHP используется только когда или уж совсем скорость критична, или когда логика очень сложная и 3/4 шаблона — из кода состоит :D
…
А так — надо будет сабж прикрутить, оценить. Синтаксис там чуть более громоздкий, чем у Smarty, но терпимый. М.б. некоторые компоненты с большим числом вложений, на него переведу, если эффективен окажется.
Да? а <?=$somthing ?>
попробуйте — работает ;)
попробуйте — работает ;)
Век живи, век учись, блин :D Спасибо, ловите плюс :)
Насколько я знаю использование этого метода не рекомендуется.
Совершенно верно.
кем не рекомендуется?
я про этот метод прочёл в документации к Zend Framework
я про этот метод прочёл в документации к Zend Framework
framework.zend.com/manual/ru/coding-standard.coding-style.html
Раздел: «B.4. Стиль кодирования. B.4.1. Обрамление PHP-кода»
Цитата:
" PHP-код должен всегда обрамлятся полными PHP-тегами:
<?php
?>
Короткие теги не допустимы. "
Раздел: «B.4. Стиль кодирования. B.4.1. Обрамление PHP-кода»
Цитата:
" PHP-код должен всегда обрамлятся полными PHP-тегами:
<?php
?>
Короткие теги не допустимы. "
эм…
вот пример использвоания:
framework.zend.com/manual/de/zend.form.quickstart.html#zend.form.quickstart.render
в самом низу, лучше поиском "<?="
собссно, из этого примера я и узнал о короткой версии тега
странно, что в русской версии они пишут о недопустимости, а в немецкой приводят в качестве примера
вот пример использвоания:
framework.zend.com/manual/de/zend.form.quickstart.html#zend.form.quickstart.render
в самом низу, лучше поиском "<?="
собссно, из этого примера я и узнал о короткой версии тега
странно, что в русской версии они пишут о недопустимости, а в немецкой приводят в качестве примера
слишком много русских быдлокодеров развелось
А посмотрите эту же страницу на английском языке (ему я доверяю больше, чем другим, ибо оф. документация написана на нём) и на том же русском, и обратите внимание, что в том месте где в немецком варианте короткие теги, в анлийском и русском вариантах короткие теги не используются…
Offtop… за что минусовали не понял… ссылку же дал на оф. документацию…
Offtop… за что минусовали не понял… ссылку же дал на оф. документацию…
на русском:
===== begin cut =====
… и скрипт вида для отображения формы:
<h2>Please login:</h2>
<?= $this->form ?>
Как вы наверное заметили, код контроллера не является полным
===== end cut =====
на английском:
===== begin cut =====
And a view script for displaying the form:
<h2>Please login:</h2>
<?= $this->form ?>
As you'll note from the controller code, there's more work to do
===== end cut =====
===== begin cut =====
… и скрипт вида для отображения формы:
<h2>Please login:</h2>
<?= $this->form ?>
Как вы наверное заметили, код контроллера не является полным
===== end cut =====
на английском:
===== begin cut =====
And a view script for displaying the form:
<h2>Please login:</h2>
<?= $this->form ?>
As you'll note from the controller code, there's more work to do
===== end cut =====
Если уж делать шаблонизатор не нативный — то, по моему мнению, лучше делать это на том, что для этого предназначено — на XSLT, ан егородить велосипед. А если хочется чегото простого — то тогда юзать натив PHP
pure PHP себя отлично показывает и быстро и наглядно (все зависит от того как оформлять), хорошо подходит альтернативный синтаксис структур управления
и также для других команд, да и расширяемость лучше, главное не путать бизнес логику и отображение.
и также для других команд, да и расширяемость лучше, главное не путать бизнес логику и отображение.
pastebin.com/f6f42f82b
[input name=«xxx» value="[?=htmlspecialchars($xxx);?]" /]
а с переводами строк что делать? а с кавычками? =)
впрочем, проблема не только в этом, а ещё и в том, что шаблон получается невалидным xml => его труднее воспринимать, а подсветка синтаксиса сходит с ума…
впрочем, проблема не только в этом, а ещё и в том, что шаблон получается невалидным xml => его труднее воспринимать, а подсветка синтаксиса сходит с ума…
>а с переводами строк что делать? а с кавычками? =)
?
>а ещё и в том, что шаблон получается невалидным xml => его труднее воспринимать
Хм. Как валидность xml влияет на восприятие? :) А в браузере уже всё валидно будет.
> а подсветка синтаксиса сходит с ума…
Редакторы надо нормальные использовать :)
?
php -r 'echo htmlspecialchars("qqq\"qqq\nqqq");'
qqq"qqq
qqq
>а ещё и в том, что шаблон получается невалидным xml => его труднее воспринимать
Хм. Как валидность xml влияет на восприятие? :) А в браузере уже всё валидно будет.
> а подсветка синтаксиса сходит с ума…
Редакторы надо нормальные использовать :)
! ну и поедет у тебя вся вёрстка, ибо в аттрибутах кавычки и переводы тоже должны экранироваться, а не только угловые скобочки да амперсандики.
угловые скобки рябят в лазах.
и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
угловые скобки рябят в лазах.
и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
>ну и поедет у тебя вся вёрстка, ибо в аттрибутах кавычки и переводы тоже должны экранироваться, а не только угловые скобочки да амперсандики.
Мы, наверное, друг друга недопонимаем.
>и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
Требуется уточнение:
— Откуда вдруг взялся препроцессор, что ты под ним понимаешь?
— Что ты понимаешь под «пониманием редактором»? Тут возможно двоякое поведение. Редакторы, типа mcedit в этом случае тупо подсвечивают строку как строку. Редакторы в массе своей, от vim до kdevelop подсвечивают в этом случае в строке php-синтаксис. Что для тебя более правильно? :)
Мы, наверное, друг друга недопонимаем.
>и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
Требуется уточнение:
— Откуда вдруг взялся препроцессор, что ты под ним понимаешь?
— Что ты понимаешь под «пониманием редактором»? Тут возможно двоякое поведение. Редакторы, типа mcedit в этом случае тупо подсвечивают строку как строку. Редакторы в массе своей, от vim до kdevelop подсвечивают в этом случае в строке php-синтаксис. Что для тебя более правильно? :)
pastebin.com/f3e2d5100
www.w3.org/TR/REC-xml/#sec-pi
правильное — подсвечивать ошибки, в частности: угловые скобки внутри атрибута — грубейшая ошибка.
www.w3.org/TR/REC-xml/#sec-pi
правильное — подсвечивать ошибки, в частности: угловые скобки внутри атрибута — грубейшая ошибка.
Давай мух отдельно, а котлеты — отдельно.
Если ты используешь шаблон, типа Smarty, то там и угловых скобок внутри параметра не будет.
Если используешь в качестве шаблона PHP — наверное, ты знаешь, что делаешь. И это, как раз, не тот случай, за который я ратую :) Но даже в этом случае проблема не встаёт. Шаблоны — на то и шаблоны, чтобы использовать их декомпозитивно. И уж на такую фигню, как угловую скобку внутри параметра, можно забить. Всё равно проверять на валидность можно только конечный результат, а не шаблон.
Если ты используешь шаблон, типа Smarty, то там и угловых скобок внутри параметра не будет.
Если используешь в качестве шаблона PHP — наверное, ты знаешь, что делаешь. И это, как раз, не тот случай, за который я ратую :) Но даже в этом случае проблема не встаёт. Шаблоны — на то и шаблоны, чтобы использовать их декомпозитивно. И уж на такую фигню, как угловую скобку внутри параметра, можно забить. Всё равно проверять на валидность можно только конечный результат, а не шаблон.
Нет, не клон. Именно из-за того, что WACT стал похходить на smarty и пришлось от него отказаться.
Лучший шаблонизатор это PHP =)
И есть ли там какие-нибудь итераторы по массивам? (php-вставки — зло)
Если работаете только вы — вполне нормально.
Но верстальщики почему-то начинают бояться шаблона, когда видят в нем php-код, и лезут с кучей вопросов перед тем, как начать что-то делать (это не мой опыт, мне рассказывали).
Но верстальщики почему-то начинают бояться шаблона, когда видят в нем php-код, и лезут с кучей вопросов перед тем, как начать что-то делать (это не мой опыт, мне рассказывали).
По опыту — не начинают, если им объяснить, что на php-вставки просто не надо обращать внимания. Расстановка этих вставок — дело программиста.
>верстальщики почему-то начинают бояться шаблона, когда видят в нем php-код, и лезут с кучей вопросов перед тем, как начать что-то делать (это не мой опыт, мне рассказывали)
Подтверждаю этот опыт личной практикой :)
Подтверждаю этот опыт личной практикой :)
Да, конечно, тэг лист
Нет, ибо чаще всего это (как и в вашем примере) не уровень представления.
А можно ссылку на определение «шаблонизатора»? ;)
xslt — это вполне шаблонизатор. Молоток не перестает быть молотком, если к нему приделать сбоку пистолет.
xslt — это вполне шаблонизатор. Молоток не перестает быть молотком, если к нему приделать сбоку пистолет.
Если уж так захотелось:
<?php $selected_user = $users[$get->userId()] ?>
{$selected_user.name}
Я использую macro уже больше года, и не помню, чтобы у меня возникли проблемы с динамическими вложенными ключами. Приведенный код вообще страшен, т.к. если в get не будет userId, или в $users не будет такого элемента, то плохо.
<?php $selected_user = $users[$get->userId()] ?>
{$selected_user.name}
Я использую macro уже больше года, и не помню, чтобы у меня возникли проблемы с динамическими вложенными ключами. Приведенный код вообще страшен, т.к. если в get не будет userId, или в $users не будет такого элемента, то плохо.
Все зависит от машинки и немного от сложности шаблона. На моей домашней машине:
korchasa@korchasa:/www/localhost/korchasa-bench$ cat /proc/cpuinfo
processor: 0
vendor_id: AuthenticAMD
cpu family: 6
model: 8
model name: Unknow CPU Type
stepping: 1
cpu MHz: 1350.114
cache size: 256 KB
с включенным APC, в забандленной версии — 150-160 rps.
korchasa@korchasa:/www/localhost/korchasa-bench$ cat /proc/cpuinfo
processor: 0
vendor_id: AuthenticAMD
cpu family: 6
model: 8
model name: Unknow CPU Type
stepping: 1
cpu MHz: 1350.114
cache size: 256 KB
с включенным APC, в забандленной версии — 150-160 rps.
Не знаю, привык к Smarty.
интересно чо за пидрила всех заплюсовал? гавнодрищ, выйди из тени, морду будем бить.
Честно говоря не вижу смысла в использовании шаблонизаторов. Читаемость шаблонов не аргумент (некоторые и среиалайз строки читают на ура).
Увеличение производительности — тоже не будет при использовании того же eAccelerator.
По мне так лучше семантическая(наглядная) верстка и php вставки(нативный шаблон).
Увеличение производительности — тоже не будет при использовании того же eAccelerator.
По мне так лучше семантическая(наглядная) верстка и php вставки(нативный шаблон).
Читаемость строк это как раз — главный аргумент. Правки в нативном РНР тупо дольше делать. Всякие хэлперы (например, Zend'овские) улучшают читаемость, но это все равно «кашица».
А чем <?=$myVar;?> отличается по читабельности {$myVar}… скобочками?
{$myVar} это не <?=$myVar;?>, а <?=htmlspecialchars($myVar);?>. Но это простой пример. Чем сложнее, тем хуже читать pure PHP:
{$#book→getAuthor().full_name}
{$#book→getAuthor().full_name}
Извиняюсь, сообщение порезалось:
{$item.title}
<?=(isset($item['title'])? htmlspecialchars($item['title']): '';?>
А дальше все хуже и хуже…
{$item.title}
<?=(isset($item['title'])? htmlspecialchars($item['title']): '';?>
А дальше все хуже и хуже…
Вот хоть убей, но обработкой должен заниматься контроллер а не представление.
Опять же имхо.
Опять же имхо.
Обработкой чего?
должен? с какой стати?
откуда контроллер будет знать, что для конкретно этого отображения для sanitize будет нужно htmlspecialchars (html, браузер), а для другого — консоль/ncurses не нужно?
откуда контроллер будет знать, что для конкретно этого отображения для sanitize будет нужно htmlspecialchars (html, браузер), а для другого — консоль/ncurses не нужно?
Ой зря ты это начал… ;)
хм… а мне кажется, что не особо-то и попрёшь против этого высказывания… хотя — посмотрим :-)
Я? Нет, конечно. Во-первых я всеми двумя руками за минимизацию контроллеров. А во-вторых мы их в CLI не используем.
Обычно, если мне нужно и cli и html, то я пишу reporter'ы. Хотя идея с контроллерами интересная.
Сейчас как раз пишу генератор моделей/контроллеров/etc. Там то либо command, либо controller. И, в принципе, мне нужно поддерживать оба интерфейса(cli, html). Может и получится объединить их. Пока только не очень понимаю, как абстрагироваться от того, как приходят параметры. Можно конечно все свести к lmbHttpRequest, но как-то это не красиво.
Обычно, если мне нужно и cli и html, то я пишу reporter'ы. Хотя идея с контроллерами интересная.
Сейчас как раз пишу генератор моделей/контроллеров/etc. Там то либо command, либо controller. И, в принципе, мне нужно поддерживать оба интерфейса(cli, html). Может и получится объединить их. Пока только не очень понимаю, как абстрагироваться от того, как приходят параметры. Можно конечно все свести к lmbHttpRequest, но как-то это не красиво.
Обработкой данных должен заниматься контроллер. Но он не должен заниматься шаблонизацией.
Если в зависимости от условия у тебя то жирным, то курсивом текст выделяться должен, то совать strong или em в контроллер — это несравнимо больший грех, чем if'ы в шаблон :)
Если в зависимости от условия у тебя то жирным, то курсивом текст выделяться должен, то совать strong или em в контроллер — это несравнимо больший грех, чем if'ы в шаблон :)
Ну если на прямую то вот:
<?=(empty($_GET['category'])? 'выберите категорию': strtoupper(htmlspecialchars($_GET['category'])));?>
А при грамотном MVC это будет так:
<?=$view->get('category', 'выберите категорию')?>
зы: пример странный, через get передавать русский текст…
зы2: strtoupper вообще говоря лишняя функция, это проще и лучше делать через css
<?=(empty($_GET['category'])? 'выберите категорию': strtoupper(htmlspecialchars($_GET['category'])));?>
А при грамотном MVC это будет так:
<?=$view->get('category', 'выберите категорию')?>
зы: пример странный, через get передавать русский текст…
зы2: strtoupper вообще говоря лишняя функция, это проще и лучше делать через css
Напишите пример php кода, аналогичный тому, что представлен в статье.
Я правильно понял — MACRO не является самостоятельным продуктом? И употребить его вне Limb3 будет проблематично, если вообще возможно?
Что-то жутко знакомое, противное, казалось бы, уже отжившее свой век встретило меня на странице результатов тестов…
«Снежинки», — задумчиво пробормотал я и закрыл страничку.
«Снежинки», — задумчиво пробормотал я и закрыл страничку.
Познакомился с MACRO летом этого года; применил его в двух «боевых» проектах, впечатления в-основном положительные: к синтаксису привыкаешь быстро, теги и фильтры достаточно обширны и покрывают значительную часть потребностей (к тому же никто не мешает добавить свои), парсер услужливо подсказывает, где ошибки (незакрытые теги, неверные параметры, некорректная вложенность и прочие), высокая скорость (компилятор на выходе отдает уже native-PHP, отсюда и :)
Из минусов (имхо): скомпилированные шаблоны валятся в одну кучу, а имена файлов хешируются, что затрудняет работу с ними (к примеру, если надо удалить какой-то конкретный, чтобы он перекомпилировался при обращении); кастомные теги/фильтры со сложной macro-логикой (например, form-тег select с optiongroup) своими силами создавать тяжко, т.к. не описан соответствующий SDK :/ правда компенсируется это весьма оперативным и благожелательным коммьюнити 8)
Из минусов (имхо): скомпилированные шаблоны валятся в одну кучу, а имена файлов хешируются, что затрудняет работу с ними (к примеру, если надо удалить какой-то конкретный, чтобы он перекомпилировался при обращении); кастомные теги/фильтры со сложной macro-логикой (например, form-тег select с optiongroup) своими силами создавать тяжко, т.к. не описан соответствующий SDK :/ правда компенсируется это весьма оперативным и благожелательным коммьюнити 8)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MACRO — гибкий PHP шаблонизатор, с человеческим «лицом»