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

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

Чтобы немного сориентироваться, в помощь несколько ссылок 
Определение CMS в википедии
Краткий список наиболее популярных CMS
Большой каталог существующих CMS с подробными характеристиками.

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

Это сообщение отредактировал(а) Medved - 21.2.2008, 23:52

Предлагаю для обсуждения:

1. Сущности, которыми должна оперировать CMS
1.1. База данных -- слой абстракиции, с которым будут работать все модули и остальные части ядра
1.2. Модуль -- произвольный класс/набор функций
1.3. Событие -- каждый модуль может зарегестрировать обработчик события а также порождать новые события или типы событий. 
1.4. Шаблон -- набор классов/функций отвечающих за визуальное отображение контента
1.5. Пользователь -- сюда также входит система контроля доступа. Возможно, группы пользователей (хотя как мне кажется, группы пользователей можно вынести в уже в отдельный модуль). Да и по поводу контроля доступа мучают сомнения -- возможно правильние сделать это на уровне события запроса доступа.
1.6. Форма -- вынесено сюда просто для того, чтобы ЗАСТАВИТЬ пользоваться внутренней системой форм, что позволит обрабатывать их события
1.7. Еденица контента -- произвольная еденица контента, функциональность которой определяется модулями. Вынесена сюда опять же для того, чтобы централизовано обрабатывать базовые события.

Большинство программных продуктов и сайтов строятся на трех общих слоях: слой хранения данных, слой управления (логики) и слой интерфейса с внешним миром. Для удобства разработчиков данные слои  необходимо отделять друг от друга. Это похоже на принципы программирования: необходим минимум связей между модулями (классами). Сейчас большинство сайтов не следуют этому принципу, в один скрипт собираются: доступ к данным (SQL), логика работы (валидация ввода, режимы вывода страниц) и код отображения (HTML).

Выделение основного кода PHP из кода страниц, с помощью функций или классов, не помогает дизайнеру, ему все еще приходится уметь программировать на PHP. Частично данную проблему решают шаблонизаторы, но их применение (например Smarty), для дизайнера, почти ничем не отличается от программирования: все теже операторы PHP в немного другом виде. Возможным решением проблем дизайнера является применение XSLT, но у данной технологии есть свои неудобства. Использование компонентной сборки страниц (ASP.NET) из разных элементов управления прибавляет проблем в тестировании и дизайне CSS.

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

Тезисы данного текста:
1. Удобнее разделять слои данных, логики и отображения.
2. Минимизация связей между слоями, либо точное описание возможных связей.
3. Необходимо предоставить дизайнеру удобство и легкость создания и отладки верстки отображения.
4. Сайт должен строиться на основе декларативной настройки алгоритмов.
5. Необходима возможность добавления императивных алгоритмов пользователем CMS.

EsAlexey, ты говоришь о паттерне Модель-Вид-Контроллер  (MVC, MVC для web). Это понятно. Практика хорошего стиля программирования.
Я понимаю твой энтузиазм по этому поводу. Когда я для себя открыл этот паттерн, все мои взгляды на программирование коренным образом изменились. Рекомендую почитать темы в этом разделе, так как уже многое обсуждалось, и в том числе этот вопрос. Например здесь
До сих пор затрагивались только инфраструктурные вопросы программирования. Т.е. КАК нужно программировать. 
То же самое делали и авторы предыдущих тем и топиков в данном разделе (по большей части). 
Но это вопросы второй стадии - проектирования. 

В первую же очередь необходимо определится с тем, ЧТО программировать, а не КАК. 

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

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

Общая концепция как раз-то и очерчивает круг задач которые необходимо решить.

Некотрые аспекты общей концепции обсуждаются в этих топиках 
Какие CMS уже разработаны и доступны
Админка системы (планирование и обсуждение)
CMF или подобие...

Но эти темы лишь отрывочные куски, не имеющие общего скелета. Так... тут кусочек, там кусочек...

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

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

