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

1. в ПХП есть автолоадер. подробноcти Жека Шарин может рассказать, или РТФМ. в кратце - класс загружается тада, када втречается его экземпляр.

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

interface HTMLObject()
{
function toHTML();
}

interface DBObject()
{
function toSQL();
}


class BaseObject implements HTMLObject, DBObject
{
function toHTML()
{echo "BaseObject->toHTML()\n";}
function toSQL()
{echo "BaseObject->toSQL()\n";}
}

class myFirstObject extends BaseObject
{
function toHTML()
{echo "myFirstObject->toHTML()\n";}
function toSQL()
{echo "myFirstObject->toSQL()\n";}
}

class mySecondObject extends BaseObject
{
function toHTML()
{echo "mySecondObject->toHTML()\n";}
function toSQL()
{echo "mySecondObject->toSQL()\n";}
}

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

вот я написал все это, такая банальщина... даже не знаю, ответил ли на поставленный вопрос?
типа наледованию учат в школе... :)

есть еще 1 паттерн - посетитель (визитор). используется в лучае, если нет возможноти менять базовые классы :)

Да не, я может как-то не так выразился, проблема не в том чтобы подключить или расширить класс, с ооп и автолоадером всё понятно (по крайней мере в это случае :] )..
Давайте простецкий и конкретный пример приведу: есть админка, в ней есть функции редактировать А, добавить А и редактировать Б.. (пусть А и Б - статьи и контент индекса соответственно..) Вот, значит, меню админки со ссылками на редактирование могут быть или статикой или храниться в базе.. А если я дописал модуль В (например старница О_нас), то чтобы ссылка на его редактирование появилась в админке и движок включил в себя сам модул и ссылку на него в меню добавил, мне приходится с каждым модулем поствалять ини-шник/тхт-шник/или_другой_изврат чтобы потом запустить скрипт апдейта цмс из указанного файла, который читает инструкции и добавляет код куда надо... Так вот я бы так и делал, но когда система разростается, всё более сложно ей объяснить как саму себя переписать с учётом нового модуля - обычно обновлял меню, создавал таблицу (если надо) для модуля в базе, и после этого в основной движок впихивалась строка с include и именем файла модуля.. Обычно просто сдвигал весь код на одну строку вниз, и новый инклуд/рекьюре всегда ставил на 14 строку (так уж повилось :] ) А вот если мне надо чтобы 6 по счёту модуль стоял(то есть инклудился и выполнялся) обязательно перед 3 (например какой-то финт с заголовками)? Ориентироваться по названию предыдущего не вариант - его может и не быть, номер строки считать - тоже опасно, малоли что-то дописал вначало основного движка, придётся все модули переписывать.. Опять всё сводится в служебной инфе, где указано, какие строки каким типам модулей принадлежат, что после 8й например заголовки уже использовать нельзя.. и тогда приходится добавлять модули чтения инфы о том, куда можно в модули для основной цмс, в обычные модули или скрипт распознания типа модуля писать.. а если я добавил ещё модуль с заголовками, то 8я стала 9й, значит надо обновить и эту инфу ))) и так бесконечно и бесконечно этот шар наростает, так что я подумал, что есть более простое и надёжное решение чем храниние всех данных необходимых для подключения модуля в файлах и скриптах.. потому что скоро правила и функции апдейта будут весить больше самой цмски..

чё-то много написалось, наболело )
Пример вкратце: как решить обновление админки с расщётом на то, что модуль может быть написан любой и движок 'о нём ничего не знает'. Причём хорошо бы чтоб решение было универсальным )

Может быть обязать каждый лмодуль регистрировать себя? и реализовывать все эти сложности как раз в ф-ции регистрации модуля в приложении?

тоесть добавить:

interface CMSObject()
{
function Register();
}

ну и там все должно произойти (естественно через интерфейсы, предусмотренные движком). Например:
- добавить скрипты JS
- предложить (!) свой заголовок.
- зарегистрировать события
- итд-итп....

