Medved, аналогия с автомобилем, конечно, интересна, но вы зря поставили "или" а не "и". Я хочу посмотреть на конструктора который проектирует авто -- минивен, внедорожник и гоночный автомобиль в одном флаконе. А ведь именно такие требования предъявляются к CMS )

Вы сейчас еще не занимаетесь проектированием. Вы занимаетесь анализом рынка.

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

Поясню, почему я считаю что не стоит писать ТЗ для каждого модуля, который будет входить в систему как базовый. 
Да, продукт ориентирован на конечного пользователя, но нет какого-то узкого сегмента, потребности которого нужно покрыть. Насколько я понимаю, планируется не решение вроде ocCommerce или Wordpres, а система, претендующая на звание универсальной. 
Если система будет проектироваться с жесткой привязкой к конечному функционалу, то получить универсальное становится сложнее.
У меня, к сожалению, не такой уж большой опыт в работе с СMS, но я могу сказать с уверенность, что Joomla и phpNuke писались как раз с оглядкой на конечный набор модулей, а Drupal проектировался как универсальный. Если вы пробовали писать модули для этих CMS, то смогли оценить разницу -- мне уже просто неприятно работать с той же joomlа, в которой для изменения функционала модуля необходимо лезть в его исходник.

Ты сейчас говоришь опять о внутренней реализации. Опять зациклился на точке зрения кодера. 

У меня уже кнопки на клавиатуре стерлись тебе объяснять.  Пальцы дымятся. Паленной кожей смердит.

Встроенные модуля будут -  как в джомла, с жесткой привязкой к конечному функционалу, или не не встроенные-  как в Drupal, без жесткой привязки - это вопросы внутренней организации. Мы же говорим о программном продукте который будет видеть конечный пользователь. Этот конечный продукт мы сейчас и разрабатываем.
Разработав этот конечный продукт, мы уже потом будет думать, как его организовывать. Так же жестко как джомла, или так же универсально как Drupal или как нибудь иначе. Потом. На втором этапе. Проектирования. 
Сейчас главное - сама задача.  Сама идея. 

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

Это сообщение отредактировал(а) Medved - 25.2.2008, 10:34

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

Добавлено через 3 минуты и 54 секунды
Слишком много текста, и так ясно, что CMS должна удволетворять потребности наибольшего круга людей, соответственно нужно уделить внимание гибкости. То, что вы просматриваете другие сайты - мягко говоря неправильно :\ Нужно смотреть более глобально - на одном ядре с одинаковым успехом крутиться интернет-магазин и домашная страничка не сможет .Соотвенно, нужно решить, чему отдавать больше предпочтений и в спорных вопросах реализации на это опираться.

Привет, попробую сказать несколько копеек/агорот/центов/гривен... 

во первых, мне не понятна концепция Vingrad CMS. мы хотим чтобы что ?

• чтобы человек использовал винград как knowledge base ?
• чтобы человек использовал винград как blogsphere ?
• насколько мы хотим это интегрировать с системами оплаты, т.е. хотим ли мы здесь предложить ответы на вопросы за деньги ? (ИМХО хорошая идея). если да, то может встать вопрос конфиденциальности и вопрос ... обмана: 
  хотим ли мы брать комиссионные с "экспертов" за каждую трнсакцию ?
  если да, то нужна регистрирующая система, с сокрытием личных данных, иначе человек пойдет к эксперту напрямик, а не через винград. хотим ли мы предотвратить это ?

далее, независимые от предыдущих вопросы.

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

определимся с контентом.. кто он контент? 

• ветки новостей
• ветки статей
• ветки форума
• группы веток форума, т.е. подразделы/подфорумы

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

Можно даже по тегам создавать таблички, для "привычной" формы презентации данных.

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

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

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


далее, вопрос прав доступа к контенту:
какие группы пользователей будут иметь права на что ?



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

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

Я так понимаю тут опечатка... Не разработав, а спроектировав? Ну что ж, остается только подождать пока вы прийдете к каким-то конкретным идеям. Схожим или не схожим с моими, т.к. обсуждение общей концепции закончилось обсуждением в аське между двумя людьми, то, видимо, остальным светит максимум роль кодера. Так что ждем развития событий.

Множество связей между модулями может быть причиной трудно-находимых ошибок и изучение такой системы становится очень сложным. Для устранения этих проблем связи должны быть не сильными и не слабыми, а стандартными и интуитивно-понятными для пользователей и программистов. Лучше всего связи определять через базовые абстрактные понятия.

Пример на основе соединения интернет-магазина и форума:

• Объекты связей:
  • Человек (в различных ролях: покупатель, администратор, гость).
  • Каталог товаров.
  • Товар (описание и характеристики).
  • Форум.
  • Тема форума.
  • Сообщение форума.
• Связи подчинения:
  • Роль -> человек.
  • Каталог товаров -> товар.
  • Форум -> тема -> сообщение.
• Связи ссылки:
  • Товар -> тема форума.
  • Человек -> сообщение.
