Концепции современной CMS

[_RVK_]

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

Ну XML я привел, так как считаю более удачным в том смычле что работать с ним проще встроенными средствами ПХП. Читать значения атрибутов, имена тегов и тд. Но можно использовать и шаблонизатор.

-~{}~ 23.12.04 11:58:

Основная идея, в общем то, это хранение структуры системы и автоматическая генерация на её основе интерфейса CMS(да и в целом сайта). Те программист занимается только разработкой нужных классов. В в большенстве случаев ему вообще не понадобится писать ни строчки кода, так как нужную функциональность будут обеспечивать уже базовые классы. Целая RAD получается Причем очень гибкая.

 

[Icar1]

Здраствуйте.
Не подскажите где почитать про проектирование CMS с нуля, желательно суровнем жля тех кто делал на "коленке" и не большие и хочет повысить свой уровень?

 

[_RVK_]

Icar1
Здесь. Поищи по словам CMS, Framework, MVC

 

[Ramzes]

Icar1
http://dvrodriguez.com/cmd/

 

[doran7]

Знаком с несколькими CMS, реально делал сайты на Друпале и MODX. Опыт в веб-программировании минимальный, стал детально изучать PHP столкнувшись с неприемлемыми для меня недостатками CMS.

На взгляд новичка, основные недостатки Друпала и MODX (и, наверное, других подобных CMS)/

1. Попытка сделать универсальную CMS как для программиста, так и для непрограммиста.
2. Попытка включить в ядро CMS как можно больше функционала.
3. Следствие двух первых пунктов - большая избыточности кода, медленная работа, чрезмерная нагрузка на сервер, чрезмерное количество запросов к БД и прочее, что делает сайты на такой CMS неконкурентоспособными.

Поскольку невозможно сделать универсальную и оптимальную CMS в одном флаконе, необходимо, наверное, делать CMS как минимум в трех реализациях.

1. Сборка Микро. Только для программистов. Только минимальный набор самых необходимых компонентов ядра. Все остальное может подключаться как расширения. Из обязательных компонентов админка и скрипт работы с БД (предпочтительно только для MySQL).
2. Сборка Мини. Только для программистов. Более полное ядро. Добавление системы регистрации пользователей. Все остальное подключается как расширения.
3. Сборка Универсал. Для программистов и непрограммистов. Расширенные функции ядра. Возможность работы с несколькими БД. Расширенный функционал на основе дополнительных модулей (расширений). Различные сервисы для непрограммистов.

Блочно модульный принцип построения CMS, в идеале, чтобы из сборки Микро можно было собрать и Мини и Универсал.
Ключевые установки - жесткий минимализм, недопустимость наращивания функционала в ущерб значимой потери быстродействия и/или значимого увеличения нагрузки на сервер.
Жестко ограниченный набор минимального функционала, чтобы для пользователей CMS, преследующих разные цели, в нагрузку попадало как можно меньше не нужных им функций.

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

 

[damner2]

doran7
ох, зря ты в начале не написал жирным "я не некрофил"

 

[doran7]

damner2...Эт верно... как-то я на дату не обратил внимания...

 

[HEm]

В анабиозе лежал чтоль?

 

[doran7]

Тема злободневная, имхо.

 

[BuxarNET NET]

Концепции современной СУК


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

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

2. Проектирование и разработка не с того конца (сам так ошибался), т.е. первоочередное решение таких второстепенных задач, как поддержка многоязычности, стилей, тем и т.д.

Опять же не согласен, если многоязычность и другие вещи не заложить сразу в ядро, потом придется переписывать всю систему.
Какая у нас многоязычность теперь реализована на большинстве скриптов, версии на разных языках за частую просто в разных подкаталогах хранятся или если в одном, то базы отдельные. У меня вот идея есть написать систему, где уже глубоко заложена многоязычность и в БД к примеру на один ИД новости по префиксу добавлялся ты текст - вот где глубокая интеграция которую если изначально не заложить, потом просто не сделаешь

3. Недостаточная гибкость и скудные возможности кастомизации. Зачастую действует следующая схема: страница делится на пять частей (шапка, низ, левая часть, правая часть, основная часть). Каждый модуль предоставляет ограниченное количество экшенов (например, для новостей: список новостей, страница новости, архив новостей), а так же набор блоков, которые могут быть размещены в левой или правой части страницы. Для каждого экшена существует набор настроек, позволяющий в некоторой степени управлять основной частью страницы (например, для списка новостей указать количество оных). В продвинутых системах для каждого экшена можно настроить список отображаемых в левой и правой части блоков, их порядок, применить уникальные для каждого экшена настройки. На этом кастомизация зачастую заканчивается. Даже такая банальная задача, как вывод двух одинаковых блоков с разным дизайном на одной странице порой становится реализуема только после перекапывания кода.

Это да, с этим согласен

4. Полная зависимость модулей друг от друга, когда этого не нужно, и невозможность интеграции модулей между собой там, где в этом действительно возникает необходимость.

Тоже так в основном пилят.

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