Вот давайте вместе и подумаем об этих требованиях.

Это сообщение отредактировал(а) Medved - 22.2.2008, 23:52

Мне казалось, что планируется написание CMS. Даже верка форума так называется )

Такой функционал должен реализовываться установкой CMS + установкой модуля "блог" + установкой модуля "форум"

Каждый понимает это слово по своему. CMS - CMS рознь. CMS - понятие обширное. Общее. А нам нужна конкретика.
У нас получается примерно следующий диалог (только я слово "CMS" заменил на слово "программа"):
- Давайте писать программу!
- Да! Давайте писать программу!
- А какую программу мы будем писать? Что она будет делать?
- Ну как!? Разве эта ветка форума не называется "Давайте напишем программу?". Вот, программу и будем писать. Я предлагаю все сделать на основе MVC.
- А что это программа будет делать? Для кого она нужна? Какие задачи будет решать эта программа?
- Ну как!? Это ведь "программа"! Все ясно и понятно!


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

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

А если серьезно то...
Любая CMS состоит из фреймверка и набора модулей. Функциональность набора модулей определяется как раз модулями. Для комфорта пользователей можно сделать такие варианты получения CMS конечным пльзователем:
1. Чистая версия без единого модуля. Из функционала только админка, зайдя в ктороую можно установить модули (список автоматически получается с community сайта, при нажатии "установить" модуль скачивается и устанавливается)
2. Типовые сборки а-ля блог, новостной портал, форум 
3. Конструктор -- позволяет выбрать из списка модулей те, которые будут включены в дистрибутив.

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

http://forum.vingrad.ru/forum/topic-197699.html - вот первый этап создания общей концепции.

awers тоже немного разбирается в MSF, и знает как подступаться к делу, чтобы проект не глох и не тормозил.

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

Поздравляю!
Разработка общей концепции начата.

Первый шаг здесь: Подготовительный этап. Часть №1. « Определение потребителя » 
Второй здесь: Подготовительный этап. Часть №2. « Составление списка бизнес функций »

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

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

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

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

Чтобы написать программу, которая понравится пользователю, надо самому стать этим пользователем, влезть в его шкуру, и понять что бы мне  хотелось, будь я обычным юзером, и ничего не зная при этом об ИТ-технологиях.

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

Хорошая реализация играет второстепенную роль. 

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

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



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

Medved, фрейверк как раз нужен для подключения модулей и обеспечения взаимодействия между ними )

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

Добавлено @ 09:38
Проведу еще небольшую аналогию с автомобилем. 

Мы тут собрались конструкторы. И решили, давайте разработаем автомобиль. 

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

Даже больше я тебе скажу. По личному опыту. С таким подходом ты никогда не напишешь фреймворк. 
Да. Ты начнешь. Создашь пару классов. Может быть даже и больше. Но потом, в определенный момент встанешь... и все... так и будет твой недописанный фреймворк лежать мертвым грузом на твоем винчестере, ожидая, когда же ты удосужиться познакомить себя с объектно-ориентированным проектированием, которым мы сейчас тут и занимаемся.

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

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, там всё для жизни есть)). Общие либы почти всегда уже реализованы.

Sardar, ну тогда уже взять готовую CMS емае ... 
Зачем нам чужие монструозные решения юзать то? 

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

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

Либа для разбора и сериализации XML -> либа генерящая RSS, что берёт инфу из некоторого общего интерфейса -> скрипт, что генерит RSS новости (новые артикли за неделю) + скрипты админовки, что настраивают всё это дело. Где то на этом пути кончается "слой с общими либами" и начинается CMS.

solenko, почитай пожалуйста. Анти-паттерн.


Sardar, я тебя совсем не понял, объясни пожалуйста, что ты этим хочешь сказать.


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


Не понимаю к чему это. К общей концепции приложения пока мало относится.


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

[был флуд]


