Xpoint
   [напомнить пароль]

Проектирование CMF

Метки: [без меток]
2005-10-04 12:56:35 [обр] maklein[досье]

Вот взялся переписать CMF. Это мысли вслух, то бишь IMHO.

  1. Общие требования и положения.

1.1. Гибкость, маштабируемость, т.е. исключаем только проекты с уникальной функциональность, под которую проще написать с нуля.
1.2. "Многосайтовость", многоконтентность, многоязычность.
1.3. Система под себя и для коммерческого испорльзования.
1.4. PHP, MySQL, Apache

  1. Функциональные требования:

2.1. Безопасность. Сюда входят: система аунтификации, фильтрация запросов(блок перебора, блок IP и т.д.), проверка входящих данных, контроль доступа(наследование, запрет, просмотр, рекомендация для вышестоящего, полный) и др.
2.2. Дебаг: режимы работы, расширенные возможности обработки ошибок(на почту, внутр. сообщение пользователю админки, лог, блок скрипта, блок сайта, вывод в браузер), измерение скорости.
2.3. Кэширование: Возможность кэшировать страницу полностью, по модулям, по функциям/методам, SQL и т.д.
2.4. Журнал команд. Т.е. список команд, с которым может работать как админ-интерфейс, так и клиент-сервер приложение. Грубо говоря, в текущем варианте этот журнал будет служить скорее, как ссылки на управляющие структуры(см. ниже).
2.5. Редактирование сайта непосредственно, т.е. без входа в админку — увидел ошибку, исправил ошибку. Или быстрый переход на страницк админки с выделение текущей страницы[ и редактируемого фрагмента].
2.6. Система контроля действий. Аналогично истории в Photoshop'e. Можно отменить/повторить любое действие любого пользователя.
2.7. Персонализированный интерфейс для админки. В каком виде пользователь оставил меню при последнем запросе к системе, в таком оно перед ним и предстанет в следующий раз. Упорядочил фалы по размеру, так и осталось.

  1. Классификация объектов:

3.1. Управляющие структуры*(сокращенно УС). Сюда относится загрузчик, обработчик данных, полученных от пользователя, и др.
3.2. *Модули
. Сюда относятся: работа с БД, работа с файлами и т.д.
3.3. *Связывающие структуры*(или абстрактные структуры). Они выполняют примерно следующий функционал. УС нужно получить данные о странице. УС ничего не знает о способе хранения этих данных. УС обращается к соотв. связывающей структуре, и та в свою очередь связывается с БД, получает данные и передает их УС. Или, например, шаблону необходимо левое меню. Чтобы не использовать в шаблонах прямого обращения к модулям, обращение происходит через абстракцию, например, template. И, конечно, в первую очередь, сюда относится ядро(о нем позже).

  1. Возникшие проблемы:

4.1. По пункту 1.2.
Есть многоязычность — дубляж контента(а точнее текстов, подписей к картинкам) на разных языках, если нет на текущем языке, переключам на язык по умолчанию(пример: microsoft.com). Есть многоконтентность — на каждой версии сайта существует свой контент(и картинки, и файлы, и т.п.), и необязательно на разных языках, т.е., можно сказать, что это разные сайты. Есть многосайтовость — здесь еще и внутренняя структура разная, т.е. админку можно с некоторыми оговорками принять за отдельный сайт — ведь там в параметрах страниц не нужны keywords и description.Как я понимаю, в общем понимании(чуток тавтология...) многоязычность — это примерно то, что я написал, а вот многосайтовость равна моему многоконтентность. Смысл таких объединений — централизация, т.е. админка по идее только одна.
Многоязычность, как я понимаю, нужна для ТНК(транс. нац. корп.) или же для компаний, которые так или иначе связаны с фирмами из-за рубежа. Многоконтентность нужна для больших компаний, которые, например, могут сделать отдельный сайт для какого-то своего продукта или услуги. Многосайтовость же может пригодится, если эти отдельные сайты требуют очень разнообразного функционала, но приэтом все еще требуют централизированного управления.
Проблема возникает как раз с многосайтовостью. Так как функционал может быть противоположным, а централизация хотя бы в управлении необходима, возникает вопрос о делении модулей, что, как мне кажется, противоречит ужесамой идее централизации. Вопрос: где золотая середина, и может ли реально понадобиться такая возможность, т.е. какова рентабильность ее внедрения.
4.2. По пункту 2.6.
Последовательный откат команд — не проблема, но, например, следовала череда действий над пользователем, а потом его удаление. Логично было бы предположить, что нельзя исправить характеристики удаленного пользователя. Как это можно связать на уровне вывода информации о связях, я очень смутно себе представляю, а точннее вообще не представляю. Только есть попытатся изменить характеристики, а система выводит сообщения, что такого пользователя нет, и нужно искать и отменять команду с его удалением вручную.

Очень интересны мнения.

спустя 15 минут [обр] Давид Мзареулян(0/1003)[досье]

…а теперь мы со всей это […] попробуем взлететь…

Скажите пожалуйста, какая конкретная задача, тебующая такого CMF, перед Вами стоит?