• Связи возможностей:
  • Товар: добавление, изменение, удаление и создание темы на форуме (для администратора).
  • Товар: просмотр, покупка (для гостя и покупателя).
  • Тема форума: создание и настройка (для администратора).
  • Тема форума: просмотр (для гостя).
  • Сообщение форума: создание и изменение (для покупателя).

При правильной классификации связей будет намного легче создавать и соединять модули. Например, для модулей блог, форум и интернет-магазин понятие "человек+роль" является общим. У каждого модуля есть набор возможностей типа добавление товара, просмотр темы форума и подобных. На основе возможностей можно создавать связи-ссылки. Ссылки будут идти на возможности модулей. В результате использования таких абстракций получится сделать понятное и удобное соединение модулей, обучиться которым будет легко как программисту, так и администратору сайта.

EsAlexey, а я бы строил немного не так:
Объекты связей:
Человек
Контент
Категория

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

Хотя возможно я не совсем правильно понял фразу 

Для добавления возможности прикрепления изображений в сообщения форума, скорее всего, придется переписывать логику работы форума. Иначе сложно интегрировать такую функцию в модуль работы с BB-code сообщений. Хотя стоит подумать как сделать логику работы форума расширяемой (наподобие плагинов).

Возможность - это как абстрактный метод интерфейса (в ООП). Она позволяет обращаться к модулям из любого места сайта (обычно гиперссылкой формата: /index.php?module=forum&command=view&param1=23894). Это пока только предположение о принципах работы CMS.

При правильном подходе модуль bb-кодов (хотя я предпочитаю html) отправляет сообщение другим можулям и получает от всех них список поддерживаемх кодов. Далее, при отображении, если встречает незнакомы код, отправляет запрос не его рендеринг и, если получает ответ, то заменят эим самым ответом.

По поводу возможностей... Да, вполне логично строить url по принципу module/action?param1=...
Но более гибкая система получится если позволить модулям вешать колбеки на конкретный url.

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

Эта информация может быть:

• Жестко структурированная (таблица, набор полей формы, дерево каталога).
• Форматированная (сообщения на форуме или в блогах).
• Неупорядоченная (все остальное).

Отображаться информация тоже может различными способами:

• HTML или XML код страницы (текст).
• Дизайн: CSS и графика (фоновые изображения, captcha).
• Файлы (все остальное).

Источниками могут быть:

• Статический текст в HTML.
• Файлы на сервере.
• Таблицы в базе данных.
• Результаты выполнения алгоритмов (результат поиска).
• Текущее состояние страницы (при ошибках ввода пользователем данных в формы).

Возможные действия:

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

Исходя из этого, получается, что информация движется:

• От источников к пользователю через ответ сервера отображением.
• От пользователя к приемникам через запросы к серверу.

А осуществляют это движение действия, которые запускаются пользователем. Некоторые действия можно сделать с помощью PHP-кода (валидаторы ввода), некоторые можно только настроить (кодирование данных от формы ввода в POST), а некоторые выполняются независимо от сайта (TCP/IP).

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

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

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

Что мы имеем.
1. 5-6 постоянных участников, имеющих навыки разработки приложений. - Ресурс разработки.
2. Форум Винград - это много-много потенциальных бета-тестеров. Не более. Ну может еще пару человек присоединятся к разработке. Будем хорошо.
3. Производственные мощности Винград (технические) - ну, это хорошо, пригодятся.

Если трезво посмотреть, то с использованием имеющихся ресурсов разработать CMS довольно сложная задача. С учетом проявленного интереса, можно сказать что и неподъемная.
Давайте немного упростим задачу, и сделаем ее более реализуемой.

Я предлагаю написать не что-то вируальное, а утолить текущую реальную потребность. Блоги. Блоги на Винград. 
Это востребованный ресурс. Текущие воплощение блогов оставляет желать лучшего (это еще мягко сказано).
И не секрет, что сфера блогов растет колоссальными темпами. Так как в общем растет число пользователей блогов, форумам до этого еще срать и срать. И вполне возможно, что форумы и не достигнут таких хороших показателей. 
Этому есть множество причин. Достаточно немного проанализировать. Давайте честно признаемся, что блоги - это будущее. Это не значит что форумы вообще исчесзнут как ББС-ки. Нет. Не исчезнут. Но по числу пользователей они никогда не догонят блоги. Даже если вам это кажется спорным утверждением, не стоит отрицать мощь и потенциал развития блогов. Кто хочет об этом поговорит подробнее, создайте отдельную тему. Я с удовольствием приму в ней участие, и обосную свою точку зрения. 

Теперь ближе к делу. 
Давайте не будем прям вот сейчас приступать к написанию полноценной CMS. А будем делать все последовательно.
ИМХО более разумный вариант - это написать скелет, косяк, основу, базис. Который в дальнейшем мы сможем наращивать, и который будет обрастать функционалом, постепенно превратиться в мощную CMS.
Написание блогов для Винград - это и будет тот костяк, та основа, на которой будет базироваться в дальнейшем CMS.

