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

[Anozer]

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

Доброго времени суток.
Возможно оффтоп, поскольку вопрос не столько по PHP, сколько по проектированию.

Имеется задача: разработка гибкой и универсальной cms.

Начал с изучения предметной области и обнаружил, что сколько-нибудь приличных материалов на эту тему нет. Рассуждений на тему "надо использовать ООП и MVC" предостаточно; реплик о том, что "цээмэска без висивиг -- не цээмэска" и того больше.
А вот исследований/обзоров/определний предметной области практически нет. То что с натяжкой может сойти за таковые все равно в итоге скатываются к обсуждению модульности/MVC.
В то же время нигде не сказано, с чем же, собственно, работает CMS -- со страницами, с контентом, с блоками? Или, что такое страница? HTML код? нет. если страницу "о компании" сверстать дивами вместо таблиц и поменять шрифт, она все равно останется страницей "о компании". Определить страницу как дизайн + контент? уже ближе, но изменим контент -- у компании сменился гендиректор. Контент изменен, а страница все равно "о компании". Какие действия возможны с сайтом? Только просмотр? Редактирование? Что-то еще?
И таких вопросов немало. Строго говоря, их нужно уяснить, разобрат и зафиксировать не то что до написания первого байта кода, а, имхо, до создания первой диаграммы классов.

Остюда, собствено, и вопрос к уважаемому коммьюнити: сталкивался ли кто-нибудь с такой проблемой? Или же знает, кто сталкивался и написал о своем опыте? Или же, что лучше, кто знает исследования на эту тему -- а таковые должны существовать, есть же битрикс, есть xcms. Поделитесь, пожалуйста, материалами по теории построения CMS. Заранее благодарен.

 

[DiMA]

а ты кого спрашиваешь? Профессиональные программисты не пишут "материалов по теории построения ЦМС" =)

 

[Anozer]

И почему не пишут?

 

[С.]

Потому что в это время они заняты написанием самой ЦМС.

 

[zerkms]

Нет никакой теории. Каждый пишет как умеет и как хочет.

 

[Beavis]

Anozer
CMS все разные, и перед их написанием каждый программист должен сам ответить на все вопросы, которые ты привел..

 

[AmdY]

есть книга по разработке cms на php5. я её читал, весьма не плохая. но её название пусть останется нашей с гуглом маленькой тайной, потому что человек доросший до написания своей cms может сам найти её по первой же ссылке.

p.s. книга на не русском.

 

[Farsh]

тут даже не гугл, а амазон придет на помощь

 

[Духовность™]

Имеется задача: разработка гибкой и универсальной cms.

это утопия, такая же, как и коммунизм. Можно сделать CMS подходящую под Н% сайтов фирм "рога и копыта", но всегда будет другой процент заказчиков, которым не подойдет ваша "универсальная и гибкая" система (если, конечно, вы им её правильно не продадите, сумев доказать, что ЭТО именно то, что ИМ нужно).

Приведу пример. Года 3 назад я работал с сайтом http://www.foma.ru
Тогда под этот сайт был написан собственный двиг, большой такой. Писали не дураки, в принципе. Я писал модуль опросов, использовав API разработчиков.

Что сейчас с сайтом http://www.foma.ru? Он висит на битриксе и его функционал стал типичным унылым говном, состоящим из статей и типичных рюшечек от битрекса - новости, FAQ. Какой бы универсальностью не обладал бы битрикс, модуля опросов, подобных моей разработке, у них в данный момент нет. А нет ножек - нет мультиков.


CMS - это система управления контентом, а не пластилин. СУК-а не должна быть "универсальной". Универсальный должен быть программный код, что бы делать модули к этой СУК. И этот код называется фреймворк.

о что с натяжкой может сойти за таковые все равно в итоге скатываются к обсуждению модульности/MVC

Ибо попугаи ничего нового предложить не могут, а повторяют то, что было сказано до них каким-то умным дядей. На этом строится вся теоретическая база обитателей форумов русскоязычных PHP-программистов. Один сказал - все повторяют. А вся МВСшная модульность в PHP это

module.php
--------------
<?
include('config.php');

$data = $db->query('SELECT * FROM guestbook')->asArray();

include('template.html');
?>

и ВСЁ. Остальное - от избытка ума.

Нет никакой теории. Каждый пишет как умеет и как хочет.

Очень верно. Надо писать так, как умеешь, как этого требует задача. Любая ЦМС - это просто интерфейс для добавления данных и настройки frontend-части сайта. Что требует задача, то и реализовывают в интерфейсе.

 

[Lightning]

[offtop]

СУК-а не должна быть "универсальной"

Про суку повеселило
[/offtop]

 

[Anozer]

отвечаю по порядку.

AmdY, спасибо, нашел. в третьей ссылке =)

Farsh, за отсылку к амазону отдельное спсибо. Про него я что-то совсем забыл.

triumvirat

это утопия, такая же, как и коммунизм.

В самом общем и широком понятии -- да, утопия. Если не брать метацмс. Но это работа для хорошей команды программистов не на один год.

