Статья:
PEAR – PHP Extension and Application Repository

Автор(ы): Дмитрий Димандт aka Mamut
Дата: 30.03.2005
Краткое знакомство с фреймворком PEAR, предоставляющим набор готовых решений PHP-программистам. В статье приводится краткое описание PEAR, помощь по установке "в полевых условиях".

Авторы:
Дмитрий Димандт aka Mamut

Аннотация:
Краткое знакомство с фреймворком PEAR, предоставляющим набор готовых решений PHP-программистам. В статье приводится краткое описание PEAR, помощь по установке "в полевых условиях".

Здравствуйте, Дмитрий Димандт aka Mamut


Все понял, только зачем вот это делать?
"8. Откройте файл DB.php в вашем любимом редакторе, найдите строчку require_once 'PEAR.php'; и сотрите ее. Сохраните файл."

А если версия обновится файлика, мне нужно будет потом опять вытирать строчку. Что это даст? Какой-то неправильный подход изменять чужие исходники без причины . Были у меня ситуации, когда приходилось править модули из PEAR, но из-за того, что то были не релиз версии и немножко подглюкивали. А тут вообще смысла не вижу...

G>Все понял, только зачем вот это делать?
G>"8. Откройте файл DB.php в вашем любимом редакторе, найдите строчку require_once 'PEAR.php'; и сотрите ее. Сохраните файл."

Ща буду отмахиваться

G>А если версия обновится файлика, мне нужно будет потом опять вытирать строчку. Что это даст? Какой-то неправильный подход изменять чужие исходники без причины . Были у меня ситуации, когда приходилось править модули из PEAR, но из-за того, что то были не релиз версии и немножко подглюкивали. А тут вообще смысла не вижу...

Это для установки "в полевых условиях". На самом деле, я сглупил немного. А может и нет — не знаю

Дело в том, что, если PEAR и его пакеты ставить "наголо", т.е., когда папка PEAR не лежит в путях, которые просматривает php, то любой пакет, содержащий "require PEAR.php" будет дико материться. Самое плохое в том, что иногда вторичные файлы или подклассы в пакетах тоже требуют PEAR. Для меня простейший способ избавления от такого — ручная правка.

Здравствуйте, Mamut, Вы писали:

M>Дело в том, что, если PEAR и его пакеты ставить "наголо", т.е., когда папка PEAR не лежит в путях, которые просматривает php, то любой пакет, содержащий "require PEAR.php" будет дико материться.

Просто include_path настроить надо и все

Здравствуйте, Mamut, Вы писали:

M>Это для установки "в полевых условиях". На самом деле, я сглупил немного. А может и нет — не знаю

M>Дело в том, что, если PEAR и его пакеты ставить "наголо", т.е., когда папка PEAR не лежит в путях, которые просматривает php, то любой пакет, содержащий "require PEAR.php" будет дико материться. Самое плохое в том, что иногда вторичные файлы или подклассы в пакетах тоже требуют PEAR. Для меня простейший способ избавления от такого — ручная правка.

Понятно

я вообще решаю это так, во всех проектах у меня есть файлик common.inc.php
в нем делаю вот такую штучку

define("cHomeScriptPath","D:\\!Projects\\php\\Signup\\dev\\");
define("cLibPath" ,cHomeScriptPath."lib/");

ini_set("include_path",cLibPath."Pear".PATH_SEPARATOR.cHomeScriptPath.PATH_SEPARATOR.ini_get("include_path"));

уже так работато несколько лет, то есть просто добавляю себе правило, что в каждый мною написанный исходничек я должен включить common.inc.php самым первым.
Тут я привел только кусочек этого файла, в нем там еще некоторые пути определяются, зато теперь все настройки с путями в одном файле.

А>я вообще решаю это так, во всех проектах у меня есть файлик common.inc.php
А>в нем делаю вот такую штучку

У меня тоже Но это — уже домашнее задание

M>>Дело в том, что, если PEAR и его пакеты ставить "наголо", т.е., когда папка PEAR не лежит в путях, которые просматривает php, то любой пакет, содержащий "require PEAR.php" будет дико материться.

ММ>Просто include_path настроить надо и все

Это не всегда возможно. Иногда такие хостеры попадаются, что PEAR боятся, как огня, лепечут что-то о секьюрити, да и вообще. Поубивав бы. В принципе, из-за них такая установка в полевых условиях и появилась

Здравствуйте, Макс М, Вы писали:

ММ>Здравствуйте, Mamut, Вы писали:

M>>Дело в том, что, если PEAR и его пакеты ставить "наголо", т.е., когда папка PEAR не лежит в путях, которые просматривает php, то любой пакет, содержащий "require PEAR.php" будет дико материться.