Я тут за выходные кое-что накидал, предлагаю к вашему рассмотрению.

ИТАК. 

Концептуальная схема.

В конечном итоге всю функциональность интернет-сайтов  можно свести к одной базовой функции - взаимодействие между пользователями. 


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


Входящая и Исходящая Информация по своему структурному составу однообразна. Этот структурный состав мы будем называть Контентом. Элементами контента являются Документы.


Основу Документа составляет Текст, в который вставлены различные структурные элементы, такие как Изображения, Звук, Видео, Ссылки и другие.


Документ является базовой единицей взаимодействия между пользователями.

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


Сервис - это единица функционала.  Или говоря по другому - часть программного кода, предоставляющая пользователю определенные вид услуг. Сервисы могут иметь в своем составе другие сервисы (подсервисы).

Отдельное внимание можно уделить подсервисам входящим в  сервис Бокс сообщений. Бокс сообщений - это своеобразная коллекция входящих и исходящих документов пользователя. 


Приведенная выше схема предлагается как базовая концепция будущей CMS.  Это так сказать взгляд на систему глазами пользователя. 

Это сообщение отредактировал(а) Medved - 18.3.2008, 21:54

Да, прошу меня извинить, просто огромный завал с работой. Вставать в 6, ложиться в 2 - это не так просто. Уже через пару дней появится время.

Medved, красивые катинки)


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

А зачем?

Вопрос в уровне абстракции. Это будет уровень ORM или просто библиотечка позволяющая удобно выполнять sql запросы

Имеется в виду система управления доступом? Опять же очень сильно зависит от механизма взаимодействия пользователей.

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

А вообще такое впечатление, что вы бросаетесь из крайности в крайность. Хотя я, конечно, рад, что мое предложение поддержали )
Предлагаю напсать ТЗ (нет не формальное по гостам, а просто историю пользователя) для блога. Постраюсь сделать это в субботу, но, думаю, еще несколько вариантов лишними не будут )

Medved действительно красиво рисуешь )

    ○ Сервис кэширования; - сейчас лишнее, вначале нужно отработать структуру
    ○ Сервис логирования; - да, пожалуй это важно, только Журналирование
    ○ Сервис криптографии; - md5 и base64 мало ?
    ○ Сервис работы с БД; - БД это уже сервис, скорее удобоваримый интерфейс
    ○ Сервис конфигурации; - от этого конечно не убежать
    ○ Сервис обработки исключений; - вот в этом не вижу смысла, это то чем занимается программист.
    ○ Сервис безопасности; - что это? sql injection? ddos атаки? подбор паролей?
    ○ Сервис проверки (валидации) вводимых данных; - это тоже не сервис, а набор патернов скорее, который можно хранить в конфигурации

Опять же пытаемся определить сервисы для несуществующих условий. Для определения "сервисов" необходимо выбрать средства реализации проекта и задачи. 


Что касательно визуальной структуры страницы Я думаю так:

Где есть только один основной блок - body и в нем только один основной суб-блок main. Все остальные блоки не обязательны и любой суб-блок можно привязать к любому блоку. Далее оформление и местонахождение на экране определяет шаблон и конфигурация модулей.

Рассмотрим модуль голосования (от пользователя до недр CMS) :
1) Блок отображенный на странице
2) Контролы блока (кнопка "голосовать")
3) CSS блока
4) Данные блока
5) CMS Модуль блока
6) Данные блока в БД
7) Конфигурация модуля

Вызов данных блока может проходить как по всему ядру CMS, так и по каким-то поинтам, снижая нагрузку. (это справедливо для AJAX/AJAH/AJAJ сервисов). Разбором и управлением этими запросами можно сложить на "обработчика запросов", который будет разбирать запросы типа "дайте страничку такую" или "дайте контент такой-то странички" или "дайте принт-форму такой-то страницы" или "получите POST данные для сервиса AJAJ в модуль VOTE" ... 

Набросал тут: 

Из средств реализации я предлогаю: 
php (как платформа)
PDO (как драйвер для доступа к бд)
XSLT (как шаблонизатор)
CSS (как единственное средство оформления, сим исключаем на 99% html. смотрите исходники opera.com к тому же это существенно снизит нагрузку на сервер, т.к. css очень хорошо кэшируется браузерами, шаблоны будут содержать кратно меньше данных, что повысит быстродействие шаблонизатора и снизит нагрузку на сервер)
jQuery (как рабочая часть приложения у клиента, что позволяет нам частично отказаться от "сервиса валидации")
AJAJ (как основное средство передачи данных клиент/сервер)

Я понимаю что мы выбрали БД как средство хранения информации, поэтому в принципи говорить об особенностях Oracle и постгри безсмысленно, т.к. в случае их использования "в полный рост" придется очень много переделывать (складывать всю бизнес логику туда).


Ладно, завтра продолжу.

Это сообщение отредактировал(а) awers - 16.3.2008, 04:02

Тут лучше Zend Framework взять или PEAR (+ базу MediaWiki, там всё для жизни есть)). Общие либы почти всегда уже реализованы.