В соответствии с итеративным подходом к разработке, который вкратце изложен тут, предлагаю выработать общую концепцию 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