касательно заголовка. вообще все сайты есть суть иерархия. за сим - в звголовке может быть 1. тайтл последнего элемента, 2. составной тайтл (из Н или из всех элементов пути от корня сайта до текущего элемента) 3. тайтл корневого элемента сайта.

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

а какие еще варианты формирования заголовка у тебя встречались?

Простое в этом смысле решение предлагает всеми нелюбимый PHP-Nuke: админка при обращении к файлу управления модулями сканирует каталог modules на предмет изменений (инфа о модулях хранится в виде таблицы в БД, а каждый модуль - эт одноименный каталог в /modules), синхронизирует состав модулей с содержимым БД. При открытии админки читается инфа о модулях из БД, потом для каждого модуля инклюдиццо файл /modules/MODULE_NAME/link.php, в котором содержиццо ссылка на админский скрипт модуля (вот примерно как Евгений в предыдущем посте показал). И фсё, афтоматически формируеццо админское меню.

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

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

___
з.ы. На самом деле вопрос, конечно, 'из пальца высосан', потому что под конкретный проект всегда сделать можно, но очень хочется найти универсальное и простое решение.. Может кто-нибудь подскажет где материал поискать именно по теории программирования на интерпретируемых языках? )
з.з.ы За примеры спасибо, у меня родилось пара идей )

2 Сергей Ульяновский: про COM объекты можно почитать... полностью вещь в себе, платформо и языконезависимая :)

а вообще - движок = логика. и объекты должны подчиняться этой логике.

вот пример с кэшированием, логика мне каж следующая:
если хотя бы 1 объект на странице не должен быть закеширован, кэшировать стр не нада.

соответственно, если хотя бы о1 объект при регистрации (CMSObject->Register()) скажет, что кэша не нада, приложение дожно вывести соотв заголовки.

так же примерно и по другим вопросам, заголовки, мета, трам-пам-пам :)

но это подразумевает, что страница выводится потом, уже после регистрации объектов :)

вот такая вот концепция :)

У меня сразу вся логика физически в голове не укладывается ) Нужно рисовать.. листочков, наверно, больше чем принтер извёл )

наверно нада :)) почитай про ком-обжекты :)

оке ) может линк на книжечку подкинешь или название подскажешь? )

тут есть ссылочка, книжка элджера замечательна для тех кто хочет понять сложные идиомы ООП. Правда там все на С++. Но на мой взгляд - С++ - база которую нужно знать 100%.

http://http://evgenybaranov.nm.ru/about_me...fficial/books...

пасиб.. но это ты сурово как-то ) С++ крутоват для плавного подъёма к вершинам.. )

Вообще в данном случае идеально писать модуль и "паковать" в XML, написать класс добавления/удаления модуля. Геморно, согласен, зато 1 раз и потом париться не будешь

а если новые требования к классу добавления, то, по идее, апдейтить движок? Тогда как быть со старыми модулями?

писать модули на глобальных, общий конфиг

2 Сергей Ульяновский:
ну типа полезно будет. потом там все-таки еще и словами много написано....

2 Глеб ◄Nightingale► Стржеговский:
согласен. такая концепция мне нра тоже. но я таких ЦМС не встерчал. и все равно остается уровень логики, которая должна быть все равно реализована классом ПХП. ибо обжект это не только свойства, но и методы.

Покопайте в сторону PEAR http://pear.php.net почитайте как для репозитория создаются модули и как там всё красиво ставится )

Пример:

У тебя движок имеет папку в которой он смотрит на определенные файлы (допустим *.mod) в котором прописано что:
- у тебя создается база с такой-то структурой - такие-то запросы
- при удалении мода - такое-то запросы
- список инклудов для различных файлов движка (могут быть или в самом этом файле или в подпапке)
- + в подпапке сами файлы модуля, которые и заниваются сторонней обработкой информации.

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

2 Михаил AzazeL Давыдов:

покопаем обязательно! а можно тут концепцию в 2 словах описать?

