php_templates 1.7

[su1d]

php_templates 1.7

Всвязи с нахождением некоторых багов, пришлось ускорить выход очередного релиза.

CHANGELOG:
- контексты (блоки) теперь могут себя вести как обычные тэги - принимать строковые значения
- tmpl_set() теперь не выдаёт сообщения об ошибке, если тэг не найден в шаблоне
- tmpl_set_global() теперь работает только в итерированных контекстах
- tmpl_get() теперь не создаёт итераций контекстов
- tmpl_context() тоже теперь не создаёт итераций контекстов
- пофиксены крэш-баги в tmpl_unset()

----------
Теперь никуда не сдвинусь, пока не разберусь с документацией, что сделал tony2001. Скоро всё будет красиво и с переводами! =)

 

[LENNY]

Привет, это снова я . Во первых спасибо за такую оперативность. Ну а во вторых снова о глюках .

Значит так, всё скачал, установил. Но опять есть кое какие проблемы. Скажем если делаешь

tmpl_set_global ($d,'test','555');

а после делаешь

tmpl_iterate($d,'f1');

то переменной {test} НЕ ВИДНО, но если сделать просто tmpl_set, то всё нормально...

Жду комментариев

 

[tony2001]

слил.
завтра поставлю, буду смотреть.

su1d:
как ты относишься к классу-врапперу ?
мне после Смарти удобно завести экземпляр, назначать в процессе переменные, а только в самом конце уже по результату выполнения выводить конкретный шаблон.
сегодня набросал что-то подобное, интересует мнение общественности о целесообразности такой вещи.

 

[su1d]

2LENNY:
это уже не баг, а фича.. tmpl_set_global() надо вызывать когда уже весь шаблон забит данными и готов к парсингу.
Просто реализация tmpl_set_global() такова, что это не столько отдельная ф-ция, сколько некая разновидность "скрипта", пробегающего по всем контекстам, назначая значения переменным.

2tony2001:
у меня была уже такая идея: прямо в самом движке создать класс php_templates и внего уже засунуть все те же самые методы. Ща гляну как это в DOMXML сделано.. если там всё просто - будет скоро 1.8 =)

 

[LENNY]

2su1d:

да, теперь понял, всё работает, спасибо!

 

[tony2001]

http://tony2001.narod.ru/testing.tar.gz - тесты для php_templates
заинтересованным в php_templates господам рекомендую скачать, разобраться и написать свои тесты - php_templates от этого будет только лучше.

вроде бы баг:
код:

tmpl_set_global($t,"test","some");
tmpl_iterate($t,'/test1');
tmpl_set_global($t,"test","some");

шаблон:
<tmpl:test1>{test}</tmpl:test1>
еррор мессадж:
Fatal error: Undefined tag/context "/test1" in ...tests/004.php on line 10 (строка с tmpl_iterate)

плюс еще есть вопросы:
1)
tmpl_set($t,'/non-existent','some'); //bool(true)
tmpl_context($t,'/non-existent'); //bool(false)
tmpl_iterate($t,'/non-existent'); //Fatal error: Undefined tag/context "/non-existent" ....

Мне кажется, что разница в поведении слишком уж большая -
одна функция возвращает true,
другая - абсолютно спокойно реагирует на несуществующий контекст,
а третья - генерит Фатал еррор(!??! ну ладно еще варнинг..., хотя лучше нотайс).

2) глюк с двумя сет_глобал в 1.6 отсутствует, НО: в 1.6 это она не переназначает переменную, а делает append к существующему значению.
хотелось бы все-таки без аппенда, т.к. его при необходимости можно и эмулировать где надо.
а лучше - флаг у сет_глобал для принудительного аппенда, но по дефолту его выключить.

 

[tony2001]

http://tony2001.narod.ru/testing1.tar.gz - пару новых тестов для php_templates
+ патч для tmpl_set_global - теперь она умеет принимать темплэйты в кач-ве значения тэга, как tmpl_set().
прогонял ее, вроде бы работает ок.

 

[tony2001]

еще пара соображений:
глобальные переменные типа путей к картинкам и др, которые используются во всех шаблонах у меня определяются обычно в инклуде, который инкулудится ДО всего кода.
соотв-но удобно использовать tmpl_set_global именно так, а не в самом конце.
поэтому хотелось бы такого поведения:
tmpl_set_global добавляет переменные в хэш, который используется при каждом вызове php_tmpl_parse как доп. источник значений.

и еще:
su1d, что ты решил с include ?
делать будешь?

 

[su1d]

уф, давай по-порядку:

а) баг подтверждаю. поправлю.
б) с еррор-мессаджами не знаю что делать. для удобства их бы вообще убрать, но, с другой стороны, без них тоже нельзя =/
в) чёт я не совсем понял про аппенд? можно подробнее плиз?
г) пасиб за патч. гляну - apply'ну =)
д) насчёт глобальных значений в самом начале - угу, есть пара идей у меня как это сделать.. подумаю сёдня вечерком.. правда код опять разрушен всвязи с добавкой класса =)
е) я против инклудов. я тебе уже говорил, что они пойдут против философии шаблонов. да и лишний парсинг шаблона не хочеца делать =Р хотя, если докажешь (но это будет трудно сделать), что они жутко уж так нужны - бум думать над реализацией =)

 

[tony2001]

>с еррор-мессаджами не знаю что делать. для удобства их бы вообще убрать, но, с другой стороны, без них тоже нельзя =/
голосую: убрать
оставить нотайсы.

----

>чёт я не совсем понял про аппенд? можно подробнее плиз?
смотри:
в 1.6 set_global работала так:
tmpl_set_global($tpl,'tag','value1');
tmpl_set_global($tpl,'tag','value2');