ММ>Просто include_path настроить надо и все

Правильно. Я, например, в файле .htaccess написал

php_value include_path "./PEAR/"

и всё работает.

Здравствуйте, Mamut, Вы писали:

ММ>>Просто include_path настроить надо и все

M>Это не всегда возможно. Иногда такие хостеры попадаются, что PEAR боятся, как огня, лепечут что-то о секьюрити, да и вообще. Поубивав бы. В принципе, из-за них такая установка в полевых условиях и появилась

что, ни set_include_path() ни ini_set('include_path', ...) не работают ?
(про .htaccess, httpd.conf и php.ini я уже молчу)

ММ>что, ни set_include_path() ни ini_set('include_path', ...) не работают ?
ММ>(про .htaccess, httpd.conf и php.ini я уже молчу)

Вот люди, не дают отмахаться

Теоретически и то и другое и третье может быть задизейблено. Например, на каком-нибудь параноидальном бесплатном хостере. Что тогда?

Здравствуйте, Аноним, Вы писали:

А>я вообще решаю это так, во всех проектах у меня есть файлик common.inc.php
А>в нем делаю вот такую штучку
А>define("cHomeScriptPath","D:\\!Projects\\php\\Signup\\dev\\");
А>define("cLibPath" ,cHomeScriptPath."lib/");
А>ini_set("include_path",cLibPath."Pear".PATH_SEPARATOR.cHomeScriptPath.PATH_SEPARATOR.ini_get("include_path"));

Я поступаю аналогично, только у меня этот файл назвывается init.php и лежит в корне сайта (там определяются пути к сайту, ну и чтобы не задавать их статически), я приведу его для примера, там кое-что на мой взгляд написано "красивее", чем у тебя, ну и может куому-то еще будет полезен:

<?php
define('SERVER_URL', (!empty($_SERVER['HTTPS']) ? 'https' : 'http').'://'.((!empty($_SERVER['HTTP_HOST']))?$_SERVER['HTTP_HOST'] : 'localhost'));
define('SITE_DIR', str_replace('\\', '/', realpath(dirname(__FILE__))));
define('SITE_PATH', substr(SITE_DIR, strlen(realpath($_SERVER['DOCUMENT_ROOT']))));
define('SITE_URL', SERVER_URL . SITE_PATH);
ini_set('include_path', implode((substr(PHP_OS, 0, 3) == 'WIN') ? ';' : ':', array(
  '.',
  'c:/php4/includes/PEAR',    // where PEAR is placed
  'c:/htdocs/libs'            // where other libs placed
)));
include 'magic_quotes_off.php';
?>

В твоем скрипте мне понравилось использование константы PATH_SEPARATOR, признаюсь, я не знал о ее существовании. Я же тупо использую PHP_OS и проверяю на WIN. Пожалуй исправлю эту часть на PATH_SEPARATOR, хотя это и не принципиально.

Здравствуйте, Geri, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

G>В твоем скрипте мне понравилось использование константы PATH_SEPARATOR, признаюсь, я не знал о ее существовании. Я же тупо использую PHP_OS и проверяю на WIN. Пожалуй исправлю эту часть на PATH_SEPARATOR, хотя это и не принципиально.

Рад, что помог

Дело в том, что я php использую очень часто для написания всяких консольных приложений, автоматических генерилок и т.д., то есть мне http или https совсем не нужно, для таких вещей я писал функции в своей библиотечке.
То есть, фактически я просто определяю пути к
1) библиотекам
2) исходникам ядра системы
3) шаблонам страниц
4) настроечным файлам
5) файлам сообщений на различных языках (английский, русский)
6) плагинам, если такие имеются
7) различным логам
и т.д.

вот примерчик файлика common.inc.php
он всегда лежит в корне проекта вместе с index.php

<?php

// This file may be included first to all project files
//
// include_once("common.inc.php");
//

if (!defined("__Common__")) {
define("__Common__","");

include_once "../home.inc.php";

set_time_limit(0);

define("cLogPath"    ,cHomeScriptPath."log/");
define("cConfigPath" ,cHomeScriptPath."kernel/conf/");
define("cLibPath"    ,cHomeScriptPath."lib/");
define("cGutLibsPath",cLibPath."GutLibs/");
define("cSrcPath"    ,cHomeScriptPath."kernel/Src/");
define("cLangPath"   ,cSrcPath."Lang/");
define("cPluginPath" ,cSrcPath."plugin/");

ini_set("include_path",cLibPath."Pear".PATH_SEPARATOR.cHomeScriptPath.PATH_SEPARATOR.ini_get("include_path"));

include_once cConfigPath."Settings.inc.php";

define("cTplsPath"   ,ScriptWWWDir()."tpls/");


include_once(cGutLibsPath."Log/class.Log.inc.php");
LogSetGlobalConfig(array("-autoMargin" => false));

// PEAR DB_DataObject
define('DB_DATAOBJECT_NO_OVERLOAD',true);

} // __Common__

