Форум dkLab и Denwer

[Дмитрий Кóтеров]

В данном топике присоединены некоторые исходники (переработанные и дополненные), которые встречаются там и тут в «Самоучителе PHP4».

---

shop.zip
Description:	Исходники из «Самоучителя PHP4»: заглушка сайта.	Download
Filename:	shop.zip
Filesize:	25,49 KB
Downloaded:	2495 Time(s)

---

[Лобач Олег]

Может тогда подскажете как расширить функциональность этого шаблонизатора? Например, хочу я выводить новости по пять штук на страничку, дёргая их из базы. Заводить пять блоков и описывать пять раз вывод блока кажется мне не самым лучшим решением. А если надо 20? А если 50?
Решение подобных задач мне видется в создании блока-массива (двумерного, я думаю, вполне должно хватить) и разбора его в шаблоне посредством псевдотегов, типа <FOREACH></FOREACH>. Но вот реализацию я что-то придумать не могу. :(
Может есть у кого идеи по реализации этого? Или ещё какие-нибудь предложения по наращиванию функциональности...

[Дмитрий Кóтеров]

Блоки - это не "что-то, что выводится в цикле". Это некоторые статические элементы. Вся динамика идеологически должна располагаться внутри блоков. То есть, если Вы хотите foreach, так и пишите:

Code (php):	скопировать код в буфер обмена
<?Controller("MyDataGenerator")?> <?foreach ($GeneratedData as $k=>$v) {?>   здесь HTML <?}?>

В принципе, если очень хочется делать "параметрический блок" (который не поддерживается в этой версии), можете просто написать для этого функцию:

Code (php):	скопировать код в буфер обмена
<?function ParametedBlock($a, $b) {?>   здесь РЕЬД <?}?> ... <?ParametedBlock(10,20)?>

Но только далеко не всегда это стоит делать. Я, например, еще ни разу не встречался с ситуацией, когда такой прием был бы оправдан.

[Лобач Олег]

К такому варианту я уже приходил. Но не понравился мне он тем, что необходимо смешивать дизайн и реализацию такого блока. Как обойти это я пока не нашёл. Мне хочется что бы дизайн отдельно взятой страницы полностью опроделялся только в одном файле шаблона. Или я неправильно понял Ваш ответ? Приведённый Вами код относился к содержимому блока или шаблону? На сколько я понимаю - к блоку. Тогда внедрение в блок кода HTML, определяющего визуализацию контента, генерирующегося в этом блоке, мне не нравится, т.к. это затруднит ре-дизайн. А вставка PHP-шного кода (даже в таких малых количествах) в шаблон тоже не вызывает у меня восторга.
И ещё один вопрос. Дмитрий, возможно ли коммерческое использование кода шаблонизатора. Елси да, то что при этом необходимо (копирайты в коде, на заглавной странице, отчисления)?

[Дмитрий Кóтеров]

Лобач Олег wrote:

Приведённый Вами код относился к содержимому блока или шаблону?

Видимо, к шаблону.

Лобач Олег wrote:

возможно ли коммерческое использование кода шаблонизатора

Все зависит от того, что Вы подразумеваете под словом «коммерческий». Мне кажется, что Вы понимаете это слово неправильно: оно значительно более мягкое. Вы можете использовать PHP-код в каких угодно проектах и как угодно, однако Вы не должны продавать шаблонизатор отдельно (например, под собственной маркой). В общем, обычная лицензия LGPL.

[Лобач Олег]

Лобач Олег wrote:

Приведённый Вами код относился к содержимому блока или шаблону?

Дмитрий Кóтеров wrote:

Видимо, к шаблону.

Мне не нравится идея внедрения PHP в шаблон страницы. Руководствуюсь вод чем: когда создаёшь дизайн сам, то можешь лавировать между удобством и простотой (используя PHP там, где чистым HTML не обойтись). А если дизайн пишет человек хорошо знающий HTML, но не владеющий PHP? Проводить ликбез? А оно ему надо? Может лучше ему дать инструмент, очень похожий на знакомый HTML, но имеющий расширеную функциональность (в пределах возможносей "движка", конечно)?
Вот поэтому я и спрашивал как можно уйти от PHP-кода в шаблоне и HTML-кода в блоке-генераторе.

Лобач Олег wrote:

возможно ли коммерческое использование кода шаблонизатора

Дмитрий Кóтеров wrote:

Вы можете использовать PHP-код в каких угодно проектах и как угодно, однако Вы не должны продавать шаблонизатор отдельно (например, под собственной маркой).

Понятно, спасибо за разъяснения.

Дмитрий Кóтеров wrote:

если очень хочется делать "параметрический блок" (который не поддерживается в этой версии)

А планируются новые версии?

[Евгений Бондарев]

Лобач Олег wrote:

Вот поэтому я и спрашивал как можно уйти от PHP-кода в шаблоне и HTML-кода в блоке-генераторе

Дмитрий будет ругаться, но я пользуюсь XTemplate

[WingedFox]

Дмитрий Кóтеров:
Свежий Денвер (10.02.2003) + shop.zip дают очень интересный GET:
===
URL = http://test/index.html?cid=95&id=4
$_GET = Array ( [/index_html?cid] => 95 [id] => 4 )
===

Параметрический блок оправдан при выводе новостной ленты со сложным дизайном и кучей полей.
Проще генерировать каждый кусок ленты внутри блока, так, чтобы наружу торчало минимальное количество ушей.
Дизайнеру один раз показал, какой циферкой в Blk() менять количество рисуемых новостей, а какой - отрезать заголовок нужной длины, а дальше - пусть он творчески мыслит, не дергая при этом программера :)