А вот в варианте "Любая ЦМС - это просто интерфейс для добавления данных и настройки frontend-части сайта" оно, имхо, вполне реализуемо. Вероятно, надо пояснить, что имеется ввиду под "гибкой СУК": гибкая СУК-- это система, предоставляющая универсальное хранилище(а) данных с удобным API к нему, и интерфейс для плагинов-модулей, позволяющий быстро и без вникания в низкоуровненвые подробности (вроде а вот тут надо бы nested set сделать, и в базу пару табличек засунуть) дописать требуемый функционал. Фактически да, это фреймворк, но фреймворк, специализированный задающий идею и стиль системы.
Исходя из вашей же цитаты, с которой я совершено согласен, СУК это совокупность средств хранения и специфической обработки данных. Специфическая обработка ставится конкретной задачей (магазин-голосование-имиджборда). Изначально ее реализовать нельзя. Ядро, позволяющее подключать это самое поведение и универсальное хранилище -- вполне. Фактически, цель такой системы -- разделить поведение и хранение данных. Таким образом конечный пользователь может конфигурировать любые части хранилища, не связанные со специфическим поведением. Например, в магазине он не может изменить поле "цена", потому что оно связано с поведением (рассчитать стоимость корзины, сгенерить платежку), но добавить поле вроде "производитель" и задать список производителей -- вполне. Понадобилось в галерее добавить категоризацию, ортогональную существующей -- пожалуйста. Понадобилось разработчику добавить в магазин регистрацию пользователей -- он работает в хранилищем пользователей, а не с базой данных.

Еще добавлю по поводу

и ВСЁ. Остальное - от избытка ума.

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

 

[Духовность™]

Anozer
У Вас есть своё мнение, не понятно - что Вы ещё хотите? Услышать вопросы на ответ "теория построения CMS"? Конкретно что-то спрашивайте, ваш вопрос абстрактен и глобален.

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

Не путайте мягкое с тёплым.

Модификация системы под "изменившуюся задачу" - это отдельное ТЗ. Когда из интернет-магазина в кротчайшие сроки нужно форум сделать, то тут ни одна супер-система не поможет.

"Чем сложнее система, тем легче ее полностью развалить" [5]. Строитель едва ли согласится расширить фундамент уже построенного 100-этажного здания. Это не просто дорого: делать такие вещи значит напрашиваться на неприятности. Но что удивительно, пользователи программных систем, не задумываясь, ставят подобные задачи перед разработчиками. Это, утверждают они, всего лишь технический вопрос для программистов.

Гради Буч, ООП

Если же речь идёт о незначительных изменениях, то чем больше сложная система, тем тяжелее её модификация:

Я помню, как-то правил проект на PHP, который сделал человек, позже ушедший в Java-разработчики.


Что бы исправить одну мелкую ошибку, надо было перескочить через четыре полупустых класса, оттуда выйти на псевдо-интерфейс, и только там увидеть функцию.


Да, я уверен, что система у автора была красивая и масштабируемая.

Только он не учел, что поддерживать её будет заранее неизвестно кто, и документации на неё нету (он не делал).


Так вот, к чему это я. К том, что в недокументированном коде, использующем сложные объектные подходы, я твердо убежден, как правило разбораться гораздо сложнее, чем в линейном простом, но при этом грамотно написанном.

Безусловно и там и там есть исключения.

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


При том, повторюсь, я уверен, что человек, писавший этот код, действительно неплохо знает проектную область. Более того, потратив две недели только на разбор кода, я таки понял идеологию, и признаю, что система масштабируема. Прьблема в том, что я потратил две недели, на проект, которым год никто не занимался. Сделал 3-часовые правки. И им еще год никто заниматься не будет. А потом опять две недели потратят вместо трех часов.

http://xpoint.ru/forums/internet/theory/thread/35663.xhtml

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


Я вовсе не отрицаю, что фитчи, описанные вами:

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

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

 

[Anozer]

К сожалению ,вета отклоняется от темы, и, боюсь, начало этому положил я. Поэтому отвечу кратко, чтобы не раздувать флейм:
1) хорошо структурированная, разбитая на уровни абстракции, и хорошо _документированная_ система не потонет в "фичах", котому что каждая "фича" заперта на своем уровне. А дока позволит довольно оперативно понять, на каком уровне надо искать.
2) если вся "заточенность под задачу" системы лежит на уровне конечного модуля-плагина, то и не придется продираться сквозь всю объетную модель. любое изменение касается только того, что к чему оно логически относится.
3) по "теории построения" я, благодаря AmdY и Farsh, получил кучу материала, которое, каюсь, упустил из виду при поиске.
4) если есть желание обсудить возможность и необходимость построения универсального фреймворка, про который я говорю, -- с удовольствием включусь в дискуссию в соотвутствующем форуме, чтобы не заморять флеймом топик, для этого не предназначенный.

 

[varan]

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

 

[Alexandre]

А вот исследований/обзоров/определний предметной области практически нет

cmslist.ru там есть и обзоры и форум

-~{}~ 12.10.09 10:25:

В то же время нигде не сказано, с чем же, собственно, работает CMS -- со страницами, с контентом, с блоками?

куча материалов и рассуждений на эту тему....

Или, что такое страница? HTML код? нет. если страницу "о компании" сверстать дивами вместо таблиц и поменять шрифт, она все равно останется страницей "о компании". Определить страницу как дизайн + контент? уже ближе, но изменим контент -- у компании сменился гендиректор. Контент изменен, а страница все равно "о компании".

как построишь архитектуру - так и будет. Возми начни с определения, что такое страница! что на ней должно выводится, откуда данная информация берется.
как данная страница будет взаимолдействовать с иными страницами.

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

поиск по форуму даст много новых идей. Каждый программист чтоб постичь Великую Карму должен:
- написать гостевую книгу
- написать ЦМС
- написать биллинг.
ты стоишь перед Первывм кругом Великого Посвящения.

Удачи!!!

 

[Anozer]

Спасибо за информацию, буду изучать.