Я попытаюсь тут
разъяснить то, как я подхожу к написанию сайтов, где
могут применять подключаемые модули. Пример тому
известный скрипт 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.
config.php
<?php
#Модуль по умолчанию
$sys_def_mod="mod1";
?>
Вот примерная схема
работы index.php
Теперь создадим два файла
mod1.php и mod2.php и положим их в каталог mods.
mod1.php
Поясню немного вот эту
строку
if (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }
В каждый модуль
желательно включать такую проверку во избежании вызова
файла модуля вне самого index.php. На примере моего
портала до вызова модуля у меня идет подключение в базе
данных, считывание некоторых глобальных переменных и без
них, ни один модуль сам по себе работать не сможет. Так
что лучше всего просто запретить вызов модуля напрямую.
Вызов модулей в данном случае производится через строку
в виде index.php?mod=имя модуля, но тут можно применить
и систему ЧПУ. Тогда URL примет вид index.php/имя
модуля/
Вот в принципе очень
грубая схема реализации модулей. Можно добавить любой
модуль, просто положив его в каталог mods/ и
придерживаясь общей концепции работы, построить очень
сложный сайт. В чем удобства работы? По сути вы
отодвигаете от себя основную заботу по натягиванию кода
на дизайн. Это делает один раз в index.php. Сам же
модуль должен только работать и приносить пользу.
Централизация сбора основной информации из базы или
конфигурационного файла, глобальные переменные сайта,
информация о пользователе и т.д. С другой стороны есть
недостатки (хотя при определенном взгляде они не кажутся
недостатками), скажем надо четко следить за тем какие
имена переменных используются до модуля, чтобы не
перезаписать, случайно, их внутри модуля. Один раз у
меня такое случилось. После такого случая, я взял для
себя за правило называть системные переменные в таком
виде $sys_имя переменной. Другой очевидный недостаток
это трудность реализации разных вариантов дизайна для
разных модулей. Но! Тут есть выход тоже.
Если взять за правило,
что каждый модуль обязан сам вывести шапку и низ сайта,
то вам уже предоставляется свобода по выбору что и как
выводить.
К примеру, наши простые
модули можно модифицировать в таком варианте.
<?php
if (!eregi("index.php", $PHP_SELF)) { die ("Access denied"); }
$PAGE_TITLE="Это Я, модуль номер 1!!!";
include("inc/top.php");
echo "Это модуль номер 1!<br>";
echo "А <a href='index.php?mod=mod2'>здесь</a> можно
посмотреть на модуль номер 2";
include("inc/bottom.php");
?>
Как делать в данном и
конкретном случае решать Вам. Я же просто попытался
направить тех, кто начинает писать на php, а может и
тех, кто уже пишет, на определенный вариант или стиль
программирования.
http://www.x-bios.3dgames.ru/
- Сайт моего портала, но к сожалению он закрыт
http://fallenangels.combats.ru/
- Сайт игрового клана, также полностью построен на
модульной системе.
Библиотека GTK+ прошла долгий путь развития и сейчас очень популярна. GNOME, одна из ведущих оконных сред, использует GTK+ почти исключительно, GIMP построен на GTK+, множество коммерческих разработчиков ПО, таких как Abobe, NVidia и VMware, решили использовать эту библиотеку в качестве графической основы для своих продуктов... подробнее
Slashdot.org – популярный новостной портал с посещаемостью 50 млн. человек в месяц. Авторы проекта добились такого успеха, предоставляя пользователям свежие и интересные новости из мира IT... подробнее
Здесь рассматривается вопрос, что бывает, если запустить некий скрипт почти одновременно (что происходит, например, при большой нагруженности сервера) несколько раз, т.е. запустить несколько копий одного и того же скрипта. И к чему это может привести... подробнее
...и снова о спаме. Кто о нем только не писал, и все писали, что это плохо и ай-яй-яй. Я не буду оригинальничать, и тоже скажу – это плохо. Это ай-яй-яй. Как бороться со спамерами со своей стороны... подробнее