?>

И еще, Pear использую только свой, а не тот который ставится хостером, то есть имеется своя сборочка только того, что мне нужно и того, что точно работает, так как мне нужно даже помнится исправлял DB_DataObject, потому что были ошибки, которые долго искал то есть, я считаю, что лучше не рассчитывать на стандартно поставленные библиотеки.

Здравствуйте, Аноним, Вы писали:

А>Дело в том, что я php использую очень часто для написания всяких консольных приложений, автоматических генерилок и т.д., то есть мне http или https совсем не нужно, для таких вещей я писал функции в своей библиотечке.

Я тоже, я писал недавно, что даже при написании такой вещи как прокси-сервер я сделал выбор в пользу PHP. Хотя, прокси в моем случае не консольное приложение, но консольных приложений я написал тоже не мало.

А>То есть, фактически я просто определяю пути к
А>1) библиотекам
А>2) исходникам ядра системы
А>3) шаблонам страниц
А>4) настроечным файлам
А>5) файлам сообщений на различных языках (английский, русский)
А>6) плагинам, если такие имеются
А>7) различным логам
А>и т.д.

По поводу "ядра" ("движка") я был бы не против вступить в дискуссию. Я ярый противник этих самых движков (точнее противник существования некоего главного объекта, обычно называемого как $rh или $theSite, который выполняет какой-то набор основных функций, агрегирует в себе несколько второстепенных объектов типа $db, $tpl, и выполняет какой-то набор действий в начале работы и иногда в конце) и у меня на сей счет есть целый ряд аргументов. Но наверное для этого лучше создать либо отдельную тему, либо вообще не здесь, а например, через e-mail или ICQ. Я долгое время тоже использовал "движки", в основном собственно производства, а потом пришел к убеждению, что все это утопия. Однако, я не считаю, что нужно писать все с нуля или без использования классов. Я пришел к иному подходу, который на мой взгляд оптимален для разработки и лишен недостатков, присущих "движкам", а они есть.