теперь tag == 'value1value2';
а хотелось бы tag = 'value2';
т.е. более поздний сет_глобал затирает старое значение, а не аппендит.

----

насчет инклудов:
это зависит от реализации класса, если она будет позволять обходиться без них, тогда ок.

сейчас просто не хочется глобальные переменные для всех шаблонов отдельно назначать.
а хранить их в хэше для всех-всех шаблонов - имхо неверно.
поэтому хотелось бы вот так:

<?
$tpl = tmpl_open('some.tpl');
tmpl_set_global($tpl,'some','some');

?>
some.tpl:
<include file=another.tpl>
<tmpl:name>a{some}aa</tmpl:name>

another.tpl:
<tmpl:name2>a{some}aa</tmpl:name2>

и в результате у нас подставились бы глобальные переменные как в родительском, так и в инклуженном шаблоне.

надеюсь, что я не сильно замороченно объясняю =)

----

и еще одно =)
оч. хочется, чтобы tmpl_set_global принимала массивы в кач-ве параметра.
вообще, имхо это правильно свести функциональность tmpl_set & tmpl_set_global к одинаковой.

я сегодня-завтра попробую еще раз поковыряться сам, конечно....

 

[su1d]

ОНО АПЕНДИТ, ВМЕСТО ЗАМЕНЫ? я в шоке. иду на свалку... =/

для меня нотайсы - те же мессаджи, т.к. кодю с error_reporting(E_ALL); надо подумать.. в некоторых случаях всё равно придётся ФаталЕрроры оставлять.

про глобалы. хмм.. ты уже предлагаешь вводить супер_глобалс - на уровне движка, а не одного шаблона. слишком загруженно получается. наверное это лучше оставлять на юзера - класс Шаблон, от которого наследуются остальные.

кстати, о классах. в php-dev интересная дискуссия по этому поводу: "zend_API.c". Вот что пишут:

> when called as function -> print warning
> when called as method -> throw exception

What exception? There are no builtin exceptions and IMHO it would be
better to leave writing such up to the user.

E.g. I'd like to be able to have _all_ my classes extend my Object
class, including my own Exception class. Plus, I prefer the Java style
notation "Exception::getMessage", "Exception::toString",
"Exception:rintStackTrace", "Exception::getStackTrace",
"Object::getClass".

If any exception class were to be integrated into PHP5, it would:
a) not extend my Object class
b) probably have methods such as get_message (following the PHP
naming conventions)
c) not have getStackTrace return an array of "StackTraceElement"s.

Other users might prefer differing notations in their framework, will
disagree on inheritance issues with Object ("this is unneccessary
bloat") or want a slightly different stack trace (consisting of an
associative array, not those stupid StackTraceElement things).

This has actually been discussed on the engine2-List and IIRC,
builtin-anything-classes being forced on users was decided against. Side
note: Whithin the mentioned thread, even amongst those liking the idea
of builtin exceptions, no consensus on how to name these classes could
we reached (Exception? exception? __exception?).

Conclusion: Don't even try to write exception classes for PHP5 in C. You
will never please all of the users' needs - so simply leave it up to
them.

по-моему с этим можно согласиться.

 

[tony2001]

>ОНО АПЕНДИТ, ВМЕСТО ЗАМЕНЫ? я в шоке. иду на свалку... =/
смотри результаты тестов для 1.6 из первого архива.

угу, я просматривал этот тред в php-dev.
кто-то хорошо сказал, что реализовывать одну и ту же функциональность в классе и в функциях - глупо.
согласен.
но это если она действительно одна и та же.
если же речь идет о функциональности более высокого уровня, то...видимо все-таки на РНР надо делать это.

>для меня нотайсы - те же мессаджи, т.к. кодю с error_reporting(E_ALL);
угу, только выполнение скрипта не прерывается при этом.
а так - хоть подавляй, хоть нет - все равно скрипт на этом месте стопорится.

>надо подумать.. в некоторых случаях всё равно придётся ФаталЕрроры оставлять.
хотя бы Варнинг, но лучше Нотайс.

 

[tony2001]

http://tony2001.narod.ru/templates.tar.gz - версия templates.c с tmpl_set_global, которая принимает массивы и template resource в кач-ве значения.
должно работать ок.

 

[tony2001]

tmpl_set_global назначает значения только в последней итерации контекста.
вот такой код:

$tpl = tmpl_load('<tmpl:url>[{some}|{id}]</tmpl:url>');
for ($i=0;$i<10;$i++) {
    tmpl_iterate($tpl,'/url');
    tmpl_set($tpl,'/url/id',$i);
    for ($j=0;$j<10;$j++) {
        tmpl_set($tpl,'/url/id',$i);
//        tmpl_set_global($tpl,'some','SOME_TEXT');
    }
}
tmpl_set_global($tpl,'some','SOME_TEXT');
echo tmpl_parse($tpl);

меняется только при раскомментировании строки...

имхо надо менять сам принцип работы tmpl_set_global....

 

[su1d]

ессно.. как я уже писал, tmpl_set_global() - это такой "скрипт", который проходит по текущим последним итерациям контекстов и проставляет там свой таг.
по ходу таки да - надо его переписывать.

 

[tony2001]

да я понял, что ессно...
не хотел я влазить в tmpl_lib.c, но придется, видимо.
сам принцип надо переделывать..

 

[su1d]

не лезь =)
я сам переделаю

 

[tony2001]

гут, убрал руки с клавиатуры =)

 

[LENNY]

люди, опять вы што то переделываете...

оставьте всё как есть

 

[.des.]

Бедняга LENNY заволновался )
LENNY они все равно переделают они такие..