[Евгений Бондарев]

WingedFox wrote:

дают очень интересный GET

Проверьте в разных браузерах. Это может ИЕ глючить. У меня такое было...

[WingedFox]

IE5.5 SP2, NN4.8, NN6.2, Opera5, Opera 7.10

[Дмитрий Кóтеров]

WingedFox:
Вроде бы эта ошибка исправлялась уже...
Сделайте phpinfo(). Вероятно, в те времена, когда писался код,;_ПУЕ просто еще не было, использовался HTTP_GET_VARS или что-то вроде того. В любом случае, этот код — лишь демонстрационный и «книжный», не стоит его применять без всяких изменений.

[WingedFox]

Я нашел топик на Xpoint'е, там действительно все исправлено.
Но именно этот вариант выдает такую строчку.
===phpinfo()===
query_string = /index.html?cid=95&id=4
===

А будущее у этого шаблонизатора есть?

[Дмитрий Кóтеров]

Зависит от Вас (-;

[WingedFox]

Нда... Как правильно Вы заметили на Xpoint'e, putenv("QUERY_STRING") почему-то не работает...
Посмотрим, что скажут разработчики PHP.

Если удастся побороть передачу параметров, то будущее у него будет :)

Кстати, вот еще один интересный глюк - если использовать ErrorDocument, то в _GET попадает только имя обработчика.

PS: "В глубине Сибирских руд" я выкопал систему Pager+Scripter, датированную 2000 годом =)
Она так и осталась в v1.0?
PPS: Может быть имеет смысл перенести кусок темы в "Прочее", чтобы не разводить тут оффтопик?

[WingedFox]

Ладно, пусть с ними.
Пока еще дождусь ответа... А работать надо прямо сейчас (*8
К счастью, мне "QUERY_STRING" не нужна.

Дмитрий Кóтеров:
Добавьте в какой-либо форме вот этот вот багфикс, пожалуйста.

Code (php):	скопировать код в буфер обмена
// Иногда в $_GET заносится и путь к скрипту // Правим это недоразумение $q = ""; foreach ($_GET as $k => $v) {   unset($_GET[$k]);   $k=preg_replace("/^[^?]*\\?/","",$k);   $HTTP_GET_VARS[$k]=$v;   $q .= "&".$k."=".($v); } $_GET=$HTTP_GET_VARS; parse_str($q); unset ($q,$k,$v);

Кстати, все забываю сказать Вам "Спасибо" за эту отличную идею организации шаблонизатора.

[Дмитрий Кóтеров]

Есть и другой способ запуска обработчика на PHP, более перспективный и лишенный недостатка с GET.

Code (Apache config):	скопировать код в буфер обмена
Action templhandler "/_Kernel/Template/TemplateHandler.php" AddHandler templhandler .html

Как видите, в хвосте нет вопросика. При этом параметры передаются насколько другим способом (см. phpinfo(), чтобы понять, как именно). Вообще говоря, этот способ более корректный и не обладает никакими побочными эффектами.

[WingedFox]

Есть, но тогда надо сразу переписывать код...
Этот путь не подходит для текущей версии "шаблонизатора".

Так что, предложенный мной патч - это наименьшее зло.

[Дмитрий Кóтеров]

Не так и много там «переписывать». Всего-то в одном месте заменить.

[Дмитрий Кóтеров]

Вот Вам кусок кода, вырежьте из него все, что нужно. См. функцию doPseudoRedirect.

---

Humanoid.zip
Description:		Download
Filename:	Humanoid.zip
Filesize:	3,16 KB
Downloaded:	629 Time(s)

---

[Shura]

Дмитрий Кóтеров wrote:

Есть и другой способ запуска обработчика на PHP, более перспективный и лишенный недостатка с GET. Код (Apache config): Action templhandler "/_Kernel/Template/TemplateHandler.php" AddHandler templhandler .html

Только надо ещё убрать (или закомментировать) строки
@putenv("REQUEST_URI=".
    $GLOBALS["HTTP_ENV_VARS"]["REQUEST_URI"]=
    $GLOBALS["REQUEST_URI"]=
    getenv("QUERY_STRING")
);

@putenv("QUERY_STRING=".
    $GLOBALS["HTTP_ENV_VARS"]["QUERY_STRING"]=
    $GLOBALS["QUERY_STRING"]=
    ereg_Replace("^[^?]*\\?","",getenv("QUERY_STRING"))
);
в файле TemplateHandler.php просто потому, что они становятся не нужны. Я Вас Правильно понял?

[Дмитрий Кóтеров]

Да, вероятно.

[WingedFox]

Извините за долгое молчание, я был очень далеко от просторов интернета =)

