Вот вам всем... обсирайте, не обижусь, спасибо скажу

sly 06.09.2003 21:47

Преамбула
-----------------

Система управления содержимым сайта - content management system, далее просто "система".

Разрабытывается российским свободным содружеством разработчиков на российской технологии скриптования сайтов Parser и мировым стандартом хранения инфы - БД MySQL.

=Предназначена для быстрой развертки сайтов (порталов) любой сложности и полного контроля над ними.
=Используется Parser + MySQL (в документации предполагается XML).
=Архитектура - платформенно-независима, легко обновляема и модифицируема средним юзером.
=Обладает предсказуемостью поведения в случае ошибок или ЧП.
=Строгая стандартизация.
=Документация для системы и каждего модуля свободно доступна.
=Сама система доступна по лицензии GNU/GPL.

Архитектура
-------------------

=Полное отделение кода (.p) от HTML (.html) для независимой модификации внутренней и внешней частей (по шаблонам проектирования Bridge).
=Код общается с БД, и передает файлу-шаблону (.tpl) переменные для генерации блока. Из блоков и складывается страница.

MySQL<->Parser->.tpl->.html

=Модуль - основная составляющая.
=Модуль - совокупность набора файлов, исп. свои таблицы в БД.
=Модуль может порождать неограниченное количество блоков, либо не порождать вовсе.
=Блок - видимый результат работы модуля.
=Блоки будут обладать стандартным интерфейсом (в случае портала) и своим собственным (в случае небольших представительских, не-контентных проектов).
=Модуль должен быть распакован в папку и инициализирован, после чего включается в общую систему.
=Модули основываются на API ядра - наборе методов, подключаемых автоматически в заголовке запроса.
=Наличие или отсутствие модуля не должно влиять на всю работоспособность (кроме модулей ядра).
=Для внешнего оформления блоков и страниц в целом исп. темы (скины).
=Мультиязычность обязывает выносить все статические тексты блока (в шаблоне) в отделный файл в виде переменных.
= ! Человеко-Понятные Урлы (ЧПУ) - необходимое условие развитой системы (возможно использование модуля "маскарада").

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

Структура
---------------

=Структура компонентов - древовидная, хранится в БД.
= ? Объекты (модули, блоки, файлы, пользователи) являются принадлежностью какого-либо класса объектов, могут иметь родителяи детей, наследующих их свойства.
=Типы файлов:

html страница-результат
tpl шаблон оформления
p код Parser'a
cfg файлы для хранения мелкой инфы - вроде пунктов навигации действий с модулем (tab-delimited)

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

/
|__/i/ # изображения для всего сайта
| |__/icons/ # иконки
| |__/avatars/ # аватары
|
|__/inc/ # включения с глобальными методами и переменными
| |
| |__/config/ # конфигурационные переменные
| | |__config.p # для сайта
| | |__db.p # для ДБ
| |
| |__/lang/ # язык ядра
| | |__/ru/ # буквенный код
| | |__alert.p # статические сообщения
| |__api.p # методы API ядра
| |__format.p # методы регулярных выражений оформления
| |__use.p # "сокет" для подключения классов
| |__page.p # класс работы со страницей (переадресация, обновление)
| |__dtf.p # класс работы с датами
| |__counters.p # класс для работы со счетчиками
|
|__/init/ # папка для скрипта первоначальной установки, после которой удаляется (инсталлятор)
|
|__/mods/ # корень администратора - папка для модулей
| |__/config/ # общий конфиг
| |__/docs/ # документация
| |__/mods/ # управление модулями (инициализация, настройка, удаление)
| |__/users/ # пользователи
|
|__/themes/ # темы оформления
| |__/slyStyle/ # папка и название темы
| |__/i/ # спецефические для темы изображения
| |__/styles/ # стили CSS
| |__theme.p # файл темы
| |__block_header.p # блоки,
| |__block_body.p # из которых
| |__block_left.p # строится
| |__block_footer.p # "каркас" страницы
|
|
|
|
|__.htaccess # файл с настройками сервера для работы с Parser'ом и системой
|__auto.p # глобальные данные о cms, сайте, строка подключения к ДБ, meta-инфа, класс @main[] для всех страниц

=Все настройки должны быть доступны для редактирования он-лайн через интерфейс администрирования.
=Пользователь должен как можно меньше общаться с FTP.

Юзабилити (удобство использования)
---------------------------------------------------------

=Она делится на структуру и интерфейс.
=Структурная юзабилити подразумевает максимально упрощенную и гибкую архитектуру.
=Внешняя юзабилити (интерфейсы) проектируется с учетом не только красоты, но и в большей степени удобства.

=>Никто не будет пользоваться навороченной и красивой системой, если делать это крайне неудобно. Он либо найдет решение попроще, либо будет писать сам.

Стандартизация
------------------------

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

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

Поставка
--------------

=As is. Поставите -> испортится что-нибудь (потеряете инфу)=>Мы не причем (я не я, жопа не моя).
=Денвер с ядром - полный unpack & run на машине клиента. Поставляется как опция (т.е. по надобности).
=Ядро поставляется с минимальным набором модулей, необходимых для запуска сайта.
=Остальную функциональность юзер комплектует отдельными модулями под конкретную задачу (не в пример свободным cms, тиранозаврский набор компонентов которых иногда просто ужасает. Пример - PostNuke, который с установкой тащит кучи мусора, который при малом объеме хостинга нельза толком подрезать, потому что все перемешано и связано. К тому же такие объемы сильно напрягают канал и часто просто не успевают исполняться скрипты).
=Репозитарий компонентов системы будет доступен бесплатно, лишь эксклюзивные, специфические модули, код которых не подлежит открытию по соображениям авторов, будет доступен только за плату.
=Документация будет поставляться отдельно, возможно, в виде модуля.
=В случае бесплатного распространения техническая поддержка не осуществляется. Вы можете получать инфу на сайте проекта в форуме (в случае, если вам ответят), а также читая документацию.
=Коммерческая поставка предусматривает техническую поддержку, установку компонентов и обновлений, патчи, а также эксклюзивные модули и возможности.

=>Давайте не будем решать за юзера, что ему качать и ставить. Предоставим ему выбор. Это необходимая составляющая открытого проекта.

Документ
--------------

=Спонтанные мысли в Блокноте, не претендующие на правоту и полноту.
=Это мое мнение.
=Жду критики (обсирания тоже), более точных формулировок по делу. Морально готов.
=Будет дополнятся и изменяться постоянно.
=Для версионности - дата.

---------------------------------------------------------------
Den 'sly' Markin [mail2den@mail.ru] 21:30 06.09.2003

---