blitz templates - теперь на sf.net
- Автор темы fisher
- Дата начала
fisher
накатила суть
если делать по-умному, то нужен парсер выражений. всё это не сложно, но нужно время, потому что никаких выражений в blitz вообще нельзя - специально. впрочем, я так и думал, что со временем что-нибудь понадобится 
есть второй вариант более простой для реализации но более кривой для языка в целом, добавить пяток методов, расширяющих функционал метода if:
ife($a1,$a2,$yes[,$no]); $a1 == $a2
ifg($a1,$a2,$yes,[,$no]) $a1>$a2
ifge($a1,$a2,$yes[,$no]) $a1>=$a2
и аналогично ifl, ifle
но уж лучше я сделаю пасрер выражений
есть второй вариант более простой для реализации но более кривой для языка в целом, добавить пяток методов, расширяющих функционал метода if:
ife($a1,$a2,$yes[,$no]); $a1 == $a2
ifg($a1,$a2,$yes,[,$no]) $a1>$a2
ifge($a1,$a2,$yes[,$no]) $a1>=$a2
и аналогично ifl, ifle
но уж лучше я сделаю пасрер выражений
Gorynych
Посетитель PHP-Клуба
fisher
а нет опасения, что пойдя на поводу у желающих расширения логики, можно получить еще один Smarty?
пока blitz все еще похож на минимально-необходимый способ абстракции, но личо для меня ключевое слово тут - минимально. Потому что тот же Smarty, это отличный тормоз для действительно нагруженных проектов.
а нет опасения, что пойдя на поводу у желающих расширения логики, можно получить еще один Smarty?
пока blitz все еще похож на минимально-необходимый способ абстракции, но личо для меня ключевое слово тут - минимально. Потому что тот же Smarty, это отличный тормоз для действительно нагруженных проектов.
fisher
накатила суть
>>PhpNG
что это такое?
>>а нет опасения, что пойдя на поводу у желающих
>>расширения логики
да разумеется, есть. я даже помню была года два назад дискуссия где я пеной у рта пытался доказать, что контексты - зло, потому что сложно для среднего ума и blitz обойдется и без них, но потом я всё-таки понял, что без них никак это я к тому что и я ошибаюсь в своем консерватизме. так что если делать с умом и не всё подряд - то почему нет
-~{}~ 22.07.07 17:08:
>>отличный тормоз для действительно нагруженных проектов
да, и у меня есть робкое подозрение, что даже если взять и реализовать функционал smarty в виде модуля, то это уже не будет таким тормозом. но в любом случае повторения функционала smarty в blitz не будет.
-~{}~ 23.07.07 01:26:
в последнем релизе 0.4.23 добавлено наследование итераций при использовании директивы include в шаблонах. грубо говоря, если зовете Include одного шаблона из другого то вызываемый шаблон наследует итерации того контекста, в котором его подключали. лучше всего это хозяйство иллюстрирует пример
include_ctx.tpl:
{{ begin test1 }} v={{ $var }} {{ end }}
{{ begin test2 }} v={{ $var }} {{ end }}
code:
<?
$T = new Blitz();
$T->load('{{ include("include_ctx.tpl") }}');
$i = 0;
while ($i<5) {
$T->block('/test1', array('var' => $i), TRUE);
$T->block('/test2', array('var' => $i), TRUE);
$i++;
}
echo $T->parse();
?>
result:
v=0 v=1 v=2 v=3 v=4
v=0 v=1 v=2 v=3 v=4
что это такое?
>>а нет опасения, что пойдя на поводу у желающих
>>расширения логики
да разумеется, есть. я даже помню была года два назад дискуссия где я пеной у рта пытался доказать, что контексты - зло, потому что сложно для среднего ума и blitz обойдется и без них, но потом я всё-таки понял, что без них никак
это я к тому что и я ошибаюсь в своем консерватизме. так что если делать с умом и не всё подряд - то почему нет -~{}~ 22.07.07 17:08:
>>отличный тормоз для действительно нагруженных проектов
да, и у меня есть робкое подозрение, что даже если взять и реализовать функционал smarty в виде модуля, то это уже не будет таким тормозом. но в любом случае повторения функционала smarty в blitz не будет.
-~{}~ 23.07.07 01:26:
в последнем релизе 0.4.23 добавлено наследование итераций при использовании директивы include в шаблонах. грубо говоря, если зовете Include одного шаблона из другого то вызываемый шаблон наследует итерации того контекста, в котором его подключали. лучше всего это хозяйство иллюстрирует пример
include_ctx.tpl:
{{ begin test1 }} v={{ $var }} {{ end }}
{{ begin test2 }} v={{ $var }} {{ end }}
code:
<?
$T = new Blitz();
$T->load('{{ include("include_ctx.tpl") }}');
$i = 0;
while ($i<5) {
$T->block('/test1', array('var' => $i), TRUE);
$T->block('/test2', array('var' => $i), TRUE);
$i++;
}
echo $T->parse();
?>
result:
v=0 v=1 v=2 v=3 v=4
v=0 v=1 v=2 v=3 v=4
fisher
накатила суть
>>А сколько может пройти времени, прежде чем появится версия с
>>виртуальными переменными для циклов
неделя-две. но поскольку в данный момент функционал blitz нашим требованиям полностью удовлетворяет, и я им занимаюсь исключительно в свободное время - я бы не хотел брать на себя каких-либо строгих обязательств
>>виртуальными переменными для циклов
неделя-две. но поскольку в данный момент функционал blitz нашим требованиям полностью удовлетворяет, и я им занимаюсь исключительно в свободное время - я бы не хотел брать на себя каких-либо строгих обязательств
Gorynych
Посетитель PHP-Клуба
fisher
э... а... а может стоит разделить версии на две? Оставить одну, которая на данный момент вашим требованиям удовлетворяет, и завести вторую, обозвав ее как-то вроде blitzx (типа extended). Потому как лучшее (иногда) - враг хорошего.
p.s. корова, разумеется не моя, но интерес - шкурный. После того, как использование Смарти (наконец-то!) у нас было изжито была мысль в части вещей попользовать именно blitz.
э... а... а может стоит разделить версии на две? Оставить одну, которая на данный момент вашим требованиям удовлетворяет, и завести вторую, обозвав ее как-то вроде blitzx (типа extended). Потому как лучшее (иногда) - враг хорошего.
p.s. корова, разумеется не моя, но интерес - шкурный. После того, как использование Смарти (наконец-то!) у нас было изжито была мысль в части вещей попользовать именно blitz.
fisher
накатила суть
Gorynych
вы не поверите, но blitz активно используется и в нашей компании - только в качестве основного инструмента, причем я всегда испоьлзую самые последние версии и по этой причине я точно также заинтересован в том, чтобы движок оставался максимально быстрым, стабильным и так далее. перед каждым релизом я прогоняю тесты на производительность чтобы убедиться что ничего в базовом функционале не затупило.
введение пред-определенных переменных скорее всего вообще никак не скажется на производительности - они не будут добавляться во все хеши, разумеется, а наоборот будут вычисляться real-time только если указаны явно в шаблоне (вычисляться тоже сильно сказано там всё будет быстро). а простые выражения скорее всего пока вводить не будем - пока я сам не пойму что это действительно нужно. так что не вижу никаких причин для беспокойства.
даже если вдруг какой-то расширенный функционал станет "тормозить" или ещё что - появится значит просто ключик для сборки.
вы не поверите, но blitz активно используется и в нашей компании - только в качестве основного инструмента, причем я всегда испоьлзую самые последние версии
и по этой причине я точно также заинтересован в том, чтобы движок оставался максимально быстрым, стабильным и так далее. перед каждым релизом я прогоняю тесты на производительность чтобы убедиться что ничего в базовом функционале не затупило. введение пред-определенных переменных скорее всего вообще никак не скажется на производительности - они не будут добавляться во все хеши, разумеется, а наоборот будут вычисляться real-time только если указаны явно в шаблоне (вычисляться тоже сильно сказано там всё будет быстро). а простые выражения скорее всего пока вводить не будем - пока я сам не пойму что это действительно нужно. так что не вижу никаких причин для беспокойства.
даже если вдруг какой-то расширенный функционал станет "тормозить" или ещё что - появится значит просто ключик для сборки.
fisher
может, я не в тему, но я все с теми же философствованиями:
зуб даю на отсечение, что создатели смарти рассуждали точно так же. "нам все это нужно. поэтому внесем-ка и этот функциональчик... "
Это же именно тот самый путь, которым и появляются монстры.
не зря я задавал недавно в жж вопрос о девелоперах, которые не добавляют фичи в продукт, а у б и р а ю т.
к тому же, кроме производительности есть и другие факторы - простота использования, однозначность синтаксиса...
blitz активно используется и в нашей компании - все верно. но ведь вы находитесь в совершенно обособленном положении. существующий функционал вы не замечаете - он как воздух, вы к нему привыкли. И новые добавления не кажутся сильно раздувающими продукт. А вот со стороны... Особенно после пары-тройки таких итераций...
может, я не в тему, но я все с теми же философствованиями:
зуб даю на отсечение, что создатели смарти рассуждали точно так же. "нам все это нужно. поэтому внесем-ка и этот функциональчик... "
Это же именно тот самый путь, которым и появляются монстры.
не зря я задавал недавно в жж вопрос о девелоперах, которые не добавляют фичи в продукт, а у б и р а ю т.
к тому же, кроме производительности есть и другие факторы - простота использования, однозначность синтаксиса...
blitz активно используется и в нашей компании - все верно. но ведь вы находитесь в совершенно обособленном положении. существующий функционал вы не замечаете - он как воздух, вы к нему привыкли. И новые добавления не кажутся сильно раздувающими продукт. А вот со стороны... Особенно после пары-тройки таких итераций...
fisher
накатила суть
%анат
а что со стороны кажется монструозным в blitz в его текущем состоянии? станет ли он монстром если в него добавить предопределенные переменные для итераций типа $_is_even, которая принимает значение TRUE/FALSE в зависимости от четности итерации? ведь в случае с "полосатым" меню это очень характерная штука - сейчас если надо сделать полосатый список то приходится идти по массиву данных и в зависимости от четного-нечетного номера ставить в него ещё одну переменную ручками, и это конечно неудобно. в данном случае энтропия растет но очень несильно а удобства прибавляется и значительно.
а что со стороны кажется монструозным в blitz в его текущем состоянии? станет ли он монстром если в него добавить предопределенные переменные для итераций типа $_is_even, которая принимает значение TRUE/FALSE в зависимости от четности итерации? ведь в случае с "полосатым" меню это очень характерная штука - сейчас если надо сделать полосатый список то приходится идти по массиву данных и в зависимости от четного-нечетного номера ставить в него ещё одну переменную ручками, и это конечно неудобно. в данном случае энтропия растет но очень несильно а удобства прибавляется и значительно.
ну, я не про конкретно эту фичу, а вообще.
сейчас кажется, что не хватает ппеременных, дальше - еще чего-то.
я об общем принципе, что ли.
хз. тут, скорее, наверное, надо идеологию придумывать новую.
просто все достоинство языков шаблонизации "без синтаксиса" - в их простоте. а если уж вводить кучу элементов - так проще уж язык со стандартным синтаксисом использовать.
вообще, я не очень понял назначение этих ппеременных. ведь основа блица, насколько я понимаю - это контексты. а контексты по определению обрабатываются в дополнительных файлах (по моей системе мира, шаблоны типа пхп_темплейтс состоят из двух частей - шаблон и обработчик) и почему нельзя эти ппеременные вводить в коде - обработчике?
сейчас кажется, что не хватает ппеременных, дальше - еще чего-то.
я об общем принципе, что ли.
хз. тут, скорее, наверное, надо идеологию придумывать новую.
просто все достоинство языков шаблонизации "без синтаксиса" - в их простоте. а если уж вводить кучу элементов - так проще уж язык со стандартным синтаксисом использовать.
вообще, я не очень понял назначение этих ппеременных. ведь основа блица, насколько я понимаю - это контексты. а контексты по определению обрабатываются в дополнительных файлах (по моей системе мира, шаблоны типа пхп_темплейтс состоят из двух частей - шаблон и обработчик) и почему нельзя эти ппеременные вводить в коде - обработчике?
fisher
накатила суть
>>почему нельзя эти ппеременные вводить в коде - обработчике
можно, но этот обработчик не всегда должен быть "сложным". ну вот пример. внутреннее представление итераций для контекста имеет такой же вид, в котором данные получаются из базы например - в этому большой бонус был ещё у php_templates. то есть вызов
$data =$dbh->getALL($sql,$params);
возвращает обычно что-то вроде
$data = array(
0=> array('id'=>1,'name'=> 'Вася'),
1=> array('id'=>2,'name'=> 'Петя'),
2 =>array('id'=>3,'name'=> 'Свето'),
)
и поэтому в обработчике можно не проходить по массиву данных а просто сказать
$View->context('/list/item');
$View->set($data);
тогда сразу же автоматом это будет одначать что контекст /list/item будет проитерирован ровно столько раз, сколько элементов в $data (три), а все переменные id и name автоматом будут видны в этой итерации (тут конечно не учитывается, что иногда нужны обработчики тот же htmlspecialchars, но это не всегда нужно, или можно использовать экранирование в самом шаблоне - короче, щас эту ситуацию не рассматриваем). это чем-то отдаленно напоминает подход XML/XSLT по-моему: то есть взяли внутреннее представление данных (массив $data - XML) и навернули на него шаблон (XSLT), только в данном случае пользуясь соглашениями о простом формате данных и шаблона всё получается куда более просто и быстро.
а теперь представим что нам нужен полосатый список. есть два варианта, и оба довольно неудобные для девелопера. первый - сделать разные контексты для того html-кода в котором прописывается стиль, второй - сделать if для того кода, где ставится стиль. но в обоих случаях уже нельзя обойтись одним лишь set - придется бежать по массиву $data в обработчике. а если будет предопределенная переменная $_is_even, то в шаблоне просто можно написать что-то вроде
style={{ if($_is_even, 'item_even', 'item_odd')}} и всё - set останется таким же.
можно, но этот обработчик не всегда должен быть "сложным". ну вот пример. внутреннее представление итераций для контекста имеет такой же вид, в котором данные получаются из базы например - в этому большой бонус был ещё у php_templates. то есть вызов
$data =$dbh->getALL($sql,$params);
возвращает обычно что-то вроде
$data = array(
0=> array('id'=>1,'name'=> 'Вася'),
1=> array('id'=>2,'name'=> 'Петя'),
2 =>array('id'=>3,'name'=> 'Свето'),
)
и поэтому в обработчике можно не проходить по массиву данных а просто сказать
$View->context('/list/item');
$View->set($data);
тогда сразу же автоматом это будет одначать что контекст /list/item будет проитерирован ровно столько раз, сколько элементов в $data (три), а все переменные id и name автоматом будут видны в этой итерации (тут конечно не учитывается, что иногда нужны обработчики тот же htmlspecialchars, но это не всегда нужно, или можно использовать экранирование в самом шаблоне - короче, щас эту ситуацию не рассматриваем). это чем-то отдаленно напоминает подход XML/XSLT по-моему: то есть взяли внутреннее представление данных (массив $data - XML) и навернули на него шаблон (XSLT), только в данном случае пользуясь соглашениями о простом формате данных и шаблона всё получается куда более просто и быстро.
а теперь представим что нам нужен полосатый список. есть два варианта, и оба довольно неудобные для девелопера. первый - сделать разные контексты для того html-кода в котором прописывается стиль, второй - сделать if для того кода, где ставится стиль. но в обоих случаях уже нельзя обойтись одним лишь set - придется бежать по массиву $data в обработчике. а если будет предопределенная переменная $_is_even, то в шаблоне просто можно написать что-то вроде
style={{ if($_is_even, 'item_even', 'item_odd')}} и всё - set останется таким же.
algo
To the stars!
P.S
Суффикс NG это типа new generation, типа syslog-ng.
phpNG типа php new generation
*wink-wink*
В конце концов - если добавлять презентационную логику (а речь о ней, как я понял) - то добавлять ее с расчетом на замену в этой роли Smarty...
Хотя на пол-пути тоже наверно остановиться можно, но как-то это слабо представляется..
Суффикс NG это типа new generation, типа syslog-ng.
phpNG типа php new generation
*wink-wink*
В конце концов - если добавлять презентационную логику (а речь о ней, как я понял) - то добавлять ее с расчетом на замену в этой роли Smarty...
Хотя на пол-пути тоже наверно остановиться можно, но как-то это слабо представляется..
Gorynych
Посетитель PHP-Клуба
угу, и мануал по ключам для сборки без всей этой дополнительной радости.
потому как откручивание Смарти лично у нас дало ну очень наглядный прирост скорости. Так что если вдруг из blitz захочется делать замену Смарти, то кончится все тем же...
p.s. вообще, лично у меня стойкое ощущение что число файловых операций и используемых для файлов хендлеров это примерно то место, где шаблонизатор и начинает тормозить на нагруженном запросаим сайтом. Потому что файловая система - это очень неприятное место при больших нагрузках. Это так, мысли в слух. Почти оффтопик.
потому как откручивание Смарти лично у нас дало ну очень наглядный прирост скорости. Так что если вдруг из blitz захочется делать замену Смарти, то кончится все тем же...
p.s. вообще, лично у меня стойкое ощущение что число файловых операций и используемых для файлов хендлеров это примерно то место, где шаблонизатор и начинает тормозить на нагруженном запросаим сайтом. Потому что файловая система - это очень неприятное место при больших нагрузках. Это так, мысли в слух. Почти оффтопик.
fisher
а нельзя пробежаться просто в цикле по $data и добавить, что надо, а потом уже натравливать шаблон?
вот сам я именно так делаю.
если данные из базы не совпадают с теми, которые будут выводиться (нбсп там понаставить, или значения из какого глобального справочника) то после этого самого $data =$dbh->getALL идет цикл.
хочу повториться: вопрос мой скорее философского свойства. где та грань, за которой разработчики остановятся, и перестанут добавлять такие мелкие доработки в продукт?ведь все мы знаем, что такие случаи будут попадаться всегда.
лечить частные случаи внесением исправлений в движок - имхо, порочная затея.
а нельзя пробежаться просто в цикле по $data и добавить, что надо, а потом уже натравливать шаблон?
вот сам я именно так делаю.
если данные из базы не совпадают с теми, которые будут выводиться (нбсп там понаставить, или значения из какого глобального справочника) то после этого самого $data =$dbh->getALL идет цикл.
хочу повториться: вопрос мой скорее философского свойства. где та грань, за которой разработчики остановятся, и перестанут добавлять такие мелкие доработки в продукт?ведь все мы знаем, что такие случаи будут попадаться всегда.
лечить частные случаи внесением исправлений в движок - имхо, порочная затея.
Макс
Старожил PHPClub
В блице это легко реализовать через пользовательские методы:
PHP:
class TrBlitz extends Blitz {
function tr_class() {
static $i = 0;
static $classes = array('red','black');
return $classes[($i++ % sizeof($classes))];
}
}
....
<!-- BEGIN TR --><tr class="{{tr_class()}}"> ... <!-- END TR -->Что-то вроде :
Blitz::addUserFunc('tr_class', array('ViewHelper', 'getTableRowClass'));
не помешало бы.
fisher
накатила суть
>>а нельзя пробежаться просто в цикле по $data и добавить, что надо, а
>>потом уже натравливать шаблон
ну а зачем бежать если можно не бежать? это и есть альтернатива, о которой я написал - те самые два способа. а можно использовать предустановленные переменные.
>>где та грань, за которой разработчики остановятся, и перестанут
>>добавлять такие мелкие доработки в продукт
ну а чем тебе не нравятся доработки? всё течёт, всё меняется смарти не будет, всё будет быстро, стабильно и чики-пуки короче.
>>Так что если вдруг из blitz захочется делать замену Смарти,
>>то кончится все тем же
а вот не дождётесь
>>Blitz::addUserFunc('tr_class', array('ViewHelper', 'getTableRowClass'))
ну динамически добавлять методы в класс тоже жесть
>>потом уже натравливать шаблон
ну а зачем бежать если можно не бежать? это и есть альтернатива, о которой я написал - те самые два способа. а можно использовать предустановленные переменные.
>>где та грань, за которой разработчики остановятся, и перестанут
>>добавлять такие мелкие доработки в продукт
ну а чем тебе не нравятся доработки? всё течёт, всё меняется
смарти не будет, всё будет быстро, стабильно и чики-пуки короче.>>Так что если вдруг из blitz захочется делать замену Смарти,
>>то кончится все тем же
а вот не дождётесь
>>Blitz::addUserFunc('tr_class', array('ViewHelper', 'getTableRowClass'))
ну динамически добавлять методы в класс тоже жесть
Макс
Старожил PHPClub
да я не настаиваю на том чтобы это были именно методы. Просто callback-функция, которую бы блиц вызывал, для обработки того, что у тебя в документации называется "пользовательскими методами"
PS
ну и не такая уж и жесть
http://www.codeproject.com/useritems/Ruby_Dynamic_Methods.asp
PS
ну и не такая уж и жесть
http://www.codeproject.com/useritems/Ruby_Dynamic_Methods.asp