спустя 1 час 56 минут [обр] Thirteensmay(0/157)[досье]
По поводу многосайтовости: На сколько я понял Вы хотите управлять сайтами с разным функционалом средствами единой админки - значит админка должна содержать все необходимые для этого инструменты, т.е. вместе с разработкой какого-либо уникального модуля разрабатывается и его админка. Далее объединяем админки в единую мегаадминку... Обоснованность сего зависит от задачи, условий и реализации...
По поводу отката: На самом деле это очень серьезная задача - живые пользователи (особенно админы) это не пиксели в Photoshop'e. В рамках мегасистемы Вы в первую очередь столкнетесь с трудностью логического анализа транзакций, ну а далее с реализацией, производительностью и т.п. Я про это забыл...
P.S. Что значит "исправить характеристики удаленного пользователя" ? Я так понимаю его предварительно надо выбрать, а как его выбрать если он уже удален ?
спустя 11 минут [обр] Дмитрий Попов(0/509)[досье]
Я вот не понимаю, какая связь у многосайтовости, кеширования, редактирования сайта непосредственно и т.д. с CMF ?
спустя 1 минуту [обр] Алексей Пешков(0/19)[досье]
  1. Реализация подобного монстра требует много времени, система морально устареет до того, как будет дописана до работоспособного состояния;
  1. Существует большое число CMS, которые реализуют подобные мега-задачи, но большой популярностью они не пользуются по разным причинам.
Единственная польза от увлечения подобными проектами — повышение личной программисткой квалификации.
спустя 28 минут [обр] Давид Мзареулян(0/1003)[досье]
Алексей Пешков[досье] Я очень не уверен, что на таких вот проектах можно повысить личную квалификацию. Потерять время — да. А квалификация, мне кажется, может повышаться только при работе над реально востребованной и работающей системой. Писать монстра, которым никто никогда не будет пользоваться — бессмысленно, потому что он никогда не будет должным образом проверен и куча ошибок и недоработок просто никогда не всплывут. Это же главное — уметь анализировать свои ошибки. А откуда о них узнаешь, если системой пользуешься только ты сам? Писать «в стол» многоэтажные логические конструкции — разве что пальцы развивать. А реальная жизнь найдёт контр-шуруп на любую систему, какой бы она ни была многоязычной, многокомпонентной и многосайтовой. И как раз при работе над реальной задачей, вопросы типа «хочу написать CMF, посоветуйте с чего начать» в принципе невозможны.
спустя 24 минуты [обр] Закиров Руслан(0/341)[досье]
Согласен, практика показывает, что разработка движимая текущими задачами идет много быстрее. Бесспорно, что такой вариант не всегд продуман в долгосрочном плане, но по завершению первого проекта вы поймете все недостатки выбраной структуры и сможете их учесть во второй итерации. Если грамотно вести TODO лист, то к окончанию первого проекта у вас будет список из 100 и более вещей, которые вы спроектировали/написали неправильно, но с которыми смогли выполнить проект, используя менее эффективные средства или заплатки. Проект сдан, садимся за рефакторинг кода и исправляем только те вещи, которые абсолютно не верны. Берем новый проект и пытаемся использовать, то что есть, там где не получается использовать перерабатываем.
спустя 15 минут [обр] maklein[досье]

Давид Мзареулян[досье] На самом деле, половина функциональных требований реализована.
Thirteensmay[досье] "Что значит "исправить характеристики удаленного пользователя" ?" — была определенная последовательность действий(создание, изменение характеристик 1, изменение характеристик 2, удаление), я писал, что нельзя отменить "изменение характеристик", если не отменить "удаление", а вот "изменение характеристик 1" не зависит от "изменение характеристик 2".
А в чем проблема отмены действий в хронологическом порядке? Есть номер команды, параметры. Все изменения проходят через единую систему, т.е., если что-то хотим изменить, то вытаскиваем еще не измененную запись, также разбираем ее на параметры и номер контр команды. Если надо изменить, реально выполням эту команду.
Дмитрий Попов[досье] Я расцениваю CMF, как набор модулей, плюс , возможно, связывающий их класс(ядро). CMS — собранная на основе этих модулей система. В данном случае я "смешал" задачи поставленные перед CMF и CMS. Главное требование к CMF, по моему мнению, это маштабируемость, т.е. возможность делать разные CMS на её основе, как я уже писал. Перед CMS же ставятся вполне конкретные задачи, которые я описал. Видимо, логичнее было бы использовать CMS вместо CMF.
Алексей Пешков[досье] Насчет времени я согласен, но повторюсь: система уже написана и поддерживает много из того, что я описал в требованиях.
Давид Мзареулян[досье] Я не "совсем" «хочу написать CMF, посоветуйте с чего начать».


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

спустя 52 минуты [обр] Eugene Efremov(0/68)[досье]
Вообще-то я тоже пишу свою CMF, и, честно говоря, не вижу в чем проблема. Если система спроектирована правильно, т.е. на основе компонентного подхода, то можно просто подобрать для каждого сайта свой набор компонент и шаблонов. Ну и небольшой врапер, который будет устанавливать include_path таким образом, чтобы компоненты с текущего сайта имели приоритет над установленными по умолчанию, и передавать управление ядру.
Powered by POEM™ Engine Copyright © 2002-2005