-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
blitz templates - теперь на sf.net
- Автор темы fisher
- Дата начала
Develar
Новичок
Можно скачать с http://sourceforge.net/project/showfiles.php?group_id=188147&package_id=219988&release_id=507872, в папке doc документация. Проект развивается - последний релиз 12 мая.
crocodile2u
http://vbolshov.org.ru
В продолжение тему об инклюдах..
Инклюды тупят, спору нет. Но помогают добиться лучшей структуризации кода. Вопрос: как решается проблема инклюдов/производительности в блиц? Интересует следующий тест по производительности:
шаблон с несколькими инклюдами на NativePHP vs схожий шаблон с несколькими же инклюдами на блиц (при этом я, конечно, понимаю, что инклюд в блиц это свосем не то же самое, что инклюд в пхп
).
А так, за проектом блиц я (не слишком активно, правда) наблюдаю уже давно, видимо, со времен первых упоминаний о нем, и, по-моему, это действительно хороший проект. Пока что, впрочем, сам предпочитаю NativePHP-шаблоны с поддержкой хелперов - это помогает значительно уменьшить количество инклюдов и повысить структурированность кода.
Инклюды тупят, спору нет. Но помогают добиться лучшей структуризации кода. Вопрос: как решается проблема инклюдов/производительности в блиц? Интересует следующий тест по производительности:
шаблон с несколькими инклюдами на NativePHP vs схожий шаблон с несколькими же инклюдами на блиц (при этом я, конечно, понимаю, что инклюд в блиц это свосем не то же самое, что инклюд в пхп
).А так, за проектом блиц я (не слишком активно, правда) наблюдаю уже давно, видимо, со времен первых упоминаний о нем, и, по-моему, это действительно хороший проект. Пока что, впрочем, сам предпочитаю NativePHP-шаблоны с поддержкой хелперов - это помогает значительно уменьшить количество инклюдов и повысить структурированность кода.
fisher
накатила суть
в blitz есть include похожий на include в php, а есть непохожий.
1) $T->include('some.tpl', $globals) - откроет отдельный файл, распарсит, жахнет туда глобальные переменные и отдаст результат. такая же операция есть в самом шаблоне {{ include('some.tpl'); }}
2) в базовом шаблоне делаешь блок, который по умолчанию не итерируется, а потом "фетчишь" это дело:
main.tpl
{{ BEGIN online }} online! {{ END }}
{{ BEGIN offline }} was online {{ $n }} {{ BEGIN h }}hours{{ END }}{{ BEGIN d }}days{{ END }}{{ BEGIN m }}months{{ END }} ago {{ END }}
{{ BEGIN away }} away... {{ END }}
php code
$T = new Blitz('main.tpl');
// online
echo $T->fetch('online')."\n";
// away
echo $T->fetch('away')."\n";
$T->context('offline');
// 15 days ago
$T->iterate('d');
echo $T->fetch('offline', array('n' => 15))."\n";
// 2 months ago
$T->iterate('m');
echo $T->fetch('offline', array('n' => 2))."\n";
output
online!
away...
was online 15 days ago
was online 2 months ago
по скорости инклюд чуть медленее, чем фетч - просто потому что надо дергать отдельный файл. на самом деле там разница имхо не принуипиальна. но php с акселератором и includes в любом случае пока будет чуть быстрее.
струкрутрированностьчерез "блоки" - читай отдельный контексты, которые ты фетчишь в зависимости от ситуации - он по производительности лучше, потому что все блоки ты пихаешь в один файл. а в php так сделать не через жопу не получится.
>>NativePHP-шаблоны с поддержкой хелперов - это помогает значительно уменьшить количество инклюдов
можешь пояснить, о чем ты?
1) $T->include('some.tpl', $globals) - откроет отдельный файл, распарсит, жахнет туда глобальные переменные и отдаст результат. такая же операция есть в самом шаблоне {{ include('some.tpl'); }}
2) в базовом шаблоне делаешь блок, который по умолчанию не итерируется, а потом "фетчишь" это дело:
main.tpl
{{ BEGIN online }} online! {{ END }}
{{ BEGIN offline }} was online {{ $n }} {{ BEGIN h }}hours{{ END }}{{ BEGIN d }}days{{ END }}{{ BEGIN m }}months{{ END }} ago {{ END }}
{{ BEGIN away }} away... {{ END }}
php code
$T = new Blitz('main.tpl');
// online
echo $T->fetch('online')."\n";
// away
echo $T->fetch('away')."\n";
$T->context('offline');
// 15 days ago
$T->iterate('d');
echo $T->fetch('offline', array('n' => 15))."\n";
// 2 months ago
$T->iterate('m');
echo $T->fetch('offline', array('n' => 2))."\n";
output
online!
away...
was online 15 days ago
was online 2 months ago
по скорости инклюд чуть медленее, чем фетч - просто потому что надо дергать отдельный файл. на самом деле там разница имхо не принуипиальна. но php с акселератором и includes в любом случае пока будет чуть быстрее.
струкрутрированностьчерез "блоки" - читай отдельный контексты, которые ты фетчишь в зависимости от ситуации - он по производительности лучше, потому что все блоки ты пихаешь в один файл. а в php так сделать не через жопу не получится.
>>NativePHP-шаблоны с поддержкой хелперов - это помогает значительно уменьшить количество инклюдов
можешь пояснить, о чем ты?
Гравицапа
elbirret elcno
Видимо имеется в виду как реализуются, например, View и Helpers в CakePHP
http://manual.cakephp.org/chapter/views
http://manual.cakephp.org/chapter/helpers
Давайте, действительно, не уходить от темы про blitz
Продолжение про хелперы здесь: http://phpclub.ru/talk/showthread.php?s=&threadid=99689
Продолжение про хелперы здесь: http://phpclub.ru/talk/showthread.php?s=&threadid=99689
fisher
накатила суть
привет! вы можете помочь проекту, проголосовав за него в номинации best new project
-~{}~ 05.07.07 11:52:
в очередной версии -0.4.19 - помимо незначительных багфиксов появились такие методы как getStruct, getGlobals и getIterations (для нелюбителей camel caps разумеется есть алиасы - get_struct, get_globals, get_iterations). все они не только заменяют отладочные dump* методы, но также позволяют сохранять и подменять все assigned параметры на лету. это дает ряд интересных возможностей. во-первых, это упрощает тестирование view для тех маньяков, которые этим занимаются. во-вторых, если вы по какой-то причине хотите воспроизвести "ровно ту ситуацию, когда юзер заметил баг", и вам не важно откуда были получены данные, а нужно просто знать, что было передано в шаблоны - достаточно будет научить ваше приложение сохранять внутренности шаблонов и смотреть сохранённые ранее снепшоты. для новой версии также есть модуль под винду, правда для php-5.2.0 - если оно несовместимо с более старшими php-5.2.* - напишите мне, плз.
-~{}~ 05.07.07 11:52:
в очередной версии -0.4.19 - помимо незначительных багфиксов появились такие методы как getStruct, getGlobals и getIterations (для нелюбителей camel caps разумеется есть алиасы - get_struct, get_globals, get_iterations). все они не только заменяют отладочные dump* методы, но также позволяют сохранять и подменять все assigned параметры на лету. это дает ряд интересных возможностей. во-первых, это упрощает тестирование view для тех маньяков, которые этим занимаются. во-вторых, если вы по какой-то причине хотите воспроизвести "ровно ту ситуацию, когда юзер заметил баг", и вам не важно откуда были получены данные, а нужно просто знать, что было передано в шаблоны - достаточно будет научить ваше приложение сохранять внутренности шаблонов и смотреть сохранённые ранее снепшоты. для новой версии также есть модуль под винду, правда для php-5.2.0 - если оно несовместимо с более старшими php-5.2.* - напишите мне, плз.
juks
Новичок
Пример. Нужно вывести некий список, основанный на массиве хешей.
Массив хешей возвращается некоторым методом объекта. У его элементов нет ключей, определяющих номер элемента, признак первого элемента массива, признак чётного элемента массива. А всё это часто полезно знать в шаблоне при построении документа.
Получается, что надо создавать цикл, в котором будет перебираться исходный массив, так чтобы в его элементы добавлялись новые ключи. По-моему это в чистом виде overhead, потому как массив потом ещё раз будет перебираться в шаблонизаторе.
Кроме того, это увеличивает громоздкость php-кода и усложняет процесс разработки. Верстальщик будет постоянно обращаться к програмисту с просьбой добавить те или иные примитивные свойства в передаваемые данные.
Получается, что логика, свойственная исключительно макету, то есть шаблону, попадает в приложение.
Ну, и без if(a < b) тоже тяжело.
Как, на Ваш взгляд, нужно решать задачу, скажем, когда в шаблоне нужно вывести список, при этом обозначить особыми стилями первый и последние элементы, чётные и нечётные и выбранный пользователем элемент?
Для perl есть очень хороший шаблонизатор — Toolkit Template, хотя бы что-то близкое найти для php... Я, разумеется, понимаю разницу в актуальности щаблонизатора для perl и для php, но тем не менее.
Надо бы добавить, что считаю оптимальным тот вариант, когда шаблон получает/отдаёт данные через набор методов приложения, передавая в них нужные параметры, а потом уже раскручивает результат на свой вкус. Когда программист начитает втыкать в то, что нужно верстальщику, работа становится метее продуктивной. Работал с этим, знаю.
Массив хешей возвращается некоторым методом объекта. У его элементов нет ключей, определяющих номер элемента, признак первого элемента массива, признак чётного элемента массива. А всё это часто полезно знать в шаблоне при построении документа.
Получается, что надо создавать цикл, в котором будет перебираться исходный массив, так чтобы в его элементы добавлялись новые ключи. По-моему это в чистом виде overhead, потому как массив потом ещё раз будет перебираться в шаблонизаторе.
Кроме того, это увеличивает громоздкость php-кода и усложняет процесс разработки. Верстальщик будет постоянно обращаться к програмисту с просьбой добавить те или иные примитивные свойства в передаваемые данные.
Получается, что логика, свойственная исключительно макету, то есть шаблону, попадает в приложение.
Ну, и без if(a < b) тоже тяжело.
Как, на Ваш взгляд, нужно решать задачу, скажем, когда в шаблоне нужно вывести список, при этом обозначить особыми стилями первый и последние элементы, чётные и нечётные и выбранный пользователем элемент?
Для perl есть очень хороший шаблонизатор — Toolkit Template, хотя бы что-то близкое найти для php... Я, разумеется, понимаю разницу в актуальности щаблонизатора для perl и для php, но тем не менее.
-~{}~ 21.07.07 01:43:
Надо бы добавить, что считаю оптимальным тот вариант, когда шаблон получает/отдаёт данные через набор методов приложения, передавая в них нужные параметры, а потом уже раскручивает результат на свой вкус. Когда программист начитает втыкать в то, что нужно верстальщику, работа становится метее продуктивной. Работал с этим, знаю.
вообще это все решается мааленьким таким патчем на blitz - если ввести переменную, которая содержит имя текущего блока.
тогда можно делать всякие хитрожопые методы в наследниках
хотя это все изврат.
а в целом, я бы скорее сказал, что если верстальщику дать хоть сколь либо богатый синтаксис, то шаблоны превратятся в месиво.
-~{}~ 21.07.07 03:20:
>Получается, что логика, свойственная исключительно макету, то есть шаблону, попадает в приложение.
а потому что не надо в приложении мешать view-логику и прочее.
шаблон - это еще не view
смарти объединяет view-логику и шаблон, это не единственный возможный подход. о том, какой лучше, предлагаю не спорить - it depends разумеется.
тогда можно делать всякие хитрожопые методы в наследниках
хотя это все изврат.
а в целом, я бы скорее сказал, что если верстальщику дать хоть сколь либо богатый синтаксис, то шаблоны превратятся в месиво.
-~{}~ 21.07.07 03:20:
>Получается, что логика, свойственная исключительно макету, то есть шаблону, попадает в приложение.
а потому что не надо в приложении мешать view-логику и прочее.
шаблон - это еще не view
смарти объединяет view-логику и шаблон, это не единственный возможный подход. о том, какой лучше, предлагаю не спорить - it depends разумеется.
fisher
накатила суть
отчасти вы правы, но если подробнее, то
>>Получается, что логика, свойственная исключительно макету, то
>>есть шаблону, попадает в приложение
да-да, согласен с фиксером, вы путаете бизнес-логику и view-логику. в blitz view-логика принудительно будет на языке программирования, не на языке шаблона, чтобы не создавать говно в сложном коде.
>>Верстальщик будет постоянно обращаться к програмисту
если такая простая горизонтальная коммуникация является проблемой - надо что-то крутить в консерватории. или заставтье программиста делать прототип, а верстальщика наводить красоту. для меня важно: верстальщик верстает, не программирует. программирует программист. опять же - это мое мнение, кому что нравится. мне такой процесс просто очень сильно по душе.
>>По-моему это в чистом виде overhead
это так. заведите отдельный тред, или напишите мне в багтрак какие именно переменные "по умолчанию" вы хотели бы видеть. подумаем, как реализовать (http://alexeyrybak.com/blitz/bt/my_view_page.php)
>>Получается, что логика, свойственная исключительно макету, то
>>есть шаблону, попадает в приложение
да-да, согласен с фиксером, вы путаете бизнес-логику и view-логику. в blitz view-логика принудительно будет на языке программирования, не на языке шаблона, чтобы не создавать говно в сложном коде.
>>Верстальщик будет постоянно обращаться к програмисту
если такая простая горизонтальная коммуникация является проблемой - надо что-то крутить в консерватории. или заставтье программиста делать прототип, а верстальщика наводить красоту. для меня важно: верстальщик верстает, не программирует. программирует программист. опять же - это мое мнение, кому что нравится. мне такой процесс просто очень сильно по душе.
>>По-моему это в чистом виде overhead
это так. заведите отдельный тред, или напишите мне в багтрак какие именно переменные "по умолчанию" вы хотели бы видеть. подумаем, как реализовать (http://alexeyrybak.com/blitz/bt/my_view_page.php)
juks
Новичок
Написал.
Я не говорю, что надо до упора развивать шаблонизатор до уровня языка программирования. Хорошо найти золотую середину. Я имею опыт работы в одном из крупнейших наших интернет-порталов и уверен, что хотя бы в отношении циклов можно было бы внести некоторые усовершенствования.
Ваш проект вполне может стать лучшим в этой области. Постараемся его поддержать, если удастся реализовать на нём новый проект. Моменты про которые я говорю — единственное, что вносит неоднозначность в принятии решения.
Кстати, не знакомы ли Вы с этим проектом?
http://teng.sourceforge.net/
Занятный, но, вероятно, заброшен и мне не удалось его собрать для php 5.
Я не говорю, что надо до упора развивать шаблонизатор до уровня языка программирования. Хорошо найти золотую середину. Я имею опыт работы в одном из крупнейших наших интернет-порталов и уверен, что хотя бы в отношении циклов можно было бы внести некоторые усовершенствования.
Ваш проект вполне может стать лучшим в этой области. Постараемся его поддержать, если удастся реализовать на нём новый проект. Моменты про которые я говорю — единственное, что вносит неоднозначность в принятии решения.
Кстати, не знакомы ли Вы с этим проектом?
http://teng.sourceforge.net/
Занятный, но, вероятно, заброшен и мне не удалось его собрать для php 5.
AnToXa
prodigy-одаренный ребенок
простите что вмешиваюсь, но я нашел замечательное.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
--
juks, это была просьба к вам.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
--
juks, это была просьба к вам.
fisher
накатила суть
juks
нет, не знаком. по реквесту - подумаем, как реализовать. если строго, то в тупую не получится, по-быстрому можно сделать только first, number и even. без предварительного прохода по массиву не будут известны total и last - blitz не запрещает смешать текстовые и строковые ключи на одном уровне итерации (такая есть недокументироанная фича, а при смешивании просто будет warning, что строковый ключ игнорирован). с другой стороны, я полагаю, на на это можно задвинуть: типа, сами себе буратины, если ошиблись, в прошакшн такого не будет, и тогда просто оценивать по общему количеству элементов.
нет, не знаком. по реквесту - подумаем, как реализовать. если строго, то в тупую не получится, по-быстрому можно сделать только first, number и even. без предварительного прохода по массиву не будут известны total и last - blitz не запрещает смешать текстовые и строковые ключи на одном уровне итерации (такая есть недокументироанная фича, а при смешивании просто будет warning, что строковый ключ игнорирован). с другой стороны, я полагаю, на на это можно задвинуть: типа, сами себе буратины, если ошиблись, в прошакшн такого не будет, и тогда просто оценивать по общему количеству элементов.