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, и разработана превосходная архитектура. 
Можно взять эти наработки, адаптировать их  и приступить непосредственно к кодингу. 
И пока будет кодироваться инструментальный уровень, можно будет параллельно производить анализ и проектирование непосредственно предметной части нашей задачи.