Комментировать эти строчки не обязательно.

Я еще не до конца проверил, может быть что-то и всплывет...

Достаточно заменить в TemplateHandler.php

Code (php):	скопировать код в буфер обмена
chdir(dirname($SCRIPT_FILENAME));

на

Code (php):	скопировать код в буфер обмена
chdir(dirname($_SERVER["PATH_TRANSLATED"]));

и

Code (php):	скопировать код в буфер обмена
echo RunUrl($SCRIPT_NAME);

на

Code (php):	скопировать код в буфер обмена
echo RunUrl($_SERVER["PATH_INFO"]);

в Librarian.php

Code (php):	скопировать код в буфер обмена
@putenv("SCRIPT_NAME=".          $GLOBALS["HTTP_ENV_VARS"]["SCRIPT_NAME"]=          $GLOBALS["SCRIPT_NAME"]=          ereg_Replace("\\?.*","",$GLOBALS["HTTP_ENV_VARS"]["REQUEST_URI"]) );

на

Code (php):	скопировать код в буфер обмена
@putenv("SCRIPT_NAME=".          $GLOBALS["HTTP_ENV_VARS"]["SCRIPT_NAME"]=          $GLOBALS["SCRIPT_NAME"]=          ereg_Replace("\\?.*","",$_SERVER["PATH_INFO"]) );

Если ничего не забыл, то это - все.

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

[WingedFox]

Хм... собрав все в кучу я нашел универсальный путь:
замените в Librarian.phl

Code (php):	скопировать код в буфер обмена
@putenv("SCRIPT_NAME=".          $GLOBALS["HTTP_ENV_VARS"]["SCRIPT_NAME"]=          $GLOBALS["SCRIPT_NAME"]=          ereg_Replace("\\?.*","",($GLOBALS["HTTP_ENV_VARS"]["REQUEST_URI"]) ); );

на

Code (php):	скопировать код в буфер обмена
@putenv("SCRIPT_NAME=".          $GLOBALS["HTTP_ENV_VARS"]["SCRIPT_NAME"]=          $GLOBALS["SCRIPT_NAME"]=          ereg_Replace("\\?.*","",($_SERVER["PATH_INFO"])?$_SERVER["PATH_INFO"]:$GLOBALS["HTTP_ENV_VARS"]["REQUEST_URI"]) );

добавьте в TemplateHandler.php после @putenv("QUERY_STRING=".....);

Code (php):	скопировать код в буфер обмена
// Иногда в $_GET заносится и путь к скрипту // Правим это недоразумение $q = ""; foreach ($GLOBALS["HTTP_GET_VARS"] as $k => $v) {   unset($_GET[$k]);   $k=preg_replace("/^[^?]*\\?/","",$k);   $GLOBALS["HTTP_GET_VARS"][$k]=$v;   $q .= "&".$k."=".($v); } $_GET=&$GLOBALS["HTTP_GET_VARS"]; parse_str($q); unset ($q,$k,$v);

и все будет работать корректно при любом типе обработчика.

Last edited by WingedFox on Mon Jun 23, 2003 1:01 am; edited 1 time in total

[Дмитрий Кóтеров]

Только, разве что, рекомендую

Code (php):	скопировать код в буфер обмена
$_GET =& $GLOBALS["HTTP_GET_VARS"]; # =&, а не =

При любом типе обработчика — это хорошо.

[WingedFox]

Спасибо.