А>if (!defined("__Common__")) {
А>define("__Common__","");

ИМХО, это лишнее, если файл инклудится через require_once или include_once.

А>include_once "../home.inc.php";

Это не понятно, ведь файл находится в корне.

А>set_time_limit(0);

Это опасно. Скрипт может зациклиться или еще что и может неоправданно загрузить сервер. А в случае DDoS атаки сервер откинется быстрее. Там, где необходимо, я использую механизм "критических секций", который гарантирует непрерывание некоего обычно небольшого фрагмента кода из-за обрыва соединения (stop в браузере) или истечения тайм-аута.

А>define("cLogPath" ,cHomeScriptPath."log/");
...
А>define("cPluginPath" ,cSrcPath."plugin/");

Я для констант использую uppercase и underscope синтаксис. Эту традицию я перенял из Си, плюс это требование PEAR Coding Standards, которых я стараюсь придерживаться:

Constants should always be all-uppercase, with underscores to separate words. Prefix constant names with the uppercased name of the class/package they are used in. For example, the constants used by the DB:: package all begin with DB_.

Note: The true, false and null constants are excepted from the all-uppercase rule, and must always be lowercase.

А>ini_set("include_path",cLibPath."Pear".PATH_SEPARATOR.cHomeScriptPath.PATH_SEPARATOR.ini_get("include_path"));

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

А>И еще, Pear использую только свой, а не тот который ставится хостером, то есть имеется своя сборочка только того, что мне нужно и того, что точно работает, так как мне нужно даже помнится исправлял DB_DataObject, потому что были ошибки, которые долго искал то есть, я считаю, что лучше не рассчитывать на стандартно поставленные библиотеки.

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

G>По поводу "ядра" ("движка") я был бы не против вступить в дискуссию. Я ярый противник этих самых движков (точнее противник существования некоего главного объекта, обычно называемого как $rh или $theSite, который выполняет какой-то набор основных функций, агрегирует в себе несколько второстепенных объектов типа $db, $tpl, и выполняет какой-то набор действий в начале работы и иногда в конце) и у меня на сей счет есть целый ряд аргументов. Но наверное для этого лучше создать либо отдельную тему, либо вообще не здесь, а например, через e-mail или ICQ. Я долгое время тоже использовал "движки", в основном собственно производства, а потом пришел к убеждению, что все это утопия. Однако, я не считаю, что нужно писать все с нуля или без использования классов. Я пришел к иному подходу, который на мой взгляд оптимален для разработки и лишен недостатков, присущих "движкам", а они есть.

А какой, если не секрет? У меня "движок" состоит из набора не особо связанных между собой классов:

NS_FUNC — набор разнообразных функций, которые не уместились в других классах
NS_PAGE — отвечает за построение страницы согласно выбранному стилю. Внутри дополнительно разделяется на ns_page_xml, ns_page_smarty, ns_page_html. Вообщем, через factory
NS_ENC — encryption
NS_SESSION — куки, сессии
NS_USER — пользователи, раздача прав, считывание прав
NS_DB — на основе PEAR::DB

То есть, завязки на "силвер буллет", управляющий всем и вся нет

Здравствуйте, Mamut, Вы писали:

G>>По поводу "ядра" ("движка") я был бы не против вступить в дискуссию. Я ярый противник этих самых движков (точнее противник существования некоего главного объекта, обычно называемого как $rh или $theSite, который выполняет какой-то набор основных функций, агрегирует в себе несколько второстепенных объектов типа $db, $tpl, и выполняет какой-то набор действий в начале работы и иногда в конце) и у меня на сей счет есть целый ряд аргументов. Но наверное для этого лучше создать либо отдельную тему, либо вообще не здесь, а например, через e-mail или ICQ. Я долгое время тоже использовал "движки", в основном собственно производства, а потом пришел к убеждению, что все это утопия. Однако, я не считаю, что нужно писать все с нуля или без использования классов. Я пришел к иному подходу, который на мой взгляд оптимален для разработки и лишен недостатков, присущих "движкам", а они есть.

M>А какой, если не секрет? У меня "движок" состоит из набора не особо связанных между собой классов:
...
M>То есть, завязки на "силвер буллет", управляющий всем и вся нет

Примерно так, как делаешь ты. Но у тебя и нет ядра, а просто набор классов. Просто на моей текущей работе мне приходится работать с движком, который представляет из себя ядро в виде глобального объекта $rh класса RequestHandler, который хранит в себе конфиг (пути, различные опции), а на этапе инициализации создает внутри себя объекты для работы с БД и шаблонами, плюс включает output buffering и выполняет ряд действий по разбору URL, на основе этого разбора инклудит тот или иной файл-хэндлер. Для своей работы все классы получают в конструктор ссылку на объект $rh.

Схема в принципе рабочая, но возникает проблема совместимости. Подключить какой-то сторонний код, становится проблемой, приходится оборачивать все во wrapper'ы, и всячески извращаться. А при изменении класса RequestHandler придется переписывать большую часть всего исходного кода. В результате, когда появляется что-то нестандартное в задании, мы имеем такой нехилый геморрой. Я за то, чтобы был набор классов, которые были максимально самостоятельные и не завязывались на каких-то существующих в окружении объектах.

А>Просто на моей текущей работе мне приходится работать с движком, который представляет из себя ядро в виде глобального объекта $rh класса RequestHandler, который хранит в себе конфиг (пути, различные опции), а на этапе инициализации создает внутри себя объекты для работы с БД и шаблонами, плюс включает output buffering и выполняет ряд действий по разбору URL, на основе этого разбора инклудит тот или иной файл-хэндлер. Для своей работы все классы получают в конструктор ссылку на объект $rh.

А>Схема в принципе рабочая, но возникает проблема совместимости. Подключить какой-то сторонний код, становится проблемой, приходится оборачивать все во wrapper'ы, и всячески извращаться.

Беда PHPNuke'ов и прочей братии Из-за этого, в принципе, и решился написать фреймворк. Пусть кривой, пусть местами неработающий, но позволяющий изголяться так, как я хочу.

Здравствуйте, Geri, Вы писали:

G>По поводу "ядра" ("движка") я был бы не против вступить в дискуссию. Я ярый противник этих самых движков (точнее противник существования некоего главного объекта, обычно называемого как $rh или $theSite, который выполняет какой-то набор основных функций, агрегирует в себе несколько второстепенных объектов типа $db, $tpl, и выполняет какой-то набор действий в начале работы и иногда в конце) и у меня на сей счет есть целый ряд аргументов. Но наверное для этого лучше создать либо отдельную тему, либо вообще не здесь, а например, через e-mail или ICQ. Я долгое время тоже использовал "движки", в основном собственно производства, а потом пришел к убеждению, что все это утопия. Однако, я не считаю, что нужно писать все с нуля или без использования классов. Я пришел к иному подходу, который на мой взгляд оптимален для разработки и лишен недостатков, присущих "движкам", а они есть.

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

BK.inc.php
BKDoc.inc.php
BKDocTransaction.inc.php
BKOrder.inc.php
BKProcessing.inc.php
BKProduct.inc.php
BKProductCustom.inc.php
BKReport.inc.php
BKSettings.inc.php
BKSite.inc.php

То есть полный набор таких модулей я и называю ядром. Может быть не совсем правильно я это называю. Эти модули подключаю конкретно в функциях по мере необходимости. Размер одного такого модуля обычно не превышает 30-40 Kb, а в среднем это килобайт 20.

А>>if (!defined("__Common__")) {
А>>define("__Common__","");

G>ИМХО, это лишнее, если файл инклудится через require_once или include_once.
согласен, это навеяно сями, и было так и оставлено еще с тех времен, нужно будет как-то пересмотреть

А>>include_once "../home.inc.php";
G>Это не понятно, ведь файл находится в корне.

Дело в том, что у меня несколько подсистем работают с одним и тем же "ядром" и библиотеками, и каждая такя подсистема имеет свой корень, сам же home.inc.php находится в корне веб-пространства и его подключают все common.inc.php из всех подсистем.

А>>set_time_limit(0);

G>Это опасно. Скрипт может зациклиться или еще что и может неоправданно загрузить сервер. А в случае DDoS атаки сервер откинется быстрее. Там, где необходимо, я использую механизм "критических секций", который гарантирует непрерывание некоего обычно небольшого фрагмента кода из-за обрыва соединения (stop в браузере) или истечения тайм-аута.

Была такая проблем, зато я определил, где у меня подвисал скрипт Это опять же не во всех common.inc.php я ставлю set-time_limit(0). Мне это нужно больше для консольных приложений, которые работают больше времени, тот же запуск процессинга карточек клиентов может занимать достаточно много времени и он не должен быть прерван тайм-аутом, а то будут проблемы (финансовые)

А>>define("cLogPath" ,cHomeScriptPath."log/");
G>...
А>>define("cPluginPath" ,cSrcPath."plugin/");

G>Я для констант использую uppercase и underscope синтаксис. Эту традицию я перенял из Си, плюс это требование PEAR Coding Standards, которых я стараюсь придерживаться:

Это дело вкуса, я и в сях писал константы с символа "c". Тут дискутировать можно долго и все равно каждый останется при своем мнении. Мне просто читать так легче, не люблю множество этих подчеркиваний.

А>>ini_set("include_path",cLibPath."Pear".PATH_SEPARATOR.cHomeScriptPath.PATH_SEPARATOR.ini_get("include_path"));

G>Как правило нет нужды сохранять старый include_path, если ты явно определяешь все что тебе нужно. Тем более это может привести к трудно отловимым ошибкам, если у тебя какого-то файла нет и он подцепился из стандартных инклудов.

тут согласен полностью, возьму на заметку. Спасибо.

G>PEAR тоже загружаю свой, именно поэтому я говорил, что лучше не сохранять старый include_path, т.к. там скорее всего указан путь к PEAR-каталогу хостера. Однако, сам PEAR правлю крайне редко, и если я правлю, то обязательно связываюсь с автором и предлагаю ему внести в его код свои исправления по таким-то причинам.
У меня было возникла ситуация, когда скрипт валился, срочно нужно было решать проблему, я решил ее, исправив DB_DataObject, то есть просто, не было времени создавать маленький кусок кода, на котором выявляется эта ошибка. Ошибка была совсем не явная. Если я не ошибаюсь в последствии тот кусок кода был переписан автором и ошибка изчезла сама собой.

Здравствуйте, Аноним, Вы писали:

А>У меня общий класс только для генерации страницы по шаблонам, то есть некий фреймоворк. В моем понимании "движок" это не есть общий класс, это набор функциональности, логически разбитой по модулям.

Ну, это нормально. Главное, чтоб не было "слонов на веревочке", которых необходимо всюду таскать.

А>>>set_time_limit(0);
А>Была такая проблем, зато я определил, где у меня подвисал скрипт Это опять же не во всех common.inc.php я ставлю set-time_limit(0). Мне это нужно больше для консольных приложений, которые работают больше времени, тот же запуск процессинга карточек клиентов может занимать достаточно много времени и он не должен быть прерван тайм-аутом, а то будут проблемы (финансовые)

У консольных приложений и так time_limit = 0, я имею в виду не cgi/php.exe, а cli/php.exe