Идея для CMS (или это уже не CMS)

[eresik]

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

Вот размышлял над тем как должен выглядеть быстрый (в плане малой загрузки сервера) и "удобный для меня" конструктор сайтов, и выношу на суд общественности первые результаты размышлений/экспериментов.
Может конечно велосипед изобрёл (это случайно не model-view-controller?)

Знаком с wordpress и drupal.
Это системы основанные на контенте, всё крутится вокруг контента.

А что если сделать систему в которой всё крутится вокруг "типов страниц" (а не типов контента, как, например, в друпале)

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

3. ядро системы - определяет к какому типу относится запрашиваемая страница (например по урл - /тип_страницы/имя_материала

4. ядро системы создаёт объект класса типа страницы обслуживающего этот данный тип страницы (в конструкторе передаём имя_материала)

5. ядро системы опрашивает объект страницы "что будем показывать в этом регионе" (для всех регионов шаблона)

6. ядро системы передаёт собранную информацию в шаблон.

Само наполнение страницы - берётся из других классов, реализующих "типы материалов" (простой текст, текст с заголовком, карточка клиента и т.п.), или "блоки-виджеты" - комментарии и т.п.

т.е. логика работы ядра будет выглядеть так:
1. тип_страницы = (определили тип страницы по url)
2. имя материала=(определили имя материала по url)
3. require_once(class_тип_страницы.php);
4. $o=new class_тип_страницы(имя_материала);
5. Опросили - чего будем выводить в регионы шаблона
$regions['header']=$o->get_header();
....
$regions['footer']=$o->get_footer();
6. передали массив $regions в шаблон, чтоб все регионы попали на свои места на странице.

Минусы и плюсы
1. CMS вряд ли получится (надо лазить в код чтоб что-то поменять)
НО
поменять что-то на какой-то странице - легко и понятно где и как.

2. По поводу кэширования - сплошные плюсы (например, класс страницы может передать ядру информацию - какие регионы на этой странице можно кэшировать, и можно ли кэшировать страницу целиком)

3. Каждый тип контента реализуется в отдельной таблице базы данных (т.е. нет необходимости в модулях типа CCK в друпал) +к быстродействию

4. Загружаются только действительно необходимые для отображения данной страницы классы/модули +к быстродействию

5. Ясно видно какие блоки на каких страницах отображаются (не из админки конечно видно, а из кода)

6. Из-за чего собственно и начались размышления - возможность реализации "виртуальных" страниц, вообще не хранящихся в базе, а генерирующих контент по "имени_материала" в url. Ну и соответственно - возможность оставлять комментарии к таким "виртуальным" страницам.
Простой пример - имя_материала - любое слово, контент страницы - только комментарии к этому слову (пример надуманный, но нечто подобное как раз и понадобилось)


Если кто-нибудь что-нибудь понял. Прошу...

[badimao]

вуд вуд

[Anadonam]

да несомненно. конечно так оно сложно сказать сходу, но думаю смысл очевиден.

[boric]

eresik
У меня примерно так все и работает, только посложнее малек и еще гибче и не на пхп. Например через урл передавать тип контента - плохая идея. Да и зачем? Каждый объект должен сам знать, какого он типа.

Также видел самописные цмс, работающие почти так, как вы описали.

[shadx]

>>> get_region_header, get_region_footer

дальше не читал.

Выкинуть хедеры и футеры и начать думать заного.

[eresik]

Сообщение от shadx

Выкинуть хедеры и футеры и начать думать заного.

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

или просто заранее прописать постоянное содержимое в шаблон страницы.
(т.е. вызовом метода класс_типа_страницы->get_region_header() - всего лишь запрашиваем доп информацию выводимую в хеадер, если она есть)

Щас "в процессе реализации", пока всё нравится.
Удобно, не то что в друпале.

Потестирую, возможно минусы перевесят конечно ("неуниверсальность" модулей/виджетов/шаблонов, каждый модуль/виджет реализует свой API)

Пример реализации "виртуальных" страниц, генерируемых по url - http://turistovo.ru

[Alexey]

У вас жестко задано деление страницы на 3 блока - хедер, футер и собственно сам контент. Между тем, блоков этих может быть как больше, так и меньше.

Я не говорю, что это плохо - есть очевидный плюс - простота. Но есть и очевидный минус - не универсальность. Где для вас оптимум - смотреть вам самим, т.к. достичь и простоты, и универсальности, и функциональность одновременно невозможно.

[eresik]

Сообщение от Alexey

У вас жестко задано деление страницы на 3 блока - хедер, футер и собственно сам контент.

Во-первых, это "регионы", в которые "класс страницы" передаёт массив блоков, т.е. в одном регионе можно отображать сколько угодно блоков. Ну например в левую колонку - передать массив блоков-менюшек, и будет несколько блоков-менюшек в левом регионе. Функциональность - не хуже чем в распространённых движках.
Минус - кэшируются только регионы, но не отдельные блоки (а может это и плюс, хз). Если регион найден в кэше, то get_region_... вообще не вызывается. Запрашиваются только регионы страницы не обнаруженные в кэше (и регионы, по поводу которых класс типа страницы сообщил, что их нельзя кэшировать)

Во-вторых - заранее сделать в шаблоне страницы кучу регионов (что сейчас и реализовано), и если блоков в регионе нет - регион вообще не выводится (т.е. если get_region_comments() - ничего не вернул, то регион комментариев вообще не выводится на страницу)

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

[Alexey]

Тогда жестко заданы регионы, суть дела от этого не меняется По логике то, каким образом будут расположены блоки на странице должен знать только шаблон, но не класс страницы. Классу страницы должно быть розово-фиолетово, как там все это отображается, его роль - обрабатывать запросы и возвращать данные. (см. архитектуру MVC).

[eresik]

Сообщение от Alexey

(см. архитектуру MVC)

Ну так это ж и не MVC

Сообщение от Alexey

Тогда жестко заданы регионы, суть дела от этого не меняется

Так они во всех CMS жёстко заданы

Сообщение от Alexey

По логике то, каким образом будут расположены блоки на странице должен знать только шаблон, но не класс страницы. Классу страницы должно быть розово-фиолетово, как там все это отображается, его роль - обрабатывать запросы и возвращать данные.

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

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

т.е. пример метода класса страницы, для вывода комментариев

PHP код:

class page_main extends page_base {
...
...
  function get_region_comments() {
    require_once('class_comments'); //класс реализующий работу с комментариями
    $comments=new CComments(ид страницы);
    $ret[0]['header']='Комментарии'; // 0 - порядковый номер блока в запрашиваемом регионе
    $ret[0]['content']=$comments->get_widget(); //у каждого блока могут быть заголовок и/или контент
    return $ret;
  }