все дело в предоставляемой гибкости. У класса, как и обычного объекта могут быть свойства — это подобие статических свойств в программировании. Например, на сайте будет форма для создания новости. Само слово «новость», описание что зачем и куда.., человеко-понятные заголовки для полей — все это свойства класса. В следующей части будет понятней.
возможно, не спорю)) все ради гибкости и скорее это даже эксперементальный проект… думаю, когда полностью всё расскажу и раставлю по полочкам, эти идеи можно будет примить в других проектах, а возможно в будущем появятся механихмы специально оптимизированные под предложенное)) например те же ОСУБД или что-то другое оригинально. Главное почувствовать гибкость…
Позже будет пример, как вызовами методов модлуя Data будут созданы новые классы данных, определны свойства, созданы объекты. В принципе, можно поковырять исходники, если не терпится
сорри, но вы прокомментировали меня, исказив смысл сказанного. Никто не понимал, что существуют модули сообщений, статьей, комментариев, каталогов и т.д. Я предположил, что maxic посчитал, что в предложенной мною архитектуре применен подобный принцип. Поэтому он аргументировал применять иерархию, зная о неизбежных и серьезных проблемах с гибкостью при расширении функций cms с такой архитектурой.
Если все очень очень сильно упростить, то модуль у меня – эта банальная функция. И чтоб расширить действия, которая она совершает, используются события. Вот и все. Модули у меня не генерируют свой контент, не владеют своими ORM, вообще ничто не делаю кроме своего локального назначения. Модулю вообще по барабану на всех)) т.е. дали порабоать, поработает, сделает свое маленькое дело и про всех забудет.
Вы предположили, что модули системы определяют типы данных, т.е. для вас кроме модуля фотографий и файлов, я так понял, существуют образно модули сообщений, статьей, комментариев, каталогов и т.д., т.е. модули которые бы определяли и позволяли бы работать с разными типами данных. В принципе то, что мы можем наблюдать в большинстве CMS. Тогда такие вот модули конечно целесообразно было бы выстраивать в иерархическую зависимость, как нечто подобное наследованию классов.
Обращаю внимание, что предложенная здесь архитектура совершенно иная. Если не заметно – модуль данных на рисунке самый большой и находится в центре, демонстрируя свою значимость. Именно этим модулем управляются данные – это как объектно-ориентрованная база данных. Все зависимости и отношения между данными, а также типы данных контролируются этим модулем. Другие модули, как и сам пользователь, могут создавать свои типы данных, но для этого используется модуль данных, т.е. типы данных создаются в этой самой как бы объектно-ориентрованной базе данных (модулем Data). Работа с данными четко выстроена, что не имеет проблем из-за внешних факторов, от таких как последовательность обработки событий.
Один универсальный настраиваемый контроллер в системе есть – это совокупность модулей! Настройка контроллера сводится к установке/удалению модулей и регистрацией моделей на события. Вот как раз этот настраиваемый контроллер можно сравнить с электронной начинкой телевизора, модуль – это плата, для неё вроде есть разъем, воткнуть (установить) её просто, но есть ещё пара проводочков (обработчики событий) которые нужно так подсоединить в существующие разъемы, чтобы не нарушить общую логику работы телевизора (cms).
Вот и получается, что нужно либо сводить на нет зависимость от последовательности обработки событий, либо просто писать инструкции по установки модулей))) типа измените порядок обработки событий так чтобы…
Постойте, но у меня модули не управляют типами. Модули image, file — они только добавлют немного логики для модуля данных. а таких модулей как новости, категории и всякие прочие типы, так таковых не существуют.
Так вот эти правила не могут быть статичными — они зависят от назначения модуля — «ребенка» иерархии — это не иерархия из однотипных элементов как файловая система. Это скорее сложный механизм типа радиоузлов телевизора
так, мне кажется говорим мы об одном, а думаем о разном)) У узла иерархии могут быть несколько «детей» и порядок передачи данных/контроллера «ребенку» тоже будет иметь определяющее значение.
Но подобная проблема остается и с контроллером. Да контроллер будет определять, кому работать, но кто будет определять само условие выбора совершаемого контроллером? Если устанавливается новый модуль в систему, то контроллер должен учитывать этот появившийся модуль. А от куда контроллеру знать, когда этому модулю следует работать? Ручки администратора?? Но тогда администратор может редактировать и порядок вызова обработчиков событий. Наверно. Хочется, чтоб все-таки модули сами устанавливались, настраивались и работали как надо.
Что-то мне видится необходимость верных действий именно от человека для конфигурирования устанавливаемых модулей. Это как присоединение дополнительного жесткого диска в ПК требует правильной установки перемычки (Master/slave…) в самом устройстве.
Таскать данные по модулям? зачем? Зачем передавать модулю то, что ему, скорее всего, не надо? модуль сам берет только то, что ему надо. Передаётся только управление. И как уже показал, возникают исключения, которые нарушают строгую иерархию передачи управления – возникает что-то типа сети.
Есть одна проблема, я её где-то озвучивал — если у события несколько обработчиков, то от последовательности вызова обработчиков будет зависеть правильность функционирования системы. Вот что нужно как-то решить. Есть вариант в таком случаи вешать на события того модуля, после которого нужно работать. Но и здесь но! А если такой зависимый модуль устанавливается в систему как дополнение??? О нем же никто не знает, не знают, что нужно только после него работать?… думать нужно)
Если под объектами вы имеете в виду данные, которые я тоже называю объектами, дополняя их словом данные, то иерархия совсем не уместна, вы это поймете, когда я расскажу в новой статье про модуль данных. Модуль данный – это как банк данных, некоторые модули участвуют (контролируют) в манипулировании данными (создание/изменение/удаление/чтение), другие модули пользуются этими данными, например модуль страниц Page. Получается, что тоталитарного контролера нету, есть например контроллер-модуль страниц, который управляет отображением данных в html формате. Самое интересное, что есть данные так таковыми данными и являющиеся (статьи, фотки, категории…), а есть данные-представления – блоки, вьюшки… Чувствую без новой статьи сложно понять))
Если речь об иерархии, как о последовательности работы модулей и применения паттерна «цепочка обязанности», то этот вариант ещё возможен. Но реально он ничего не меняет. Посмотрите на рисунок событий – вроде иерархия. Но если отобразить все события, то будет не иерархия, а сеть. Не получиться выстроить последовательность работы модулей в иерархию.
Вот пример:
Как по рисунку событий в статье, выполняются события… модуль Request вызвал событие AFTER, первым его обрабатывает модуль данных Data, модуль Page ожидает своей очереди (он тоже зарегистрирован на AFTER), но вдруг в модуле Data возникает сбой, допустим, не может подключиться к БД – ошибка! Ошибка перехватывается модулем Errors. и модуль ошибок генерирует свое событие. На рисунке это событие не связано с модулем Page, но на самом деле модуль Page обрабатывает это событие – ему незачем ждать, когда придет его очередь от модуля Request!!! Несмотря на ошибку, модуль страниц корректно срабатывает и выводит красивую информации об отсутствии доступа к сайту.
Если все очень очень сильно упростить, то модуль у меня – эта банальная функция. И чтоб расширить действия, которая она совершает, используются события. Вот и все. Модули у меня не генерируют свой контент, не владеют своими ORM, вообще ничто не делаю кроме своего локального назначения. Модулю вообще по барабану на всех)) т.е. дали порабоать, поработает, сделает свое маленькое дело и про всех забудет.
Обращаю внимание, что предложенная здесь архитектура совершенно иная. Если не заметно – модуль данных на рисунке самый большой и находится в центре, демонстрируя свою значимость. Именно этим модулем управляются данные – это как объектно-ориентрованная база данных. Все зависимости и отношения между данными, а также типы данных контролируются этим модулем. Другие модули, как и сам пользователь, могут создавать свои типы данных, но для этого используется модуль данных, т.е. типы данных создаются в этой самой как бы объектно-ориентрованной базе данных (модулем Data). Работа с данными четко выстроена, что не имеет проблем из-за внешних факторов, от таких как последовательность обработки событий.
Один универсальный настраиваемый контроллер в системе есть – это совокупность модулей! Настройка контроллера сводится к установке/удалению модулей и регистрацией моделей на события. Вот как раз этот настраиваемый контроллер можно сравнить с электронной начинкой телевизора, модуль – это плата, для неё вроде есть разъем, воткнуть (установить) её просто, но есть ещё пара проводочков (обработчики событий) которые нужно так подсоединить в существующие разъемы, чтобы не нарушить общую логику работы телевизора (cms).
Вот и получается, что нужно либо сводить на нет зависимость от последовательности обработки событий, либо просто писать инструкции по установки модулей))) типа измените порядок обработки событий так чтобы…
Что-то мне видится необходимость верных действий именно от человека для конфигурирования устанавливаемых модулей. Это как присоединение дополнительного жесткого диска в ПК требует правильной установки перемычки (Master/slave…) в самом устройстве.
Есть одна проблема, я её где-то озвучивал — если у события несколько обработчиков, то от последовательности вызова обработчиков будет зависеть правильность функционирования системы. Вот что нужно как-то решить. Есть вариант в таком случаи вешать на события того модуля, после которого нужно работать. Но и здесь но! А если такой зависимый модуль устанавливается в систему как дополнение??? О нем же никто не знает, не знают, что нужно только после него работать?… думать нужно)
Если речь об иерархии, как о последовательности работы модулей и применения паттерна «цепочка обязанности», то этот вариант ещё возможен. Но реально он ничего не меняет. Посмотрите на рисунок событий – вроде иерархия. Но если отобразить все события, то будет не иерархия, а сеть. Не получиться выстроить последовательность работы модулей в иерархию.
Вот пример:
Как по рисунку событий в статье, выполняются события… модуль Request вызвал событие AFTER, первым его обрабатывает модуль данных Data, модуль Page ожидает своей очереди (он тоже зарегистрирован на AFTER), но вдруг в модуле Data возникает сбой, допустим, не может подключиться к БД – ошибка! Ошибка перехватывается модулем Errors. и модуль ошибок генерирует свое событие. На рисунке это событие не связано с модулем Page, но на самом деле модуль Page обрабатывает это событие – ему незачем ждать, когда придет его очередь от модуля Request!!! Несмотря на ошибку, модуль страниц корректно срабатывает и выводит красивую информации об отсутствии доступа к сайту.