В принципе то же, что и ты - либа с функционалом (функционал в общем понятии, к примеру делать HTTP запросы на соседний сервак) может быть разная и к CMS не относится. Проектирование интерфейсов, отображающих конкретную логику (комментарий, оценка и т.п.) это уже CMS, IMHO. Отсюда не вижу смысла отказываться от Zend Framework и тем более от PEAR. Хотя фреймворки могут накладывать свои ограничения и "верные пути" на общий дизайн системы, но гарантированно всегда есть возможность полностью реализовать полёт фантазии системного архитектора 

На счёт "визуальной структуры страницы", хорошо конечно сверстать пару страниц, отсюда проще видно какой функционал нужен (вплоть до решений, генерим вёрстку на сервере или статика + JS/Ajax на клиенте + XML сервисы на сервере (удобно для админки)). Но выводить отсюда какие либо "пути"/ограничения на дизайн системы в целом (и тем более вшивание вёрстки в код) - глупо и резко бьёт по гибкости системы.

[]


Чтобы найти середину, надо знать две крайние точки.

Это сообщение отредактировал(а) Medved - 17.3.2008, 02:17

я все понял. Спасибо

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


Теперь попробуем взглянуть глазами системного архитектора.

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


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

Бизнес-логика
Этот слой инкапсулирует в себе реализацию бизнес-правил, бизнес-потоков и бизнес-сущностей, а также предоставляет интрефейсы к ним, которые потом используются в слое представления. Он состоит из следующих подслоев:
    ○ Бизнес-потоки - реализует необходимую последовательность логических действий (проще говоря последовательность шагов) в бизнес-процессах пользователя, которые автоматизируются в данном приложении.
    ○ Бизнес-компоненты - реализует бизнес-процессы, которые необходимо автоматизировать.
    ○ Бизнес-сущности - в этом слое описываются сущности, которые в дальнейшем участвуют в бизнес-процессах.
    ○ Сервисные интерфейсы - агрегирует и предоставляет необходимые интерфейсы для доступа  к объектам, которые реализуют бизнес-процессы. 

Данные
Этот слой отвечает за доступ к данным и предоставляет эти данные слою бизнес-логики, который в дальнейшем оперирует ими и предоставляет их пользователю.
Этот слой состоит из следующих подслоев:
    ○ Логика доступа к данным - выделение слоя логики доступа к данным централизует функциональные возможности доступа к данным что в дальнейшем облегчает их формирование, рефакторинг и дальнейшее сопровождение.
    ○ Сервисные агенты - данные могут предоставлять не только локальные источники, но так же и другие сторонние сервисы, для работы с ними и нужен этот слой. Так же выделение этого функционала в отдельный слой облегчает его дальнейшее сопровождение и модификацию.

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

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


Инструментальный уровень является базовым уровнем для всех остальных и включает в себя следующие программные сервисы:
    ○ Сервис кэширования;
    ○ Сервис логирования;
    ○ Сервис криптографии;
    ○ Сервис работы с БД;
    ○ Сервис конфигурации;
    ○ Сервис обработки исключений;
    ○ Сервис безопасности;
    
Тут ничего нового я не изобретал, а взял за основу архитектуру библиотеки Enterprise Library для платформы .Net.


Пока все. Продолжение еще не готово к публикации, идет его написание.
Так же можно скачать исходники того материала, который я здесь изложен.
Сам проект сделан в виде раздела MS OneNote 2007, а схемы и картинки я рисую в MS PowerPoint 2007.
Vingrad CMS.one (192 Kb)
Scheme VCMS.pptx (956 Kb)

P.S. Кто-нибудь из модераторов, пожалуйста, закрепите эту тему.

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

Попытался написать фичелист. Получилось вот что:
http://docs.google.com/View?docid=dfpchwp8_20x2k7hkfc
Дополняйте и исправляйте.


Если ты считаеш, что какое-то из моих предложений подпадает под один из антипаттернов, то укажи, плиз какое именно и под какой.
Например:


Это Ненужная сложность

Тему закрепил. 

В отношении криптографии согласен с solenko )

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

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

Я потом еще перерисую последнюю схему и добавлю сервис валидации.

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

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


Если ты сам до этого дойдёшь, будет больше пользы. 


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

Это сообщение отредактировал(а) Medved - 19.3.2008, 07:18

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

Добавлено через 7 минут и 17 секунд
По поводу системы валидации...Это же не только набор валидаторов, но и то, как эти валидаторы вызываются. 

А зачем ее портировать? Я не понимаю.


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


Нет, это разработка системной архитектуры будущей CMS, более точно - разработка инструментального уровня.

Это сообщение отредактировал(а) Medved - 19.3.2008, 11:00

Вот и я не понимаю зачем мне "сначала разбираться с нетовской EntLib"

Чтобы давать мне дельные советы и предложения.

Добавлено через 12 минут и 19 секунд
Тут хочу еще сделать одно маленькое отступление.

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

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

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

Очень рад что ты наконец-то решил прояснить ситуацию.


Поясни почему недостаточно будет их если "не спускаться". Зачем нужна дополнительная обертка для стандартных функций? Потрудись дать ответ.


Почему выбрана для копирования архитектуры .NET платформа, а не PHP? Опять же, жду аргументации, а не фразы "если спуститься до уровня кодера, то можно и php"
(да я понимаю, что архитектура слабо привязана к языку. Однако нектороые нюансы все же есть. Это всплывает уже сейчас -- сервис криптографии -- и, возможно, будет всплывать и позже. Кроме того, т.к. разработка будет вестись на php, значительно больше шансов, что кто-то из команды уже знаком с выбранной системой)

Это сообщение отредактировал(а) solenko - 19.3.2008, 15:40

solenko, я тоже часто задумывался о "портировании" некоторой идеологии .net на php. Скажу откровенно  - в этом есть смысл

Чтобы мне тебе ответить доходчиво на этот вопрос, необходимо будет написать книгу, наподобие той, что написал Гради Буч. Но раз она уже написана, просто почитай ее. Потом еще спасибо скажешь.

Medved, а не пробовал заглянуть в состав этого сомого сервиса криптографии в entlib? Что туда вынесено? md5, base64... А попробовать подумать зачем? Возможно потому, что .NET библиотеки пишутся для использования из многих языков и не во всех есть нативные функции для этих методов или звучат они по-разному? 
А теперь попробовать подумать зачем нужен этот сервис в php билиотеке, которая будет использоваться только из php?
Почитай вот эту статью. Там, к сожалению, не описано как этим пользоваться, но именно применение этого отличает программиста от человека, просто прочитавшего много книг.

Это сообщение отредактировал(а) solenko - 20.3.2008, 09:02

solenko, остынь пожалуйста.
Давай работать. Мне не нужно доказывать какой ты умный. Это покажут результаты твоего труда, а не знания, которыми ты обладаешь. Я тебе не пытаюсь доказать, что у меня голова больше твоей. Хотя к сожалению, видимо ты именно так и воспринимаешь информацию исходящую от меня. :(
Вообщем хватит мериться письками, и давай конструктив в дальнейшем. 
Самоутверждаться лучше результативным трудом, а не попытками оскорбить других. 

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

Это сообщение отредактировал(а) Medved - 20.3.2008, 09:40

Думаю интересно будет поучиться на чужом опыте 
тут
надеюсь не покажется не относящимся к нашей задаче

Это сообщение отредактировал(а) awers - 24.3.2008, 18:00

А.. Джоуля почитываешь.. респект...

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

и еще для размышления 
http://extjs.com/deploy/dev/examples/
а особенно 
http://extjs.com/deploy/dev/examples/desktop/desktop.html

Пол года назад обратил на этот прект внимание. По-моему здорово и легко поможет создать хороший интерфейс!