Модульное программирование на PHP или как написать маленький портал
Я попытаюсь тут разъяснить то, как я подхожу к написанию сайтов, где могут применять подключаемые модули. Пример тому известный скрипт PHPNuke. Как бы не ругали его, подход, примененный в нем, к модульному программированию очень удобен. Но из-за корявости общего кода применять такой скрипт на серьезных сайтах, точнее скажем порталах, с большим количеством посетителей, не рекомендуется. Почему? Скрипт работает медленно, очень большая нагрузка на базу данных. Можно еще очень много чего описать, но это уже материал для другой статьи. Если кому интересно , то в интернете полно описаний этого движка. В PHPNuke я убедился сам. Мой основной проект NVIDIA BIOS Collection в начала базировался на PHPNuke, но постоянные проблемы с хостингом заставили меня начать разработку своей система портала с нуля. Из PHPNuke я взять только суть модулей, все остальное же делал сам. И так для начала. Прежде всего, надо продумать систему каталогов, что и где будет лежать. Вот примерный вариант.
* /mods/ — каталог для хранения модулей
* /img/ — картинки
* /include/ — каталог вспомогательных файлов
Это что нам сейчас пока надо. Применять блоки и скины мы пока не будем. В моем портале также были другие каталоги
* /blocks/ — Тоже своего рода модули, но не выводящие сами информацию, а возвращающие заполненную переменную.
* /js/ — каталог для Java скриптов
* /theme/ — каталог выбора тем или, грубо говоря, набор скинов для сайта.
* /files/ — файлы для скачивания
В корневом каталоге храниться всего один файл index.php и вся работа идет через него. Теперь надо решить как будет выглядеть сам сайт. Для нашего примера подойдет наипростейший вариант дизайна , верх сайта , низ сайта, а в середине наша информация из модулей. Для этого в каталоге include создадим два файла top.php и bottom.php, что соответственно будет верхней частью дизайна и нижней частью дизайна.
Предвижу комментарии, где скажут, почему я не вывожу HTML код отдельно, а php отдельно. Я приучил себя к написанию 100% PHP кода, с одной стороны не очень и красиво может выглядеть, но мне так удобнее. Если кто-то хочет писать по-другому, то тут я не советчик. Заметьте переменную $PAGE_TITLE в top.php. В моей реализации вся информация о модулях храниться в базе данных, где помимо имени файла модуля храниться также и его название, которое потом и кладется в $PAGE_TITLE, для вывода его в головок браузера.
Также создадим файл конфигурации config.php и положим его в каталог include.
Вот примерная схема работы index.php
Теперь создадим два файла mod1.php и mod2.php и положим их в каталог mods.
Поясню немного вот эту строку
В каждый модуль желательно включать такую проверку во избежании вызова файла модуля вне самого index.php. На примере моего портала до вызова модуля у меня идет подключение в базе данных, считывание некоторых глобальных переменных и без них, ни один модуль сам по себе работать не сможет. Так что лучше всего просто запретить вызов модуля напрямую. Вызов модулей в данном случае производится через строку в виде index.php?mod=имя модуля, но тут можно применить и систему ЧПУ. Тогда URL примет вид index.php/имя модуля/
Вот в принципе очень грубая схема реализации модулей. Можно добавить любой модуль, просто положив его в каталог mods/ и придерживаясь общей концепции работы, построить очень сложный сайт. В чем удобства работы? По сути вы отодвигаете от себя основную заботу по натягиванию кода на дизайн. Это делает один раз в index.php. Сам же модуль должен только работать и приносить пользу. Централизация сбора основной информации из базы или конфигурационного файла, глобальные переменные сайта, информация о пользователе и т.д. С другой стороны есть недостатки (хотя при определенном взгляде они не кажутся недостатками), скажем надо четко следить за тем какие имена переменных используются до модуля, чтобы не перезаписать, случайно, их внутри модуля. Один раз у меня такое случилось. После такого случая, я взял для себя за правило называть системные переменные в таком виде $sys_имя переменной. Другой очевидный недостаток это трудность реализации разных вариантов дизайна для разных модулей. Но! Тут есть выход тоже.
Если взять за правило, что каждый модуль обязан сам вывести шапку и низ сайта, то вам уже предоставляется свобода по выбору что и как выводить.
К примеру, наши простые модули можно модифицировать в таком варианте.
Как делать в данном и конкретном случае решать Вам. Я же просто попытался направить тех, кто начинает писать на php, а может и тех, кто уже пишет, на определенный вариант или стиль программирования.
Источник статьи: http://www.internet-technologies.ru/articles/modulnoe-programmirovanie-na-php-ili-kak-sozdat-portal.html
PHP модуль — это просто
Недавно мы опубликовали визард для VisualStudio, с помощью которого можно создать экстеншн в пару кликов мыши. Теперь с помощью него мы напишем наши два первых расширения: «Привет, мир» и «вытащим иконку из exe».
Сразу прошу прощение, что очень сильно задержал статью, но жизненные обстоятельства вынудили это сделать, но они исключительно уважительные.
Итак, начнем.
1. Качаем «волшебника» для VS 2008.
По ссылке из темы VS wizard: PHP extension
Устанавливаем его, это произойдет автоматически.
2. Скачиваем необходимые для сборки файлы.
Нужны лишь исходники PHP и бинарники. Скачиваем 5.2.11 версию обоих файлов
Разархивируем php-5.2.11-Win32.zip в C:\PHPDEV\php-5.2.11-Win32 и php-5.2.11.tar.bz2 в C:\PHPDEV\php-5.2.11.
3. Запускаем VS, создаем новый проект. 
И вводим его название. Пути настраивать не придется 😉 
После этого видим главное окно студии, смотрим, что же там в файлах. 
4. Создаем функции.
Как уже замечено, то скелет полностью создан, осталось лишь написать функции и прописать их.
В проекте есть тестовая функция, раскоментируем ее.
Для справки:
1) Заголовок функции должен быть в h файле. В виде PHP_FUNCTION(имя_функции).
2) Определение — в c файле.
3) Функция должна быть прописана в function_entry test_functions в c файле. В виде PHP_FE(имя_функции, NULL).
Как написать саму функцию, я расскажу позднее. А пока ограничимся этой:
5. Сборка и запуск.
Собираем в релизе. Собралось.
Создаем каталог C:\PHPDEV\test
Копируем туда php.exe и php5ts.dll из каталога.
Копируем собранный dll под именем test.dll.
Создаем php.ini:
extension_dir = .
extension = test.dll
Создаем test.php со строкой и запускаем его в консоли. 
6. Продвинутое создание функций.
Разберемся, как принимать значения из функций и передавать их.
Сложность заключается в том, что функция принимает и возвращает различные значения различных типов.
Рассмотрим пример, при котором принимается строка и целое и возвращается строка.
Как можно увидеть, здесь использованы следующие конструкции:
zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, строка_формата, адреса_дляполучаемых_значений)
RETURN_*;
Рассмотрим 2 таблицы, в первой указаны принимаемые PHP-типы и соответствующие им форматы и типы C.
Во второй возвращаемые значения с соответствующими конструкциями.
Дабы не утруждать себя, я прилагаю фотографии таблиц из книги, которую я всем советую прочитать. 
Еще раз смотрим на примеры выше и понимаем, как все просто.
Кстати хочу обратитьт внимание, что выделение памяти ведется через e-аналоги функций c(emalloc, efree, erealloc), это нужно для того, чтобы GC PHP сам смог «прибраться».
7. Полезный пример. Вытащим иконку из exe.
Конечно можно написать это и на PHP, но работы будет больше. А тут уже есть необходимые заголовки.
Напишем код на C(писал одепт bl4de):
В файле pe.h мы видим использование кусков кода из библиотек windows: они нам помогут, а прямое их подключение невозможно, мы ведь пишем кроссплатформенное расширение, не так ли? 😉
В pe.c же пишем код. Как и понятно, мы будем оборачивать функцию void _extract_ico(char *filename, char *filenameOut).
Источник статьи: http://habr.com/ru/post/75388/
Модульное программирование на PHP или как написать маленький портал
Я попытаюсь тут разъяснить то, как я подхожу к написанию сайтов, где могут применять подключаемые модули. Пример тому известный скрипт PHPNuke. Как бы не ругали его, подход, примененный в нем, к модульному программированию очень удобен. Но из-за корявости общего кода применять такой скрипт на серьезных сайтах, точнее скажем порталах, с большим количеством посетителей, не рекомендуется. Почему? Скрипт работает медленно, очень большая нагрузка на базу данных. Можно еще очень много чего описать, но это уже материал для другой статьи. Если кому интересно , то в интернете полно описаний этого движка. В PHPNuke я убедился сам. Мой основной проект NVIDIA BIOS Collection в начала базировался на PHPNuke, но постоянные проблемы с хостингом заставили меня начать разработку своей система портала с нуля. Из PHPNuke я взять только суть модулей, все остальное же делал сам. И так для начала. Прежде всего, надо продумать систему каталогов, что и где будет лежать. Вот примерный вариант.
- /mods/ — каталог для хранения модулей
- /img/ — картинки
- /include/ — каталог вспомогательных файлов
Это что нам сейчас пока надо. Применять блоки и скины мы пока не будем. В моем портале также были другие каталоги
- /blocks/ — Тоже своего рода модули, но не выводящие сами информацию, а возвращающие заполненную переменную.
- /js/ — каталог для Java скриптов
- /theme/ — каталог выбора тем или, грубо говоря, набор скинов для сайта.
- /files/ — файлы для скачивания
В корневом каталоге храниться всего один файл index.php и вся работа идет через него. Теперь надо решить как будет выглядеть сам сайт. Для нашего примера подойдет наипростейший вариант дизайна , верх сайта , низ сайта, а в середине наша информация из модулей. Для этого в каталоге include создадим два файла top.php и bottom.php, что соответственно будет верхней частью дизайна и нижней частью дизайна.
Предвижу комментарии, где скажут, почему я не вывожу HTML код отдельно, а php отдельно. Я приучил себя к написанию 100% PHP кода, с одной стороны не очень и красиво может выглядеть, но мне так удобнее. Если кто-то хочет писать по-другому, то тут я не советчик. Заметьте переменную $PAGE_TITLE в top.php. В моей реализации вся информация о модулях храниться в базе данных, где помимо имени файла модуля храниться также и его название, которое потом и кладется в $PAGE_TITLE, для вывода его в головок браузера.
Также создадим файл конфигурации config.php и положим его в каталог include.
Вот примерная схема работы index.php
Теперь создадим два файла mod1.php и mod2.php и положим их в каталог mods.
Поясню немного вот эту строку
В каждый модуль желательно включать такую проверку во избежании вызова файла модуля вне самого index.php. На примере моего портала до вызова модуля у меня идет подключение в базе данных, считывание некоторых глобальных переменных и без них, ни один модуль сам по себе работать не сможет. Так что лучше всего просто запретить вызов модуля напрямую. Вызов модулей в данном случае производится через строку в виде index.php?mod=имя модуля, но тут можно применить и систему ЧПУ. Тогда URL примет вид index.php/имя модуля/
Вот в принципе очень грубая схема реализации модулей. Можно добавить любой модуль, просто положив его в каталог mods/ и придерживаясь общей концепции работы, построить очень сложный сайт. В чем удобства работы? По сути вы отодвигаете от себя основную заботу по натягиванию кода на дизайн. Это делает один раз в index.php. Сам же модуль должен только работать и приносить пользу. Централизация сбора основной информации из базы или конфигурационного файла, глобальные переменные сайта, информация о пользователе и т.д. С другой стороны есть недостатки (хотя при определенном взгляде они не кажутся недостатками), скажем надо четко следить за тем какие имена переменных используются до модуля, чтобы не перезаписать, случайно, их внутри модуля. Один раз у меня такое случилось. После такого случая, я взял для себя за правило называть системные переменные в таком виде $sys_имя переменной. Другой очевидный недостаток это трудность реализации разных вариантов дизайна для разных модулей. Но! Тут есть выход тоже.
Если взять за правило, что каждый модуль обязан сам вывести шапку и низ сайта, то вам уже предоставляется свобода по выбору что и как выводить.
К примеру, наши простые модули можно модифицировать в таком варианте.
Как делать в данном и конкретном случае решать Вам. Я же просто попытался направить тех, кто начинает писать на php, а может и тех, кто уже пишет, на определенный вариант или стиль программирования.
Источник статьи: http://www.codenet.ru/webmast/php/modules.php
Как создать свой сайт
При разработке php-проекта часто возникает потребность разделить его на небольшие части — модули. Слово «модули» довольно расплывчато и в разных случаях может трактоваться по своему, но в данном случае речь идёт только о том, что модуль — это некий код, который может представлять собой единую сущность.
Программно модуль может быть набором классов, функций и файлов. Он может содержать html-код, css-стили, js-скрипты, изображения и т.п. То есть не важно как в реальности реализован модуль, главное это то, что мы можем его воспринимать как единое целое.
Хорошим примером модульности может служить CodeIgniter (1-3 версий). В нём модуль представляет собой «обертку» над классами или функциям. То есть вместо того, чтобы писать сложный код подключения, инициализации и т.п., используется универсальный загрузчик, например так:
«Loader» берёт на себя задачу по подключению файла класса и его инициализацию (и даже поддержку как singleton). Дальнейшее использование сводится к обращению к методам класса encrypt в достаточно простом варианте:
В данном случае encrypt можно рассматривать именно как модуль CodeIgniter. Если бы речь шла о простом классе, то нам нужно было бы самостоятельно вызвать new , предварительно прописав подключение файла и т.д.
В данном примере encrypt очень простой класс, состоящий из одного файла, но гораздо чаще модуль состоит из множества классов и файлов. В этом разрезе становится очевидно, что модуль должен представлять собой уже каталог, где и будут размещаться все файлы модуля.
В таком случае подключение модуля становится не такой простой задачей, ведь среди всех файлов нужно найти его «точку входа». В разных php-фреймоворках задача решается различными способами. Самый простой — это размещение в каталоге модуля предопределенного файла, например bootstrap.php . То есть когда нужно выполнить подключение модуля, то загрузчик ищет этот «начальный» файл. Такой файл необходим, поскольку модуль может быть достаточно сложным и нужно обеспечить его корректную инициализацию. Также в этом файле обычно размещают и автозагрузчик классов.
Структура каталогов модулей этого варианта может быть такой:
Такой подход используется например в Fuel PHP Framework при подключени модулей packages.
Главный момент здесь в том, что файл bootstrap.php выполняет роль «буфера», через который происходит «адаптация» классов модуля к php-проекту.
Приведу небольшой абстрактный пример. Например нам нужно вывести слайдер на какой-то странице сайта. Сам слайдер требует предопределенную html-разметку. Также он содержит базовые css-стили и jQuery-плагин. Модуль должен уметь не просто сгенерировать готовый html-код, но и быть управляемым, например поддерживать все параметры jQuery-плагина через php-переменные, а также дополнительные опции, вроде своих css-классов.
Понятно, что такой модуль должен состоять из каких-то php-классов или функций, но также в модуле следует разместить и все «сопутствующие» файлы: css и js, например:
Файл bootstrap.php может содержать только загрузчик классов модуля. Поэтому работа с модулем может выглядеть так:
Данный вариант хорош тем, что используется единый подход к работе с модулем. Но при этом возникает проблема для модулей, которые не имеют единой «точки входа». Например модуль представляет собой просто набор не связанных классов. Примером может послужить база данных. В зависимости от типа базы (MySQL, sqlite, pdo), будут использованы различные классы.
Обычно такие модули выделяют в специализированные каталоги, вроде «core», «database», «classes» и т.п. То есть формально это теже самые модули, но которые работают по другим «правилам». Назвать это проблемой нельзя, хотя такой подход ломает «стройность» проекта.
Но на самом деле, проблема не только в этом. На сегодняшний день существует огромное количество готовых php-проектов, решающих практически все задачи. То есть вместо того, чтобы «изобретать велосипед», можно воспользоваться уже готовой разработкой.
Чтобы оценить объем возможностей приведу как пример The PHP Package Repository, где размещены описания на почти 220 тысяч (. ) проектов. Этот репозиторий используется менеджером Composer, который довольно часто используется в php-фреймворках.
Таким образом, если мы хотим воспользоваться чужой разработкой, то возникает довольно серьезная проблема встраивания чужого проекта в свой модуль. Дело в том, что php-разработчики используют самые разные подходы из-за чего с каждым проектом приходится разбираться индивидуально.
Например, кто-то использует классы, кто-то только функции. Кто-то использует namespace, кто-то нет. Кто-то придерживается PSR-4, кто-то нет.
В итоге структура модуля получит примерно такой вид:
Каталог distr содержит дистрибутивы сторонних разработок, которые используются в данном модуле.
У такого подхода есть два серьезных минуса. Первый — если несколько модулей используют один и тот же дистрибутив, то его придётся дублировать или создавать опасную связь между модулями. Второй — если дистрибутив имеет новую версию, то в своих модулях необходимо как-то организовать их обновление. При большом количестве модулей это может оказаться проблемой.
Очевидным решением будет вынос всех сторонних дистрибутивов в отдельный каталог. Здесь самое время ещё раз упомянуть добрым словом Composer, который и решает данную задачу. С помощью специального файла конфигурации Composer не просто скачивает все необходимые дистрибутивы, но и создаёт для них специальный автозагрузчик классов. Дистрибутивы Composer сохраняет в каталог vendor , где будет готовый файл autoload.php .
При такой схеме модуль может уже не иметь bootstrap.php (если используется Composer и подключен его autoload.php ). При этом уже не нужны никакие load_module() .
Модули в php-проекте должны располагаться в отдельном каталоге и соответствовать стандарту PSR-4, что позволит упростить их использование (через автозагрузчик).
При этом каталог vendor нужно оставить для Composer. Поскольку он автоматически формирует autoload.php , то в своем проекте достаточно будет лишь проверить наличие этого файла и подключить его.
Все дистрибутивы, которые могут использоваться повторно, но не относящиеся к Composer, нужно выделить отдельно, например в каталог distr . Здесь придётся как-то решить вопрос с автозагрузкой, но индивидуально для каждого дистрибутива, поскольку они слишком уж «разношерстные».
В заключении немного кода для index.php , чтобы стало понятно как это может работать в реальности.
- Вначале задаются константы для каталогов.
- После определяются автозагрузчики классов.
- Дальше показаны примеры использования в разных вариантах.
Вы можете скачать полный набор файлов. Классы простые для демонстрации, а для Composer’а я «прикрутил» парсер Parsedown. Вначале он вызывается сам по себе, а после из класса модуля.
Источник статьи: http://maxsite.org/page/php-modules