Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 164
Да-да, хороший проект!
Но лично мне в Blitz не всегда удобно работать с условиями. Почему в if нельзя вставить блок кода (что-нибудь типа if $condition {{BEGIN}}...{{END}})? Было бы гораздо-гораздее :)
Но лично мне в Blitz не всегда удобно работать с условиями. Почему в if нельзя вставить блок кода (что-нибудь типа if $condition {{BEGIN}}...{{END}})? Было бы гораздо-гораздее :)
Пиши фишеру реквест :)
Да, пока условие проверяем в коде и добавляем еще один контекст :)
Да, пока условие проверяем в коде и добавляем еще один контекст :)
да реквест такой конечно есть просто руки никак не дойдут
http://alexeyrybak.com/blitz/bt/view.php…
http://alexeyrybak.com/blitz/bt/view.php…
Есть ли четкая политика, которая ограничивает выполнение реквестов? Не "доходом рук", а по принципиальным соображениям. Очень боюсь, что Блиц превратится в Смарти N2 и "теперь мы попробуем со всей этой фигней взлететь"
лень не самый фиговый ограничитель кстати. если совсем лень, то, значит, и не надо. а какие есть причины думать, что оно превратится в монстра? есть проекты, где не используется _ничего_ кроме контекстов, как в старом добром php_templates. ни пользовательские методы, ни инклюды, ни условные операторы. и потом, тут есть принципиальный момент - усложняя функционал этого модуля, довольно сложно замедлить старые приложения. то есть с фигней взлетит невопрос.
Подставь в свой текст слово Смарти вместо Блиц - совпадет на 100% =)
На смарти тоже есть проекты, где одни контексты. И летает оно прекрасно, поскольку по сути php mess...
Собственно, наличие Смарти и заставляет так думать. Ну, и постепенное движение Блица от "блочного" классического шаблонизатора к "логическому".
Хотя, возможно, я и на пустом месте переживаю.
На смарти тоже есть проекты, где одни контексты. И летает оно прекрасно, поскольку по сути php mess...
Собственно, наличие Смарти и заставляет так думать. Ну, и постепенное движение Блица от "блочного" классического шаблонизатора к "логическому".
Хотя, возможно, я и на пустом месте переживаю.
Вот тоже сидел, думал - что бы переписать под данный шаблонизатор для его оценки. И везде требуются либо вложенные условия, либо блоки begin..end в условиях. А очень бы хотелось ощутить в работе его...
Это не должно вас останавливать :) Все эти проблемы решаемы и Blitz стоит того, что бы это попробовать.
Решаемы, но путем ввода изменений в сам скрипт, а не в шаблон. Допустим, банальный листинг файлов. В одном шаблоне(в данном случае я уже подразумеваю стиль - внешний вид, шкурка) мне надо для файлов, добавленные в последний час отобразить одну иконку, а добавленные за последние сутки - другую. В другой шкурке вообще не надо никак выделять такие файлы. И вместо того, чтоб передать в шаблон массив файлов, я еще в самом скрипте буду должен добавлять строки для определения свежести файла, а во второй шаблон заглушку - пустоту вместо иконки. КОнечно, сильно утрировано, но неудобства все же доставляет:-(
Не уж то Хабр v2.0 таки будет использовать Blitz, как спрашивали вы тут и советовали вам тут?
ну и вам ребят большое спасибо, во-первых вы продавили некоторые фичи, которые мне просто лень было делать. во-вторых вы нашли некоторое количество сложных косяков, которые мы бы исправили ещё хрен знает когда. что касается удобства - споры не утихают, но я руководствовался абсолютно теми же причинами, когда начинал этот проект - а было это ещё в 2005-м. они в-общем чисто управленческие и далеко не каждому технарю сразу понятные. удачи :)
какой кстати ещё для меня был опыт (очень важный) - это использование комьюнити для повышения качества проекта. я на полном серьезе ваще не представлял раньше как это круто работает. просто так выделить время на разработку подобных проектов почти никогда не получается, обосновать необходимость подобных проектов сложно, поскольку они не дают мгновенной отдачи, но при этом никто не торопится делать-то что-то открытое или вместе по очень понятным прозаическим причинам. открывая проект в Open Source конечно руководствуешься и разными не-бизнес мотивами (have a lot of fun!), но что дает такое развитие бизнесу - качественное тестирование и поддерку в виде реквестов, безо взяких затрат. это очень круто и честно говоря я очень советую открывать таким макаром внутренние закрытые проекты/инструменты, которые составляют ядро вашего производства.
Интересует информация об этом проекте с точки зрения управления разработками, а не программиста. Где можно получить более подробную информацию, увидеть как это работает и кто из разработчиков уже работает с этим проектом?
Идея проста. Программист делает свою работу, верстальщик свою. Как это работает внешне — http://www.autokadabra.ru. Технические аспекты в документации.
Вопрос командного взаимодействия как-то в эти рамки не входит.
Вопрос командного взаимодействия как-то в эти рамки не входит.
любая подобная технология четко разграничивает верстку и программирование, данная принуждает к выделению логики презентации в отдельный слой под контролем девелопера, а не в коде у верстака. соотвественно в плюсе стоимость владения на больших проектах
Blitz - отличная штука, шустрая, быстрая, красивая, изящная и по-настоящему применимая.
Эх, я не очень разбираюсь в линях, но чтобы использовать эту штуку необходимо уломать хостера поставить её себе (make, install...). Поэтому мы в наших проектах используем smarty. Есть ли какой-нибудь простой способ установки подобных (Blitz) шаблонизаторов? Без томных уговоров хостеров.
Штука удобная, но дизайнеру(верстальщику) придется ее изучать(а PHP не знают только самые ленивые). Поэтому пока мой выбор - шаблоны на самом PHP.
{{ BEGIN footer }}{{$title}}{{ END footer}}
Хороший верстальщик, владеющих набором этих директив, вполне справится с разработкой сайта, подобного этому.
Хороший верстальщик, владеющих набором этих директив, вполне справится с разработкой сайта, подобного этому.
>Глава 4. Настройка
в таблице данный синтаксис объявлен как "по умолчанию", т.е. есть возможность сократить количество скобок ;)
в таблице данный синтаксис объявлен как "по умолчанию", т.е. есть возможность сократить количество скобок ;)
Blitz не поддерживает по принципиальным соображениям сложные выражения:
{{if(if($foo, 0, 1), 'bar', 'foobar')}}
Данный код работать не будет. Не надо превращать код в спагетти.
IF'а нет. я не работал со смарти и поэтому с трудом представляю зачем IF'ы в шаблонах (в php_templates их нет и как-то удавалось с этим мириться) :")
насколько я понимаю, автор тоже предпочитал php_templates пока не сделал ему более удобную замену...
"а PHP не знают только самые ленивые" - вот это очень пугает... и как знают? видимо поэтому есть такое понятие как "пых-пых программист"
уже давно на Blitz засматриваюсь, но по старинке использую php_templates (слава Аллаху - на PHP приходится писать очень редко :"), но тем не менее )
только что полез еще раз почитать доки и возникло несколько вопросов:
1. а никак не удастся добавить возможность использовать синтаксис php_templates для объявления контекстов?
2. в php_templates удобно "перебивать" настройки задавая собственный синтаксис объявления контекстов как параметр tmpl_open
в Blitz такое не планируется?
просто сам я на Cи не пишу, и не смогу сделать для себя патчик даже по 1му вопросу :(
только что полез еще раз почитать доки и возникло несколько вопросов:
1. а никак не удастся добавить возможность использовать синтаксис php_templates для объявления контекстов?
2. в php_templates удобно "перебивать" настройки задавая собственный синтаксис объявления контекстов как параметр tmpl_open
в Blitz такое не планируется?
просто сам я на Cи не пишу, и не смогу сделать для себя патчик даже по 1му вопросу :(
1. там небольшой гемор с парсингом он посроен на старом коде php_templates но в blitz есть просто открывающий и закрывающий тэг, а все прочие конструкции языка определяются лексемами внутри тэга. а в php_templates есть отдельные тэги для открытия-закрытия контекстов, и для прочего. соотвественно если писать поддержку ещё и нативную php_templates то это просто лишние поиски и дополнительные операции. оно быстрое но все равно зачем. проще написать конвертор, он элементарный например
<tmpl:name> в <!-- BEGIN name -->
</tmpl:name> в <!-- END name > или просто <!-- END -->
<tmpl:name> в <!-- BEGIN name -->
</tmpl:name> в <!-- END name > или просто <!-- END -->
жаль... просто довольно удобно юзать фолдинг контекстов (при подходе используемом в php_templates он будет работать в любом редакторе) ...
но в целом ты прав, вроде ничего не мешает конвертировать шаблон от php_templates в твой синтаксис непосредственно перед употреблением (1 раз при выкладывании на сервер). так оно и шаблон кодить будет удобно (по старинке) и работать пошустрее чем php_templates должно :)
но в целом ты прав, вроде ничего не мешает конвертировать шаблон от php_templates в твой синтаксис непосредственно перед употреблением (1 раз при выкладывании на сервер). так оно и шаблон кодить будет удобно (по старинке) и работать пошустрее чем php_templates должно :)
2. BEGIN/END перебить нельзя. можно перебить теги {{, }} а также альтернативные тэги <!--, --> и префикс переменной ($). плюс по умолчанию переменные можно не префиксовать вовсе.
ясно. будем привыкать :)
php_templates — в коме, а Blitz — свежий современный проект, следующий эволюционный шаг, сделанный fisher'ом в правильном направлении.
я ещё некоторое (продолжительное) время не дам php_templates'у совсем умереть, поддерживая его коматозное состояние, т.к. писал его изначально под себя, и сейчас на нём крутится что-то около сотни только моих проектов. так что, сборки под новые версии РНР появляться будут по мере сил и возможностей.
однако же, никаких планов по поводу введения новых фич нет и не предвидится.
поэтому, чтобы идти в ногу с прогрессом, решение о неторопливом, без суеты, переходе на Blitz — абсолютно верное. =)
я ещё некоторое (продолжительное) время не дам php_templates'у совсем умереть, поддерживая его коматозное состояние, т.к. писал его изначально под себя, и сейчас на нём крутится что-то около сотни только моих проектов. так что, сборки под новые версии РНР появляться будут по мере сил и возможностей.
однако же, никаких планов по поводу введения новых фич нет и не предвидится.
поэтому, чтобы идти в ногу с прогрессом, решение о неторопливом, без суеты, переходе на Blitz — абсолютно верное. =)
с ума сойти :)
сколько тут оказывается интересных людей :D
>поэтому, чтобы идти в ногу с прогрессом, решение о неторопливом,
>без суеты, переходе на Blitz — абсолютно верное. =)
собственно так оно тогджа и будет. старое пока на php_templates работает и трогать его нет смысла, а в чем-нибудь новом можно и Blitz опробовать... а когда руку набью, тогда может и старое на Blitz можно будет неспешно перевести :")
сколько тут оказывается интересных людей :D
>поэтому, чтобы идти в ногу с прогрессом, решение о неторопливом,
>без суеты, переходе на Blitz — абсолютно верное. =)
собственно так оно тогджа и будет. старое пока на php_templates работает и трогать его нет смысла, а в чем-нибудь новом можно и Blitz опробовать... а когда руку набью, тогда может и старое на Blitz можно будет неспешно перевести :")
Подскажите, а что такое ZPS на диаграмме?
После Смартиподобных шаблонизаторов работать с Blitz сложнее.
Возникает привычка зачастую задавать логику прямо в шаблоне, а переход на Blitz подразумевает переписку всех модулей, ядра системы и обработку шаблонов. К сожалению, процесс нельзя автоматизировать.
А что если сделать хотя бы схожий синтаксис со Smarty для более облегченного перехода? :-)
Возникает привычка зачастую задавать логику прямо в шаблоне, а переход на Blitz подразумевает переписку всех модулей, ядра системы и обработку шаблонов. К сожалению, процесс нельзя автоматизировать.
А что если сделать хотя бы схожий синтаксис со Smarty для более облегченного перехода? :-)
А чем Blitz лучше/хуже чем Smarty?
Проводились сравнения?
Проводились сравнения?
Бенчмарки (графики), указанные в самом начале топика говорят о том, что Blitz в разы шустрее Smarty.
не в разы, но быстрее, насколько - зависит от сложности приложения (чем сложнее - тем быстрее).
Функционал в смарти слишком перегружен, имхо. В разы. Не редкость хелперы, которые напрямую работают с БД. Ушли от PHP... "и вышли таки обратно на Дерибасовскую" - получили ту же самую лапшу. Только утяжелённую.
Появление таких проектов, как Smarty Lite, Quicky - говорит само за себя.
Появление таких проектов, как Smarty Lite, Quicky - говорит само за себя.
Поскольку проект - плод одного, хоть и весьма талантливого энтузиаста, да к тому же ещё и совсем юного, то сайта у него нет, есть только линк на релиз: http://vsudebyl.cz/files/quicky_0.3.03.r…
Точку зрения автора можно почитать в docs/story.txt
Точку зрения автора можно почитать в docs/story.txt
/story захватывающий. Попробовали повесить на свой проект, сжирает 24 метра памяти и помирает (смарти в районе 12 жрет)
Вообще, движком автор занимается или забил?
Вообще, движком автор занимается или забил?
Занимается, насколько мне известно.
Можно даже ему написать о проблемах. Вот только в силу уже упомянутой молодости реагирует он не всегда адекватно, что жаль. Хотя тот же самый фактор может его заставить немедленно исправить ошибку =)
Ссылку на релиз я брал отсюда:
http://phpclub.ru/talk/showthread.php?s=…
Можно, наверное, ему туда написать
А подо что оно отжирает память? Насколько я понимаю, может жрать только при компиляции? Или на чем-то ещё?
Можно даже ему написать о проблемах. Вот только в силу уже упомянутой молодости реагирует он не всегда адекватно, что жаль. Хотя тот же самый фактор может его заставить немедленно исправить ошибку =)
Ссылку на релиз я брал отсюда:
http://phpclub.ru/talk/showthread.php?s=…
Можно, наверное, ему туда написать
А подо что оно отжирает память? Насколько я понимаю, может жрать только при компиляции? Или на чем-то ещё?
Ах да, при попытке использовать Blitz возникали проблемы с "наследованием" переменных, то есть применением их во вложенных шаблонах. И даже использования глобальных вариантов не спасало.
если это баги - о них надо не стесняться писать девелоперам. в первоначальных версиях такие косяки действительно были - даже не косяки, я просто типа считал "нафиг надо"
А чейнджлог сейчас обновлен на сайте?
Сам посмотрел. Увидел последнее обновление мануала от 27 ноября прошлого года.
Хотелось бы узнать - конструкции include($var . '/my.tpl'); до сих пор не доступны? :-)
Хотелось бы узнать - конструкции include($var . '/my.tpl'); до сих пор не доступны? :-)
да, операций конкатенации нет. и тоже есть такие реквесты, иначе народ обходится своими обертками вида
function my_include($name, $params) {
$full_path = ... // prepare full path
return $this->include($full_path);
}
но это медленнее
многие например вообще не используют include в HTML коде, всё делают переменными, а внутри вьюхи эти переменные инициализируют - либо парсят отдельные шаблоны, либо фетчат блоки. так шаблоны совсем простые получаются.
function my_include($name, $params) {
$full_path = ... // prepare full path
return $this->include($full_path);
}
но это медленнее
многие например вообще не используют include в HTML коде, всё делают переменными, а внутри вьюхи эти переменные инициализируют - либо парсят отдельные шаблоны, либо фетчат блоки. так шаблоны совсем простые получаются.
Вот из-за отсутствия таких костылей я и использую собственноручно написанный шаблонизатор, простой, быстрый и с нужными мне функциями. :-)
использую с первого релиза, делаю на выходе echo $tpl_header->parse () . $tpl_main->parse () . $tpl_footer->parse ();
Доктор, это нормально, если мне удобно? (В рамках скорости)
Доктор, это нормально, если мне удобно? (В рамках скорости)
ну, доктора говорят так. если вам хорошо, то даже если вам вдруг кажется, что кто-то считает, будто это наоборот совсем никуда - не парьтесь, они просто ничего не понимают. но если серьезно, то я не понял вопроса :)))))
Я б на Blitz бы перешел! Пусть меня научат!
ИМХО Мне кажется синтаксис чуть сложноват, во всяком случае в сравнени со смарти.
ИМХО Мне кажется синтаксис чуть сложноват, во всяком случае в сравнени со смарти.
Охренительная хрень!
Как ни странно, я недавно реализовал подобный шаблонизатор (где есть только переменные и контекст (у меня блоком называется)).
Вообщем, я в шоке!
Как ни странно, я недавно реализовал подобный шаблонизатор (где есть только переменные и контекст (у меня блоком называется)).
Вообщем, я в шоке!
не понимаю а че там должно быть сложного с прослойкой?
наоброт цель была сделать поддержку больших проектов проще
а что в смарти что в пхп такое мясо наворотишь потом и с поллитрой не разберешься, особенно если не сам, а отдаешь кому-то начинающему или кто в программинге не очень шарит.
наоброт цель была сделать поддержку больших проектов проще
а что в смарти что в пхп такое мясо наворотишь потом и с поллитрой не разберешься, особенно если не сам, а отдаешь кому-то начинающему или кто в программинге не очень шарит.
а что такое php mass?
Это php в перемешку с html, т.е. без использования шаблонизатора, как видим - без шаблонизатора приложение все равно будет быстрее :)
только php mEss
График как по мне очено абстрактный....
Хотя бы зависимость от с ( количество конкурирующих запросов) узнать ( 4 8 16 32 64) для возможности экстраполяции, а также значения средней нагрузки процессора и загрузки памяти.
ОФТОП:
Идея сайта Веб 3.0:
1. Отказаться от серверных языков ( кроме с конечно :)
2. Доступ к базе по http протоколу ( xml - зопрос, ответ)
3. Сбор страници на стороне клиента ( Java Script, Flash, Silverlight, и т.п.)
Хотя бы зависимость от с ( количество конкурирующих запросов) узнать ( 4 8 16 32 64) для возможности экстраполяции, а также значения средней нагрузки процессора и загрузки памяти.
ОФТОП:
Идея сайта Веб 3.0:
1. Отказаться от серверных языков ( кроме с конечно :)
2. Доступ к базе по http протоколу ( xml - зопрос, ответ)
3. Сбор страници на стороне клиента ( Java Script, Flash, Silverlight, и т.п.)
про конкурентные запросы и утилизацию ресурсов - хорошие замечания, я просто поленился. это довольно кропотливая работа и если проводить измерения аккуратно для всех движков я бы потратил слишком много времени которого нет - надо автоматизировать, короче времени на это пока нет. да и будет ли особенный смысл неясно - так как приложение приложению рознь.
Смысл заключается в том, что показать какой выигрыш даст использования при больших нагрузках. А тест интересен в основном (имхо) при zps( or xcache or apc) для сравнения с smarty, php(includes), xml/xslt
Плюс ссылка по теме:
Template Benchmark
Template Benchmark
Самый простой вариант:
1) веб изер = изер базы данных
2) запросы написаны в хмл на на серверы в виде( название , параметры)
Пример:
{query name="get.user.list.10" group="select/params/param[group]" }
{select limit="10"}
{filds}
{int name="id" from="users" /}
{/filds}
{where}
{eq name="group" from="users"}group{/eq}
{/where}
1) веб изер = изер базы данных
2) запросы написаны в хмл на на серверы в виде( название , параметры)
Пример:
{query name="get.user.list.10" group="select/params/param[group]" }
{select limit="10"}
{filds}
{int name="id" from="users" /}
{/filds}
{where}
{eq name="group" from="users"}group{/eq}
{/where}
Чем конструкция:
Hello, {{$object}}!
лучше чем
Hello, !
???
Мне больше по нутру шаблонизаторы с нативным синтаксисом - такой как Zend_View.
Hello, {{$object}}!
лучше чем
Hello, !
???
Мне больше по нутру шаблонизаторы с нативным синтаксисом - такой как Zend_View.
В сравнении не участвует vLib Templates, написанный на PHP. Он достаточно распространен, странно, что его не включили.
Содержит ли Blitz Templates механизмы кэширования и повторного вывода результатов при парсинге? Или это реализуется внешними средствами, не относящимся собственно к BLitz Templates?
И вопрос в общем - насколько важна скорость генерации страницы шаблонизатором отдельно и веб-приложения вообще? Просто где-то на Хабре некоторое время назад проскакивала мысль, что при значительных нагрузках на сайт скорость генерации страниц отходит на второй план, а становятся критичными механизмы кэширования и балансировки. В этом случае - есть ли разница между 600 и 800 запросов в секунду, если нужно, например, 10000 при тех же условиях?
Содержит ли Blitz Templates механизмы кэширования и повторного вывода результатов при парсинге? Или это реализуется внешними средствами, не относящимся собственно к BLitz Templates?
И вопрос в общем - насколько важна скорость генерации страницы шаблонизатором отдельно и веб-приложения вообще? Просто где-то на Хабре некоторое время назад проскакивала мысль, что при значительных нагрузках на сайт скорость генерации страниц отходит на второй план, а становятся критичными механизмы кэширования и балансировки. В этом случае - есть ли разница между 600 и 800 запросов в секунду, если нужно, например, 10000 при тех же условиях?
1. кеширование не входит в обязанности шаблонизатора
2. скорость важна только для проектов где всё затюнено и cpu usage на вебах начинает играть существенную роль.
2. скорость важна только для проектов где всё затюнено и cpu usage на вебах начинает играть существенную роль.
3. про vLib Templates - я конечно просто не в состоянии добавлять в тест вообще все шаблонизаторы, особенно те, с которыми не знаком сам. методика тестирования известна, код для тестирования есть - каждый может добавить туда свой любисый шаблонизатор (обычно это занимает минут 5-10) - присылаете мне, я гоню тест и обновляю. так на меня выходило несколько девелоперов и я добавлял движки какие они просили в тест
Интересует, как сделать такую вещь
если шаблонная переменная $news_next равна true, то выводим:
а если false, то ничего не выводим.
Когда пробывал Blitz, этого не получилось реализовать :(
Ведь такая фишка там непрокатит:
Что скажите ребята?
если шаблонная переменная $news_next равна true, то выводим:
<a href="{{ $news_url }}">Читать дальше</a>а если false, то ничего не выводим.
Когда пробывал Blitz, этого не получилось реализовать :(
Ведь такая фишка там непрокатит:
{{ if($news_next, "<a href=" $news_url ">Читать дальше</a>") }}Что скажите ребята?
делаем блок и итерируем его в коде view-контроллера.
в шаблоне <!-- BEGIN READ_MORE --><a href="{{ $news_url }}">Читать дальше</a><!-- END -->
в коде $View->block('READ_MORE', $vars);
спасибо
А вот кстати. Вопрос по взаимодействию верстальщика и программиста. Как решается классическая засада, когда в скрипте программер не знает, что такое READ_MORE - его в цикле итерировать или проверять на наличие данных?
Какой-то есть формальный протокол согласования, или просто работают в живом контакте?
Какой-то есть формальный протокол согласования, или просто работают в живом контакте?
конечно в живом контакте. программер не может этого не знать. он это знать обязан. в том и фишка. в этом случае программер ведёт таск, и фигни типа "а я все данные посетил пусть теперь вася захерачит шаблон" просто не будет.
Слушай, ты перевернул все мои представления о разделении труда верстальщика и программиста =) А можно хоть чуть-чуть поподробнее про это?
Почему подход "я все данные посЕтил" плохой? Речь идет о том самом облегчении труда верстальщика, который, в отличие от яндексовых верстал, совсем не морочится с логикой, а только чисто с хтмл/цсс?
Почему подход "я все данные посЕтил" плохой? Речь идет о том самом облегчении труда верстальщика, который, в отличие от яндексовых верстал, совсем не морочится с логикой, а только чисто с хтмл/цсс?
не плохой, но чреватый. начинает играт роль в больших проектах и куче мелких задач: в таком случае чем более размыта ответственность, тем хуже. эта логика отображения для девелопера просто семечки и он её делает ваще не замечая.
Круто. Спасибо, это очень интересная информация с совершенно неизвестной мне стороны.
А вот такой вопрос ещё, если можно. Отделяется ли у вас организационно этот контроллерот мотороллера шаблона? Или органично лежит в остальном коде? Теоретически - должно разделяться, но интересует именно опять ваш практический опыт =)
А вот такой вопрос ещё, если можно. Отделяется ли у вас организационно этот контроллер
никак не пойму что же народ так любит это извращение над самым сильным шаблонизатором(я имею ввиду только мир PHP, в других языках свое наверно) - PHP. сам пых изначально был создан как шаблонизатор и сейчас с этой задачей справляется на отлично.
какой смысл писать на псевдо языке, который потом переводиться в PHP код?
использование шаблонизаторов очень помогает, не зависимо от того сколько надору работает над проектом и есть ли там разделение на прогера и на дизигнера (по крайней мере несколько лет приходиться делать достаточно крупные проекты не имея не только дизигнера, но кого-либо еще - максимум - еще один программист).
пробовал смарти - наверно он так убил во мне какое либо желание смотреть на эти шаблонизаторы на псевдо языке. не пробовал других(и Blitz Templates в часности). пытался найти чтото проще смарти(мне, как программисту на PHP, не очень хотелось учить другой синтаксис, к тому же я хотел автокомплита и поддержки подсветки) - но, после неуспешных поисков чего-либо удобоваримого и, самое главное, не перегруженного - решил написать свой. А после того как "познакомился" с токенайзером PHP - вообще сомнений не осталось. затратив неделю - теперь тока один плюсы (да еще и в 8К кода уложился).
Ну чем вам PHP то не нравиться?
Какая разница, что учить девелоперу - PHP синтаксис, Smarty синтаксис или еще какой?
P.S.
использование стандартного(Blitz Templates, Smarty etc) шаблонизатора (пусть и не самого удобного) хорошо наверно только при разработке проекта в какой либо студии и потом передача его другим людям. сказать - код написан на этом, шаблоны написаны на этом - нате, получите и распишитесь.
не даром, при поиске на работу верстальщика(вроде, могу ошибаться в проффесии) иногда указывают , например, smarty.
какой смысл писать на псевдо языке, который потом переводиться в PHP код?
использование шаблонизаторов очень помогает, не зависимо от того сколько надору работает над проектом и есть ли там разделение на прогера и на дизигнера (по крайней мере несколько лет приходиться делать достаточно крупные проекты не имея не только дизигнера, но кого-либо еще - максимум - еще один программист).
пробовал смарти - наверно он так убил во мне какое либо желание смотреть на эти шаблонизаторы на псевдо языке. не пробовал других(и Blitz Templates в часности). пытался найти чтото проще смарти(мне, как программисту на PHP, не очень хотелось учить другой синтаксис, к тому же я хотел автокомплита и поддержки подсветки) - но, после неуспешных поисков чего-либо удобоваримого и, самое главное, не перегруженного - решил написать свой. А после того как "познакомился" с токенайзером PHP - вообще сомнений не осталось. затратив неделю - теперь тока один плюсы (да еще и в 8К кода уложился).
Ну чем вам PHP то не нравиться?
Какая разница, что учить девелоперу - PHP синтаксис, Smarty синтаксис или еще какой?
P.S.
использование стандартного(Blitz Templates, Smarty etc) шаблонизатора (пусть и не самого удобного) хорошо наверно только при разработке проекта в какой либо студии и потом передача его другим людям. сказать - код написан на этом, шаблоны написаны на этом - нате, получите и распишитесь.
не даром, при поиске на работу верстальщика(вроде, могу ошибаться в проффесии) иногда указывают , например, smarty.
Вот это да! Отличный шаблонизатор!
Зря я его недооценивал. :-)
Зря я его недооценивал. :-)
Все-таки никогда не понимал, и наверное так и не смогу понять смысл использования шаблонизаторов в php. Во всех моих проектах шаблонизатором был обычный include с созданием локального пространства имен. Имхо специальный псевдо-язык нужно только тогда, когда верстальщик настолько бестолков, что ему легче написать {{$a}} чем
Кроме того, бенчмарк вряд ли что-то доказывает. Неизвестно, что конкретно и как тестировалось. Нужно сильно постараться, чтобы убедить меня, что немаленький набор классов может работать быстрее нативной php-функции.
Известно. Просто Вы не читали ;)
Что касается немаленького набора классов - в контексте того, что blitz это модуль к PHP на Си я не очень понимаю вопроса о "нативный" функциях. Рациональное зерно однако в Ваших рассуждениях есть, но следует четко понимать все-таки на что тратится время. Если мы пишем шаблоны на обычном PHP, то есть условно говоря при сборке шаблонов задействованы лишь операции с переменными (то есть над памятью), то мы получим идеальную скорость. Такого обычно конечно же не происходит, мы бьём файлы на более мелкие, и стараемся как-то организовать наш код. Как только у нас появляются какие-нибудь инклюды - мы имеем оверхед на работу с файловой системой, пусть оно и оседает мгновенно в кеше - но если поизучать внимательнее, видно, что это несколько системных вызовов, которые конечно накапливаются в существенный довесок при сборке страницы, если она сложная. blitz не избавляет от этого, и blitz никогда не будет быстрее php mess, что я специально подчеркиваю с бенчмарках. Однако blitz позволяет не сильно "убить" систему при переходе на более грамотно организованный код в нагруженном проекте. Например, blitz позволяет компактно упаковать в один шаблон несколько независимых блоков, которые будут использованы при сборке, в то время как сделать такое на PHP "красиво" невозможно (либо это будут разные файлы - и потеря скорости, либо функции-хелперы, которые замешают PHP-код и HTML-код).
Что касается немаленького набора классов - в контексте того, что blitz это модуль к PHP на Си я не очень понимаю вопроса о "нативный" функциях. Рациональное зерно однако в Ваших рассуждениях есть, но следует четко понимать все-таки на что тратится время. Если мы пишем шаблоны на обычном PHP, то есть условно говоря при сборке шаблонов задействованы лишь операции с переменными (то есть над памятью), то мы получим идеальную скорость. Такого обычно конечно же не происходит, мы бьём файлы на более мелкие, и стараемся как-то организовать наш код. Как только у нас появляются какие-нибудь инклюды - мы имеем оверхед на работу с файловой системой, пусть оно и оседает мгновенно в кеше - но если поизучать внимательнее, видно, что это несколько системных вызовов, которые конечно накапливаются в существенный довесок при сборке страницы, если она сложная. blitz не избавляет от этого, и blitz никогда не будет быстрее php mess, что я специально подчеркиваю с бенчмарках. Однако blitz позволяет не сильно "убить" систему при переходе на более грамотно организованный код в нагруженном проекте. Например, blitz позволяет компактно упаковать в один шаблон несколько независимых блоков, которые будут использованы при сборке, в то время как сделать такое на PHP "красиво" невозможно (либо это будут разные файлы - и потеря скорости, либо функции-хелперы, которые замешают PHP-код и HTML-код).
Говоря об использовании инклудов в качестве шаблонизатора, я не имел в виду банально втыкать include(...) и все дела - естественно, некая логика для кэширования и оптимизации должна иметь место быть. Я говорю исключительно про, так сказать, front-end шаблонизатора - псевдо-язык, используемый в шаблонах. И вот как раз лучшей замены стандартному синтаксису в этом плане я не вижу.
стандартный синтаксис превращает сложный (по-настоящему) шаблон в мясо полное. это одна из самых больших удач и ошибок изобретателей PHP - дать девелоперу мешать HTML и PHP-код.
дайте, пожалуйста, ссылку на "по-настоящему сложный" шаблон
nda :)
Просто мне действительно интересно. Вдруг мои шаблоны, в которых верстальщик пока что отлично разбирается, на самом деле сложны совсем не по-настоящему.
ну я ж этого не говорил. что ваши, что не по-настоящему - нет, дело в другом. я вот, например, как только у меня перед глазами возникала конструкция вида switch или нескольких if/elseif, которые внутри разрываются добротным куском html, внутри которого тоже есть какие-то свои if - вот я всегда чуствовал себя крайне подавленным, смотря на такой код.
что касается примера - представьте себе, как выглядит шаблон примерно с такой историей. сначала это просто элемент списка с к раткой информацией по профайлу ползователя. затем, вы должны написать, сколько у этого человека фотографий, а если нет фотографий, то не писать. а потом ещё появилось видео - и над писать скока видео. или если он в онлайн или был не более стольких-то минут назад онлайн, то надо написать жирно - он щас онлайн, а если был тогда-то - то в другим оформлении был в онлайн тогда-то. а ещё есть хитрые посетители у них ваще неизвестно когда был онлайн по историческим причинам - им надо написать особенный текст. а ещё если ему можно отправить какую-нибудь "симпашку", или "мессадж" - и надо вывести такие иконки, но не всем. если вы аноним, а юзер выбрал с "анонимами не общаюсь!", тогда иконок быть не должно. и я могу продолжать бесконечно. это всё на какой-то чертов мелкий элемент списка юзеров.
что касается примера - представьте себе, как выглядит шаблон примерно с такой историей. сначала это просто элемент списка с к раткой информацией по профайлу ползователя. затем, вы должны написать, сколько у этого человека фотографий, а если нет фотографий, то не писать. а потом ещё появилось видео - и над писать скока видео. или если он в онлайн или был не более стольких-то минут назад онлайн, то надо написать жирно - он щас онлайн, а если был тогда-то - то в другим оформлении был в онлайн тогда-то. а ещё есть хитрые посетители у них ваще неизвестно когда был онлайн по историческим причинам - им надо написать особенный текст. а ещё если ему можно отправить какую-нибудь "симпашку", или "мессадж" - и надо вывести такие иконки, но не всем. если вы аноним, а юзер выбрал с "анонимами не общаюсь!", тогда иконок быть не должно. и я могу продолжать бесконечно. это всё на какой-то чертов мелкий элемент списка юзеров.
Все, что вы перечислили, можно отрезюмировать одной фразой - дофига условий. Рахве шаблонизатор может хоть как-то упростить задачу по ветвлению в шаблоне? Всяко нужно делать хоть какие-то if-ы - так не все ли равно, как они будут выглядеть, и действительно ли это так важно, чтобы терять полноценно интерпретируемый шаблон без багов и ограничений псевдо-языка?
хм. вообще все это конечно же фуфел по сравнению с мировой революцей, тут спору нет.
но смотрите сами условие внутри if, или ещё какая синтаксическая конструкция которую можно по-быстрому плюхнуть в код лишь бы работало - всё это может быть довольно сложным. а вы заменяете его на блок с именем WAS_ONLINE и вас совершенно не волнует чё там за условия. у вас нет даже возможности "наплодить". а тот код, который определяет, будет ли проитерирован данный контекст (то есть появится ли один из нескольких кусочков кода, которые много от чего зависят) - он не смешан с HTML совсем. в нем легко что-то поправить. никакая программерская логика - будь то логика отображения, или любой другой код - никогда не будет идти рядом с HTML. помню, я как-то пытался уже это объяснить. мне пришлось закончить словами примерно такими - понимаешь, это своего рода философия и ты либо её разделяешь, либо просто не понимаешь, почему это имеет какое-то значение
но смотрите сами условие внутри if, или ещё какая синтаксическая конструкция которую можно по-быстрому плюхнуть в код лишь бы работало - всё это может быть довольно сложным. а вы заменяете его на блок с именем WAS_ONLINE и вас совершенно не волнует чё там за условия. у вас нет даже возможности "наплодить". а тот код, который определяет, будет ли проитерирован данный контекст (то есть появится ли один из нескольких кусочков кода, которые много от чего зависят) - он не смешан с HTML совсем. в нем легко что-то поправить. никакая программерская логика - будь то логика отображения, или любой другой код - никогда не будет идти рядом с HTML. помню, я как-то пытался уже это объяснить. мне пришлось закончить словами примерно такими - понимаешь, это своего рода философия и ты либо её разделяешь, либо просто не понимаешь, почему это имеет какое-то значение
Нет-нет.
Я не прошу объяснять, зачем нужны шаблонизаторы. И я вроде как знаю, что такое отделение логики от представления. Я хочу узнать (упрощенно), чем конструкция {{BEGIN} WAS_ONLINE} ... {{END}} проще конструкции <?if($was_online):?> ... <?endif;?>
Я не прошу объяснять, зачем нужны шаблонизаторы. И я вроде как знаю, что такое отделение логики от представления. Я хочу узнать (упрощенно), чем конструкция {{BEGIN} WAS_ONLINE} ... {{END}} проще конструкции <?if($was_online):?> ... <?endif;?>
да я вроде как и объясняю - далеко не все условия такие простые, как Вашем примере. В Вашем примере - ничем.
Я хочу узнать (упрощенно), чем конструкция {{BEGIN} WAS_ONLINE} ... {{END}} проще конструкции <?if($was_online):?> ... <?endif;?>
тут скорее надо привести пример такой:
чем конструкция {WAS_ONLINE} проще конструкции <?include($was_online);? >
И, тем не менее, шаблон у "блочного" шаблонизатора (к которым относится Блиц) по определению всегда будет выглядить проще. За счет того, что на самом деле он состоит из двух частей - собственно шаблона и скрипта-обработчика. Как пример могу привести то же самое дерево: выделяем строчку HTML в блок и обрабатываем его рекурсивно. В "логическом" же шаблонизаторе дерево - pain in the..., скажем, head.
Классическая задача - вывести небольшое дерево. Карту сайта или, скажем, меню с подменю одного уровня. С выделением текущего раздела. HTML кода будет меньше, чем PHP (или любого другого, при использовании любого шаблонизатора)
А как эта задача решается, например, в Блитце? Выделяется блок для итерирования, понятно - что дальше?
Увы,я не пользуюсь Блицем, мой выбор - PHP-native =)
Я исхожу из общих представлений о шаблонизаторах его семейства. Выделяется блок, и скрипт-обработчик рекурсивно обходит данные, заполняя его. В самом простом варианте - корректно открывая и закрывая <ul>
Я исхожу из общих представлений о шаблонизаторах его семейства. Выделяется блок, и скрипт-обработчик рекурсивно обходит данные, заполняя его. В самом простом варианте - корректно открывая и закрывая <ul>
Что мешает аналогичным образом создать переменную ("блок") в php-шаблоне и аналогичным образом обойти его в скрипте?
Усложнением интаксиса, наверное.
Тема, кстати, важная и интересная. Достойная, на мой взгляд, отдельного обсуждения. Вот все говорят - PHP-native, но подходы-то ведь у всех наверняка разные! Слишком большой язык. Слишком велик соблазн скатиться к той же лапше, от которой хотели уйти.
Мой подход - сознательное ограничение используемого в шаблонах синтаксиса. Жёсткое. В частности, $var= <<<HTML... мне, признаюсь, в страшном сне не приснится.
Мне предлагали функцию сделать. Это тоже представляется неподходящим для шаблона. Как и строковые замены с последующим eval-ом вместо инклюда.
А другие способы организовать блок мне не приходят в голову.
Тема, кстати, важная и интересная. Достойная, на мой взгляд, отдельного обсуждения. Вот все говорят - PHP-native, но подходы-то ведь у всех наверняка разные! Слишком большой язык. Слишком велик соблазн скатиться к той же лапше, от которой хотели уйти.
Мой подход - сознательное ограничение используемого в шаблонах синтаксиса. Жёсткое. В частности, $var= <<<HTML... мне, признаюсь, в страшном сне не приснится.
Мне предлагали функцию сделать. Это тоже представляется неподходящим для шаблона. Как и строковые замены с последующим eval-ом вместо инклюда.
А другие способы организовать блок мне не приходят в голову.
Если говорить про синтаксис - да. Хотя лично мне конструкция
$var = <<<HTML
много хтмла
HTML;
кажется ничуть не сложнее и уродливей, чем
{{BEGIN} var}
много хтмла
{{END}}
или какая угодно другая подобного типа.
Но вы правы, это действительно обсуждение отдельное и, по сути, в данном топике - оффтоп.
$var = <<<HTML
много хтмла
HTML;
кажется ничуть не сложнее и уродливей, чем
{{BEGIN} var}
много хтмла
{{END}}
или какая угодно другая подобного типа.
Но вы правы, это действительно обсуждение отдельное и, по сути, в данном топике - оффтоп.
Рискну, всё же, возразить.
Дело в том, что для блочного шаблонизатора конструкция
{{BEGIN name}}{{END}} - стандартная сущность. Для PHP native же это добавление новой.
В этом ведь и состоит, на мой взгляд, главная привлекательность "блочных" шаблонов - предельная простота синтаксиса. Блоки да переменные - больше ничего и не надо.
Именно таких случаев я и боюсь, когда для каждой новой задачи в шаблон вносится новый синтаксический элемент, и в результате - ...
Дело в том, что для блочного шаблонизатора конструкция
{{BEGIN name}}{{END}} - стандартная сущность. Для PHP native же это добавление новой.
В этом ведь и состоит, на мой взгляд, главная привлекательность "блочных" шаблонов - предельная простота синтаксиса. Блоки да переменные - больше ничего и не надо.
Именно таких случаев я и боюсь, когда для каждой новой задачи в шаблон вносится новый синтаксический элемент, и в результате - ...
> Если говорить про синтаксис - да. Хотя лично мне
> конструкция
> $var = ...
> кажется ничуть не сложнее и уродливей, чем
>{{BEGIN} var}
имхо, есть разница.
первый вариант вы вбиваете в PHP код. второй там вообще не появляется, он есть только в HTML шаблоне. в итоге код читается легко, шаблон тоже. а в первом варианте получается винигрет из кода и HTML - пугает именно винигрет :)
> конструкция
> $var = ...
> кажется ничуть не сложнее и уродливей, чем
>{{BEGIN} var}
имхо, есть разница.
первый вариант вы вбиваете в PHP код. второй там вообще не появляется, он есть только в HTML шаблоне. в итоге код читается легко, шаблон тоже. а в первом варианте получается винигрет из кода и HTML - пугает именно винигрет :)
На первых порах может быть не совсем очевидно, зачем нужен Blitz для php, в то время, когда этот язык, по сути дела, и есть шаблонизатор, только весьма навороченный.
улыбнуло (:
Эх, где ж оно раньше было!?.. годочка, эдак, 4 назад. Я бы эту штуковину заюзал с превеликой радостью. А сейчас уже поздняк.
Странно давно следить за шаблонизаторами... такое ощущение что оgять 2000 год на улице.
php сам по себе прекрасный шаблонизатор велика ли разница или {LOGIN}
А учить новую семантику шаблонизаторов, которые используются в разных проектах...бред.
Не лучше ли выучить один раз верстальщику основы php за 1 день чем от проекта к проекту учить новые шаблонизаторы...
Лучше обратить внимание контроллеры и вывод данных CVS... и нудить больше по этому поводу,
а как их потом обрабатывать... пусть решают сами...
php сам по себе прекрасный шаблонизатор велика ли разница или {LOGIN}
А учить новую семантику шаблонизаторов, которые используются в разных проектах...бред.
Не лучше ли выучить один раз верстальщику основы php за 1 день чем от проекта к проекту учить новые шаблонизаторы...
Лучше обратить внимание контроллеры и вывод данных CVS... и нудить больше по этому поводу,
а как их потом обрабатывать... пусть решают сами...
Может заключим с Вами соглашение? Вы будете готовить программистов за 1 день, и если они будут соответствовать нашим требованиям, мы будем Вам платить гонорар, соразмерный размеру их ежемесячного вознаграждения?
Нам очень нужны разработчики.
Нам очень нужны разработчики.
Я написал верстальщика - раз, второе - основы php, это разные вещи...
основы php можно выучить за 1 день...
Проверял лично... не на себе конечно :)
Но сын 10 лет за 2 часа уже понимал основы php и с успехом решал маленькие поставленные задачи, соизмеримые с верстанием ...
Это 10 летний сын, который о программировании и не знает ничего вообще кроме школьной программы.
Если вы набираете неучей ксебе, то их ежемесечное вознаграждение не покроют мои знания :)
основы php можно выучить за 1 день...
Проверял лично... не на себе конечно :)
Но сын 10 лет за 2 часа уже понимал основы php и с успехом решал маленькие поставленные задачи, соизмеримые с верстанием ...
Это 10 летний сын, который о программировании и не знает ничего вообще кроме школьной программы.
Если вы набираете неучей ксебе, то их ежемесечное вознаграждение не покроют мои знания :)
Начал тестировать, уже даже смирился с отсутствием смарти-подобных if'ов и циклов. Но пустые строки между "row #" при переносе содержимого блока на новую строку:
{{ BEGIN row }}
row #{{ $i }}
{{ END }}
просто раздражают:-) Весь исходный код страницы портится. А оставлять объявление блока и первую строку содержимого блока на одной строке - рука не поднимается. Надеюсь, в будущем это нарушение эстетики будет ликвидировано
{{ BEGIN row }}
row #{{ $i }}
{{ END }}
просто раздражают:-) Весь исходный код страницы портится. А оставлять объявление блока и первую строку содержимого блока на одной строке - рука не поднимается. Надеюсь, в будущем это нарушение эстетики будет ликвидировано
А существует какая-то обратная связь кроме багтрека? То ли багу нашел, то ли мануал недопонял, хотелось бы узнать у fisher'a, но не знаю, куда писать. Тут все-таки не форум:-)
Будет ли возможность шаблоны в БД хранить, а не в файлах (Шаблон->include->uid).
Сейчас выбираю шаблонизатор, Blitz самым подходящим оказался - у нас некоторые пользователи сайта могут создавать свои View, для отображения информации - получилось так, что в базе шаблоны хранить удобнее чем в виде файлов.
Сейчас выбираю шаблонизатор, Blitz самым подходящим оказался - у нас некоторые пользователи сайта могут создавать свои View, для отображения информации - получилось так, что в базе шаблоны хранить удобнее чем в виде файлов.
хотел поинтересовать вот на счет такой фичи: как подружить PEAR HTML_QuickForm && Blitz ?
для шаблонизаторов: HTML_Template_Flexy, HTML_Template_IT, HTML_Template_Sigma, Smarty есть така возмлжность.
для шаблонизаторов: HTML_Template_Flexy, HTML_Template_IT, HTML_Template_Sigma, Smarty есть така возмлжность.
А на обычный шаренный хостинг как это поставить?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Blitz Templates