Необходима теория создания блочной структуры админки и самого сайта

Извиняюсь если не туда пишу, нобходима идея построения блочной структуры CMS (своей). А именно как построить движок так что бы можно было без особых усилий добавлять новые написанные модули, таблицы в sql в админке ну и сам вывод, то есть при добавлении или удалении блока не нужно было делать много действий руками буду признателен за любую инфу.

модуль -> регистрация модуля в "ядре" -> показ модуля

в чём трабл?)

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

не пытайтесь повторять жумлу. Это не самый лучший пример для подражания.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Хорошо тогда какие операции должны происходить при этом?

как минимум зависит о того что собой эти модули представляют

лично я не вижу смысла регистрации модуля через админку, это толлко усложняет структуру системмы инфраструктурой единственное назначение которой подключение модуля через админку

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

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

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

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

примерчик бы построения не помешал, что бы понять идею

(Отредактировано автором: 15 Августа, 2013 - 15:49:38)

регистрация модуля... ядро... какие сложности... .
Единственно что присутствует в используемом движке — добавление "функций" сайта через админку (единственная запись в бд для построения всех связей с модулем админки и внешней части) и все. К ней же можно добавить страницу для удобного управлениям всеми метами заголовками и статичными текстами не динамических страниц.
Права юзеров, меню в админке и тд - пожалуйста ручками в конфиге админки. 1 контроллер 1 шаблон для вывода с внешки. Можно выстраивать их цепочки при желании. Все.
Шаблон есть то, что автоматически инклудится после отработки контроллера безо всяких там прокладок-шаблонизаторов. В админке для контроллеров функций сайта (контроллер в админке и контроллер внешки - независимые вещи и это правильно. Первый также прописывается в конфиге и это удобно легко и правильно, второй, - как указано выше) есть возможность заполнить шаблон но там идет создание одного единственного объекта класса View который визуализирует рабочую область админки в виде таблиц / списков данных (просмотр) или форм или wysiwyg-редакторе (добавление-редактирование).

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

Zuldek То есть вы хотите сказать что лучше под каждый проект просто ручками дописывать по требованию?