Не просто в 2-х словах описать )
Опишу основные:
0. Контроль версий и модулей
1. Всё жестко оформляется (XML)
2. Есть собственный репозиторий модулей. Не надо искать по многочисленным сайтам.
3. Если ставится библиотека и ей не хватает чтонить то она __сама докачивает необходимую версию необходимого модуля__! Это очень важный момент!
4. Есть такая возможность включать в скрипты при установке пользовательских переменных по средством регулярных запросов или замене констант (прим: урл темп папки, емеил пользователя и пр.) Типо маленького сетапа как в винде.
5. Оно даже может само собрать сишные библиотеки, включенные в модуль и установить их!!! о_О

Это отличительные возможности.

Чем разрабатывать свой стандарт тех же XML файлов потом писать XSD...
используйте наработки людей там всё идеально заточено для модулей.
http://http://pear.php.net/manual/index.php (ru)
http://http://pear.php.net/manual/ru/
http://http://ru.wikipedia.org/wiki/PEAR

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

MFC - и то непросто :)

сразу же, что не понра в PEAR. Смотрю пакет:

http://http://pear.php.net/package/XML_Parser

8<---------------------------------------------------------------------------
----
This is an XML parser based on PHPs built-in xml extension.
It supports two basic modes of operation: "func" and "event". In "func" mode, it will look for a function named after each element (xmltag_ELEMENT for start tags and xmltag_ELEMENT_ for end tags), and in "event" mode it uses a set of generic callbacks.
8<---------------------------------------------------------------------------
----

непонятно, зачем это надо? если есть кроссплатформенные либы (в тч и и в ПХП) которые осуществляют XSLT преобразование. Зачем еще что-то сверху этого????

короче говоря, боюсь, что остальное тоже не очень нада, но все таки попробую поизучать исчо :)

1. В пиар(на ум пришло PR =) ) ярунду не добавляют. Наверно эта весч удобна)
Зачам тогда абстракция СУБД - PEAR MDB2, DB? )

2 Михаил AzazeL Давыдов:
ну про абстракцию субд - это понятно. отделяется управление хранилищем данных.

а вот нафига делать приблуду к к стандарту (дефакто и деюре), я не понимаю. :) лан, буду еще глубже копать :)

2 Сергей Ульяновский
- по поводу номеров строк для инклудов и "модулей, которые могут быть ответственны за что-то связанное непосредственно с выводом кода в браузер", мне кажется, что сами эти модули ни в коем случае не должны осуществлять вывод сами (к тому же, как я понял, есть отдельно шаблонизатор), пусть у них устанавливаются соответствующие переменные (с мета-тэгами, тайтлом, основным контентом), тогда порядок инклудов становится не важным - пусть с этими переменными работает работает отдельный модуль, который отвечает за формирование html-кода страницы (шаблонизатор, или что там?), который сначала опрашивает все модули на наличие соотв. переменных для составления тайтла, потом для составления списка мета-тэгов, списка миниблоков и т.п.. Таким примерно образом решается проблема того, что "модуль может быть написан любой и движок 'о нём ничего не знает'". Так сказать, больше универсальности. =) Мне кажется, Евгений Баранов именно что-то такое сообщал нам на первой странице темы.

2 Сергей Ульяновский

- по поводу модуль В (например старница О_нас), я бы, наверное, отдельно создавал бы спец. модуль, который бы отвечал за все однотипные по сути разделы стат. инфы (всякие странички или разделы страниц), а не порождать для каждого свой модуль; т.е. все странички хранятся в одной таблице БД, доступ ко всем унифицирован, на всех одна единственная админка, соответственно, только выводятся они на сайте в разных местах (для определения места каждого можно создать второй микромодуль (чисто админский), ну, если там шаблонизатор какой, то, грубо говоря, для ручного сопоставления id и имен шаблонных переменных, хотя я не понимаю сейчас, что говорю:).

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

статья по вопросу динамически подключаемых модулей, нашел статейку:

http://http://www.codenet.ru/webmast/php/dynamic-classes.php

но опять же в свете автолоад - сомнительными выглядят все эти конструкции.