У меня тоже такие мысли.. Пока не вижу необходимости излишне усложнять.

Хм... По мне так, ядро - это один файлик, например /kernel/kernel.php...

У меня так:



Ну, и далее пляшем от этого. Т.е. в ядре в основном иклюдятся конфиги/классы и так далее. Не понимаю, какие функции должно еще выполнять ядро. Работа с бд - уже дело определенного класса, шаблонизатор - то же самое. Логгер или еще что-то - туда же 

Как считаете? Или хотя бы опишите, что ваш класс ядра будет делать, кроме как инлюдить конфиги.

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

"Ядро" в PHP - штука IMHO бессмысленная.


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

Любой копонент публикует свой функционал в виде статических методов "входного" класса (фасад). По любому ты знаешь, что используешь. Взаимозаменяемые по функционалу модули должны описываться общими интерфейсами (в смысле сущности interface). Движок PHP отвечает за всё остальное.

Лень много писать. Почитайте как взаимодействуют уровни в TCP/IP протоколе. Мб станет ясно

Интересное сравнение...  быть может я путаю, под взаимодействием считается концептуальные вещи, в коде же само ядро - лишь набор коментариев (guide-line)? ;-)

Хотя пример не удачный, IP оборачивает TCP, добавляя понятие адреса (+сам протокол адрсации, TTL и т.д.), второй же вводит понятие порта (+ понятия коннекта, sequence и т.д.). Могу расписать побайтово, т.к. это был один из моих проектов (сетевуха на микроконтроллере). Корреляции с понятием "ядра" в этом топе не вижу...

Ясно, что ясно не стало. Нашелся лишь повод кинуть "понт"

Это сообщение отредактировал(а) ImamMahdi - 29.2.2008, 15:26

Например о сообщеиях типа "авторизация пользователя", "изменение контента" etc.
Конечно, если нет общего понятия контента, то нет и необходимости в большинстве этих сообщений. Правда тогда и наповедение этого контента можно повлиять только если залезть в исходники. Да и систематизировать те же блоги сможет только модуль "блог" и никто больше.
То, как я вижу это пытался изложить в  Общая концепция Vingrad CMS

А отсутсвие подгрузки по требованию -- статичный набор модулей.


Вот и добрались до самого интерестного. "Ядро" и должно определять эти интерфейсы.

Это сообщение отредактировал(а) solenko - 29.2.2008, 17:17

Смотря как реализовать. Пусть:


Как такового ядра (код) не существует, есть лишь принцип дизайна, которому следуют все компоненты.


А чем плох статичный набор модулей? При использовании кода ты точно знешь, какой интерфейс ты собираешся использовать (в Java к тому же это на этапе компиляции проверить можно). Реализация набора интерфейсов может изменятся на момент исполнения, ты же не привязан к конкретному коду. Интерфейс - контракт, что и как ты хочешь использовать.


Как при проектировке "ядра" узнать какие интерфейсы будут в компонентах системы? Слишком абстрактные интерфейсы типа .get/.set и .callByName - штука глупая в PHP.

Я бы не брал на себя отвтственность за решение "пользователю понадобится это и только это"
Вы osCommerce случайно не проовали расширять?) Он спроектирован так, что добавлять можно только модули оплаты и доставки. Все остальное лепят программисты путем изменения core исходников. Мягко говоря очень неудобно, не говоря уже о user friendly. 

Вы читали то что я предлагал в соседней ветке? Я предлагал вынести в ядро некоторые базовые понятия. В частности, такие как контент, форма, пользователь. 
Кроме того, я считаю, что система должна быть event-ориентированной, т.е. каждый модуль может добавить листенер на core объект (контент, форма, пользователь) и, соответственно, породить такое событие. Т.е. если есть некий модуль, занимающийся... ну например блогом и модуль, который в этот блог добавляет маааленькую фичу (например добавление поля со ссылкой), то достаточно обработать события (form, load, save) контента (blog) и выполнить действия.
 Также должна быть возможность регестрировать новые виды событий (например модуль оплаты товара должен регестрировать событие "оплата завершена").

Всё, понял, за ядро принимаем набор базовых компонент, хотя и не обязательно "совершенно необходимых" (к примеру юзер не везде нужен). Просто было предложение:


Было интересно о каком взаимодействии идёт речь. Жаль что мысль испарилась вместе с автором...


Так я не о пользовательском функционале говорю, а о банальной организации кода. Если есть несколько классов, способных выполнить задачу и им помощь некоторого общего "ядра" не требуется, то значит оно (ядро в понятии ImamMahdi) и не нужно вовсе...  То что ты называешь "ядром", обычно зовут коллекцией основных библиотек. К примеру тут (это лишь  кусочек движка, извиняюсь за жуткий код, писалось давно  ), можно взять Cache::getCache(.. и использовать. То же самое для любого другого компонента системы, причин писать отдельный код для "взаимодействия" пока не вижу...

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

При запросе конкретной записи блога запрос не идет на модуль "блог". Он иет на модуль "контент", который формирует базовый объект контента и отправляет сообщение другим модулям, которые могут этот объект дополнить/изменить.

Т.е. в обход модуля "контент" работать просто нельзя.

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

Ещё была идея полной анархии в движке 
Представим есть дипетчер запросов, он ловит все запросы, согласно файлу-схеме (простой XML) находит и запускает "процесс". "Процесс" поднимает компоненты, как это прописано в его схеме, не вдаваясь в подробности зачем этот компонент и что он будет делать (к примеру инклюдит класс, вызывает статический метод). Компонент поднимает необходимые ресурсы (DataBase::getConnection(); Configuration::get(..); Output::registerProvider("me", $this) etc), затем сам делает полезную работу, формирует DOM дерево и ожидает пока его заберут. Он без понятия что будет с этими данными, как их отформатируют и куда вставят.

Общий шаблонизатор поднимает необходимые шаблоны, как это задал дизайнер, собирает страницу. Именно "схема процесса" описывает всех провайдеров данных и применение к ним шаблонов. Главный шаблон раскладывает инфу по местам на странице.

Заметим нет понятия ядра/проклейки, компоненты не обязательно должны знать друг о друге (хотя контент-генератор может сказать компоненте-главное-меню, что сейчас открыт такой то ресурс, хотя это можно реализовать и более элегантно). Все компоненты используют коллекцию базовых библиотек независимо друг от друга (один раз открытое БД соединение используется всеми). Удаление одного компонента не вызовет каких то проблем с зависимостями, можно даже Output удалить, все будут работать, только на выводе будет формироваться пустая страница (или страница ошибки, нет компонента-провайдера страницы).

2модератор - по моему пора разделить тему, последние посты во "Внутренняя организация движка" могут пойти.

Sardar, ты с drupal не знаком (думаю стоит ли пытаться расписать)? Просто идея, которую я пытаюсь продвинуть, вышла как раз оттуда. Там как раз и есть почти полная анархия + базовое понятие node, что позволяет оперировать контентом единообразно.



"контент" это несколько полей для сохранения в базу (title, user, дата создания и т.д.) + набор событий. То, что получается очень гибко доказано все тем же друпалом. Вот только он из за своей гибкости слишком уж  тяжеловесен -- хотелось бы найт золотую середину.

Стоит, быть может по ходу мыслей придём к удобному дизайну/архитектуре движка. Возьми для этого новую тему