Забыл, что $_GET может быть большим =)
Обычно у меня в нем лежат 1-2 параметра...

[Shura M]

WingedFox wrote:

Комментировать эти строчки не обязательно.

Тогда задам вопрос прямо. Объясните ущербность удаления двух putenv из TemplateHandler.php, если REQUEST_URI и QUERY_STRING и без них содержат правильное значение (я имею в виду случай
Action templhandler "/_Kernel/Template/TemplateHandler.php"
а не
Action templhandler "/_Kernel/Template/TemplateHandler.php?"
). Более того первый putenv приведёт в занесению в REQUEST_URI значения QUERY_STRING, которое уже имеет правильное значение (т. е. содержит значения параметров после символа '?', а не идентификатор ресурса), что приведёт к неверному REQUEST_URI. Я не прав? Тогда в чём?

[WingedFox]

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

Если есть желание, Вы можете обернуть эти putenv в

Code (php):	скопировать код в буфер обмена
if (!$_SERVER["PATH_INFO"]) { .... }

[Дмитрий Кóтеров]

Это обязательно нужно сделать.

[WingedFox]

Поправлено.

Правда, у меня проблем не было... Пока что. 8*)

---

_Kernel.zip
Description:	Исправленные TemplateHandler.php и Librarian.phl	Download
Filename:	_Kernel.zip
Filesize:	4,12 KB
Downloaded:	627 Time(s)

---

[WingedFox]

Обновление №1:
в Template.phl добавлена функция

Code (php):	скопировать код в буфер обмена
// Добавляет фильтр в список. // Формат функций идентичен описанному в комментарии к $GLOBALS["BLOCKFILTERS"] // Будьте внимательны! function AddFilter($filter) {    $GLOBALS["BLOCKFILTERS"][]=$filter; }

и изменена функция

Code (php):	скопировать код в буфер обмена
// Запускает все фильтры для блока. // Модифицированный вариант - запускает только те фильтры, которые // существуют в природе. function _ProcessContent($name,&$cont,$url) {       foreach($GLOBALS["BLOCKFILTERS"] as $F)           if (function_exists($F))                 $F($name,$cont,$url); }

Теперь можно добавлять фильтры из любого места программы.

Обновление №2:
Теперь возможно использование функций для финальной обработки контента.
Например - упаковки.
В Template.phl добавлено:

Code (php):

скопировать код в буфер обмена

// В этом массиве перечислены функции, которые выполняются по окончании обработки // всех блоков. По умолчанию, у меня здесь подключается библиотека для компрессирования // содержимого страничек. Формат функций: // void PostProcFunc(string &$content) $GLOBALS["POSTPROC"]=array(); // Функция для добавления заключительного обработчика в массив. function AddPostProcFunc($func) {    $GLOBALS["POSTPROC"][]=$func; } // Запускает все существующие заключительные обработчики. function _ExecPostProc(&$cont) {         foreach ($GLOBALS["POSTPROC"] as $F)           if (function_exists($F))                 $F($cont); }

и Templatehandler.php изменены последние строчки:

Code (php):	скопировать код в буфер обмена
$final_content = RunUrl($SCRIPT_NAME); _ExecPostProc($final_content); echo $final_content;

Пример использования пост-обработчика (для чего это все и писалось 8*))

Code (Apache config):	скопировать код в буфер обмена
#<?AddPostProcFunc("gzip_content")?>

Code (php):	скопировать код в буфер обмена
function gzip_content (&$cont) {   Uses ("class.gzip_enc");   ob_start ();   echo $cont;   $cont="";   new gzip_encode(); }

Библиотеку class.gzip_encode можно скачать с www.leknor.com

С пожеланиями и предложениями - добро пожаловать!

---

_Kernel.zip
Description:	Обновленные Template.phl и TemplateHandler.php	Download
Filename:	_Kernel.zip
Filesize:	6,23 KB
Downloaded:	442 Time(s)

---

[Исаенков Павел]

Дмитрий Кóтеров:
Я как понял ваш пример работает на основе .htaccess и директивы Action. Это все хорошо, если у твоего хостинга доступна эта директива, а если она не доступна или вообще нет поддержки .htaccess то что тогда делать. Можно ли как нибудь обойтись без этого файла или никак нельзя?

[WingedFox]

Поскольку Дмитрий Кóтеров в отпуске, то отвечу я 8)

Если нельзя работать с .htaccess, то надо менять хостера %*)

Главное, чтобы была возможность прописать тем или иным путем обработчик для .html файлов.

