Comments 96
Smartyклон?! :) «Show me the code!» похоже на смарти
+5
в целом интересно, хотя давно не использую такого рода шаблонизаторы, именно по тому, что «медленнее чистого РНР».
+3
К сожалению pure PHP шаблоны плохочитаемы.
-1
Абсолютно нормально читаемы. или {} лучше чем <? ?> ?? Это смешно ;)
-2
> или {} лучше чем <? ?>
{$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, но терпимый. М.б. некоторые компоненты с большим числом вложений, на него переведу, если эффективен окажется.
+1
Да? а <?=$somthing ?>
попробуйте — работает ;)
попробуйте — работает ;)
+3
Век живи, век учись, блин :D Спасибо, ловите плюс :)
-2
Насколько я знаю использование этого метода не рекомендуется.
+3
Совершенно верно.
0
кем не рекомендуется?
я про этот метод прочёл в документации к Zend Framework
я про этот метод прочёл в документации к Zend Framework
0
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
?>
Короткие теги не допустимы. "
0
эм…
вот пример использвоания:
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
в самом низу, лучше поиском "<?="
собссно, из этого примера я и узнал о короткой версии тега
странно, что в русской версии они пишут о недопустимости, а в немецкой приводят в качестве примера
0
слишком много русских быдлокодеров развелось
0
А посмотрите эту же страницу на английском языке (ему я доверяю больше, чем другим, ибо оф. документация написана на нём) и на том же русском, и обратите внимание, что в том месте где в немецком варианте короткие теги, в анлийском и русском вариантах короткие теги не используются…
Offtop… за что минусовали не понял… ссылку же дал на оф. документацию…
Offtop… за что минусовали не понял… ссылку же дал на оф. документацию…
0
на русском:
===== 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 =====
0
Если уж делать шаблонизатор не нативный — то, по моему мнению, лучше делать это на том, что для этого предназначено — на XSLT, ан егородить велосипед. А если хочется чегото простого — то тогда юзать натив PHP
+1
pure PHP себя отлично показывает и быстро и наглядно (все зависит от того как оформлять), хорошо подходит альтернативный синтаксис структур управления
и также для других команд, да и расширяемость лучше, главное не путать бизнес логику и отображение.
и также для других команд, да и расширяемость лучше, главное не путать бизнес логику и отображение.
-1
pastebin.com/f6f42f82b
0
[input name=«xxx» value="[?=htmlspecialchars($xxx);?]" /]
0
а с переводами строк что делать? а с кавычками? =)
впрочем, проблема не только в этом, а ещё и в том, что шаблон получается невалидным xml => его труднее воспринимать, а подсветка синтаксиса сходит с ума…
впрочем, проблема не только в этом, а ещё и в том, что шаблон получается невалидным xml => его труднее воспринимать, а подсветка синтаксиса сходит с ума…
+1
>а с переводами строк что делать? а с кавычками? =)
?
>а ещё и в том, что шаблон получается невалидным xml => его труднее воспринимать
Хм. Как валидность xml влияет на восприятие? :) А в браузере уже всё валидно будет.
> а подсветка синтаксиса сходит с ума…
Редакторы надо нормальные использовать :)
?
php -r 'echo htmlspecialchars("qqq\"qqq\nqqq");' qqq"qqq qqq
>а ещё и в том, что шаблон получается невалидным xml => его труднее воспринимать
Хм. Как валидность xml влияет на восприятие? :) А в браузере уже всё валидно будет.
> а подсветка синтаксиса сходит с ума…
Редакторы надо нормальные использовать :)
0
! ну и поедет у тебя вся вёрстка, ибо в аттрибутах кавычки и переводы тоже должны экранироваться, а не только угловые скобочки да амперсандики.
угловые скобки рябят в лазах.
и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
угловые скобки рябят в лазах.
и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
+1
>ну и поедет у тебя вся вёрстка, ибо в аттрибутах кавычки и переводы тоже должны экранироваться, а не только угловые скобочки да амперсандики.
Мы, наверное, друг друга недопонимаем.
>и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
Требуется уточнение:
— Откуда вдруг взялся препроцессор, что ты под ним понимаешь?
— Что ты понимаешь под «пониманием редактором»? Тут возможно двоякое поведение. Редакторы, типа mcedit в этом случае тупо подсвечивают строку как строку. Редакторы в массе своей, от vim до kdevelop подсвечивают в этом случае в строке php-синтаксис. Что для тебя более правильно? :)
Мы, наверное, друг друга недопонимаем.
>и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
Требуется уточнение:
— Откуда вдруг взялся препроцессор, что ты под ним понимаешь?
— Что ты понимаешь под «пониманием редактором»? Тут возможно двоякое поведение. Редакторы, типа mcedit в этом случае тупо подсвечивают строку как строку. Редакторы в массе своей, от vim до kdevelop подсвечивают в этом случае в строке php-синтаксис. Что для тебя более правильно? :)
0
pastebin.com/f3e2d5100
www.w3.org/TR/REC-xml/#sec-pi
правильное — подсвечивать ошибки, в частности: угловые скобки внутри атрибута — грубейшая ошибка.
www.w3.org/TR/REC-xml/#sec-pi
правильное — подсвечивать ошибки, в частности: угловые скобки внутри атрибута — грубейшая ошибка.
0
Давай мух отдельно, а котлеты — отдельно.
Если ты используешь шаблон, типа Smarty, то там и угловых скобок внутри параметра не будет.
Если используешь в качестве шаблона PHP — наверное, ты знаешь, что делаешь. И это, как раз, не тот случай, за который я ратую :) Но даже в этом случае проблема не встаёт. Шаблоны — на то и шаблоны, чтобы использовать их декомпозитивно. И уж на такую фигню, как угловую скобку внутри параметра, можно забить. Всё равно проверять на валидность можно только конечный результат, а не шаблон.
Если ты используешь шаблон, типа Smarty, то там и угловых скобок внутри параметра не будет.
Если используешь в качестве шаблона PHP — наверное, ты знаешь, что делаешь. И это, как раз, не тот случай, за который я ратую :) Но даже в этом случае проблема не встаёт. Шаблоны — на то и шаблоны, чтобы использовать их декомпозитивно. И уж на такую фигню, как угловую скобку внутри параметра, можно забить. Всё равно проверять на валидность можно только конечный результат, а не шаблон.
0
Нет, не клон. Именно из-за того, что WACT стал похходить на smarty и пришлось от него отказаться.
0
UFO just landed and posted this here
Лучший шаблонизатор это PHP =)
+5
UFO just landed and posted this here
UFO just landed and posted this here
И есть ли там какие-нибудь итераторы по массивам? (php-вставки — зло)
+1
UFO just landed and posted this here
Если работаете только вы — вполне нормально.
Но верстальщики почему-то начинают бояться шаблона, когда видят в нем php-код, и лезут с кучей вопросов перед тем, как начать что-то делать (это не мой опыт, мне рассказывали).
Но верстальщики почему-то начинают бояться шаблона, когда видят в нем php-код, и лезут с кучей вопросов перед тем, как начать что-то делать (это не мой опыт, мне рассказывали).
+1
UFO just landed and posted this here
По опыту — не начинают, если им объяснить, что на php-вставки просто не надо обращать внимания. Расстановка этих вставок — дело программиста.
0
>верстальщики почему-то начинают бояться шаблона, когда видят в нем php-код, и лезут с кучей вопросов перед тем, как начать что-то делать (это не мой опыт, мне рассказывали)
Подтверждаю этот опыт личной практикой :)
Подтверждаю этот опыт личной практикой :)
0
Нет, ибо чаще всего это (как и в вашем примере) не уровень представления.
0
UFO just landed and posted this here
А можно ссылку на определение «шаблонизатора»? ;)
xslt — это вполне шаблонизатор. Молоток не перестает быть молотком, если к нему приделать сбоку пистолет.
xslt — это вполне шаблонизатор. Молоток не перестает быть молотком, если к нему приделать сбоку пистолет.
0
UFO just landed and posted this here
Если уж так захотелось:
<?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 не будет такого элемента, то плохо.
0
UFO just landed and posted this here
Все зависит от машинки и немного от сложности шаблона. На моей домашней машине:
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.
0
Не знаю, привык к Smarty.
+1
UFO just landed and posted this here
UFO just landed and posted this here
интересно чо за пидрила всех заплюсовал? гавнодрищ, выйди из тени, морду будем бить.
-6
UFO just landed and posted this here
UFO just landed and posted this here
Честно говоря не вижу смысла в использовании шаблонизаторов. Читаемость шаблонов не аргумент (некоторые и среиалайз строки читают на ура).
Увеличение производительности — тоже не будет при использовании того же eAccelerator.
По мне так лучше семантическая(наглядная) верстка и php вставки(нативный шаблон).
Увеличение производительности — тоже не будет при использовании того же eAccelerator.
По мне так лучше семантическая(наглядная) верстка и php вставки(нативный шаблон).
0
Читаемость строк это как раз — главный аргумент. Правки в нативном РНР тупо дольше делать. Всякие хэлперы (например, Zend'овские) улучшают читаемость, но это все равно «кашица».
0
А чем <?=$myVar;?> отличается по читабельности {$myVar}… скобочками?
0
{$myVar} это не <?=$myVar;?>, а <?=htmlspecialchars($myVar);?>. Но это простой пример. Чем сложнее, тем хуже читать pure PHP:
{$#book→getAuthor().full_name}
{$#book→getAuthor().full_name}
0
Извиняюсь, сообщение порезалось:
{$item.title}
<?=(isset($item['title'])? htmlspecialchars($item['title']): '';?>
А дальше все хуже и хуже…
{$item.title}
<?=(isset($item['title'])? htmlspecialchars($item['title']): '';?>
А дальше все хуже и хуже…
0
Вот хоть убей, но обработкой должен заниматься контроллер а не представление.
Опять же имхо.
Опять же имхо.
0
Обработкой чего?
0
должен? с какой стати?
откуда контроллер будет знать, что для конкретно этого отображения для sanitize будет нужно htmlspecialchars (html, браузер), а для другого — консоль/ncurses не нужно?
откуда контроллер будет знать, что для конкретно этого отображения для sanitize будет нужно htmlspecialchars (html, браузер), а для другого — консоль/ncurses не нужно?
+2
Ой зря ты это начал… ;)
0
хм… а мне кажется, что не особо-то и попрёшь против этого высказывания… хотя — посмотрим :-)
0
Я? Нет, конечно. Во-первых я всеми двумя руками за минимизацию контроллеров. А во-вторых мы их в CLI не используем.
Обычно, если мне нужно и cli и html, то я пишу reporter'ы. Хотя идея с контроллерами интересная.
Сейчас как раз пишу генератор моделей/контроллеров/etc. Там то либо command, либо controller. И, в принципе, мне нужно поддерживать оба интерфейса(cli, html). Может и получится объединить их. Пока только не очень понимаю, как абстрагироваться от того, как приходят параметры. Можно конечно все свести к lmbHttpRequest, но как-то это не красиво.
Обычно, если мне нужно и cli и html, то я пишу reporter'ы. Хотя идея с контроллерами интересная.
Сейчас как раз пишу генератор моделей/контроллеров/etc. Там то либо command, либо controller. И, в принципе, мне нужно поддерживать оба интерфейса(cli, html). Может и получится объединить их. Пока только не очень понимаю, как абстрагироваться от того, как приходят параметры. Можно конечно все свести к lmbHttpRequest, но как-то это не красиво.
0
Обработкой данных должен заниматься контроллер. Но он не должен заниматься шаблонизацией.
Если в зависимости от условия у тебя то жирным, то курсивом текст выделяться должен, то совать strong или em в контроллер — это несравнимо больший грех, чем if'ы в шаблон :)
Если в зависимости от условия у тебя то жирным, то курсивом текст выделяться должен, то совать strong или em в контроллер — это несравнимо больший грех, чем if'ы в шаблон :)
0
UFO just landed and posted this here
Ну если на прямую то вот:
<?=(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
0
Напишите пример php кода, аналогичный тому, что представлен в статье.
+1
UFO just landed and posted this here
Я правильно понял — MACRO не является самостоятельным продуктом? И употребить его вне Limb3 будет проблематично, если вообще возможно?
+1
Что-то жутко знакомое, противное, казалось бы, уже отжившее свой век встретило меня на странице результатов тестов…
«Снежинки», — задумчиво пробормотал я и закрыл страничку.
«Снежинки», — задумчиво пробормотал я и закрыл страничку.
+3
Познакомился с MACRO летом этого года; применил его в двух «боевых» проектах, впечатления в-основном положительные: к синтаксису привыкаешь быстро, теги и фильтры достаточно обширны и покрывают значительную часть потребностей (к тому же никто не мешает добавить свои), парсер услужливо подсказывает, где ошибки (незакрытые теги, неверные параметры, некорректная вложенность и прочие), высокая скорость (компилятор на выходе отдает уже native-PHP, отсюда и :)
Из минусов (имхо): скомпилированные шаблоны валятся в одну кучу, а имена файлов хешируются, что затрудняет работу с ними (к примеру, если надо удалить какой-то конкретный, чтобы он перекомпилировался при обращении); кастомные теги/фильтры со сложной macro-логикой (например, form-тег select с optiongroup) своими силами создавать тяжко, т.к. не описан соответствующий SDK :/ правда компенсируется это весьма оперативным и благожелательным коммьюнити 8)
Из минусов (имхо): скомпилированные шаблоны валятся в одну кучу, а имена файлов хешируются, что затрудняет работу с ними (к примеру, если надо удалить какой-то конкретный, чтобы он перекомпилировался при обращении); кастомные теги/фильтры со сложной macro-логикой (например, form-тег select с optiongroup) своими силами создавать тяжко, т.к. не описан соответствующий SDK :/ правда компенсируется это весьма оперативным и благожелательным коммьюнити 8)
+1
Sign up to leave a comment.
MACRO — гибкий PHP шаблонизатор, с человеческим «лицом»