Code (Apache config):	скопировать код в буфер обмена
# Связываем имя обработчика с конкретным файлом. Action templhandler "/_Kernel/Template/TemplateHandler.php" # Action templhandler "/_Kernel/Template/TemplateHandler.php?" # Документы этого типа мы желаем "пропускать" через наш обработчик. AddHandler templhandler .html

Все остальное - это исключительно директивы движка.
Если хост не будет впадать в коматоз, видя .htaccess, то можно оставить все как есть, иначе - можно поправить код скрипта.
Возможно, если будет достаточно желающих, то я сделаю возможность использовать произвольный файл..
Пока что - не вижу необходимости.

Желаю удачи!

[Исаенков Павел]

WingedFox wrote:

Если хост не будет впадать в коматоз, видя .htaccess, то можно оставить все как есть, иначе - можно поправить код скрипта.

Из-за чего он может впадать в каматоз?

[WingedFox]

Из-за наличия этого файла.
Пару раз я встречался с тем, что при появлении .htaccess в одной из директорий сайта всплавала "Error 500".

[Исаенков Павел]

WingedFox wrote:

Пару раз я встречался с тем, что при появлении .htaccess в одной из директорий сайта всплавала "Error 500".

У меня как раз такая ошибка и вылазила на хостинге. Это значит что директива Action и AddType не поддерживаются?

[WingedFox]

Скорее всего - да.
Тут лучше написать письмо в саппорт с просьбой объяснить, в чем дело.

[Дмитрий Кóтеров]

Только одно маленькое замечание. По логике, система пост-фильтров не является частью шаблонизатора. Она должна быть выполнена в виде независимой надстройки. В самом деле, шаблонизатор — это система для предобразования текстовой информации и сборки из блоков окончательной страницы. Ключевое понятие для нее — блок, и, по сути, все, что делает шаблонизатор, — это вычисление тела указанного блока (по умолчанию Output).

В то же время, сжатие контента должно выполняться уже после этого процесса. И для нее не важно, был ли до нее запущен шаблонизатор, или нет. Кроме того, сжатие — это только одна из частных задач, которая должна выполняться обязательно в конце списка фильтров. Для этого в PHP существует функция ob_gzhandler().

Прикрепляю код, который используется для пост-фильтрации контента в данном форуме. Вообще говоря, HTML_SemiParser умеет три вещи:
- заменять куски кода по регулярному выражению;
- заменять целые тэги (включает парсер атрибутов тэгов);
- заменять невложенные контейнеры вроде <b>...</b>.
См. комментарии в коде.

Простой пример использования:

Code (php):

скопировать код в буфер обмена

ob_start(); # # тут код # $text = ob_get_contents(); ob_end_clean(); include_once "HTML/SemiParser.php"; $parser =& new HTML_SemiParser(); # например: удаляет все пробелы перед </td> $parser->addReplace("#\s+(?=</td>)#s", create_function('', 'return "";')); # обрабатывает все тэги <img> $parser->addTag("img", "img_replacer"); $text = $parser->process($text); echo ob_gzhandler($text); // <IMG> tag processor. function img_replacer($attr) {         // No need to set width-height.         if (isSet($attr['width']) || isSet($attr['height']) || !isSet($attr['src'])) return;         // Determime picture parameters.         $isz = @HTML_FormPersister::getimagesize_byUri($attr['src']);         if(!@$isz) return;         $attr['width'] = $isz[0];         $attr['height'] = $isz[1];         return $attr; }

---

HTML_SemiParser.zip
Description:		Download
Filename:	HTML_SemiParser.zip
Filesize:	2,78 KB
Downloaded:	401 Time(s)

---

Last edited by Дмитрий Кóтеров on Tue Jul 29, 2003 3:27 pm; edited 1 time in total

[WingedFox]

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

Сейчас я уже вынес все ее функции в отдельный модуль, дабы код стал более легко читаемым и не смешивался с кодом самого шаблонизатора.

Кстати, я заметил, что ob_gzhandler() не всегда срабатывает. По этому, я до сих пор предпочитаю использовать class.gzip_encode.

А Вы не против, что я публикую обновления и дополнения к системе? 8*)

[Дмитрий Кóтеров]

WingedFox wrote:

А Вы не против, что я публикую обновления и дополнения к системе? 8*)

Как раз наоборот — я очень рад (-;
Вообще говоря, у меня есть уже послностью переписанная «в стиле PEAR» версия шаблонизатора (сильно измененная), но она еще не обкатана.

[WingedFox]

Это хорошо 8*)

А она будет доступна к использованию?
А то я тут думал спросить у Вас разрешения открыть проект на sf.com =)