Ранее (а точнее два года назад) я писал, что давно меня мучает идея создания собственного  велосипеда сайтового движка. Времени прошло много. Мыслей передумано и идей перепробовано еще больше. В итоге, кое-что в результате все же появилось. И это "кое-что" уже живет и дышит. И, кстати, делает это весьма не плохо. 

Первоначальное название (Flat CMS) пришлось сменить, т.к. как оказалось кэ-мэ-эсина с таким названием уже была когда-то написана какими-то немцами, но похоже успешно умерла, т.к. последние упоминания о ней датируются аж 2006-м годом. И с тех давних пор, похоже, она больше не развивается. Собственно и развивать-то там особо нечего - функционал там ни-ка-кой. Но речь не о ней.

А речь идет о TanitaCMS - движке, который реализует совершенно новый подход к этому самому движко-строению. По-сути это даже не CMS (Content Management System - система управления содержимым), а CMF (Content Management Framework - фреймворк для управления содержимым). Казалось бы, разница в одной букве, а суть меняется кардинально.

Чем различаются КМСы и фреймворки?

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

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

Говоря по-русски, если КМС рассчитана на обслуживание блогов (например всем известный Word Press), то не стоит пытаться собрать на ней магазин - если и получится, то сами будете не рады. А скорее всего и не получится вообще.

Другое дело - фреймворки. Эти "звери" представляют собой библиотеки кода почти на все случаи жизни. И вот на базе фреймворков можно соорудить все, что угодно, от тупого мини-сервиса, до огромного портала или социальной сети. Однако ж и тут не все идеально.

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

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

Второй недостаток фреймворков - их огромный размер и (очень часто) весьма невысокая скорость работы. Но это уже не важно.

Но вернемся к TanitaCMS.

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

И оно-таки удалось! 

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

Версии, версии, версии...

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

Что "оно" уже умеет.

Не стану описывать возможности API и особенности внутренней структуры (они могут быть интересны только разработчикам), лишь скажу, что модули к TanitaCMS делаются предельно просто и очень быстро - гораздо быстрее, чем на любом из известных мне фреймворков. Обычному же пользователю гораздо интереснее узнать, что уже умеет TanitaCMS в качестве обычной КМС. Вот не полный список уже реализованных возможностей:

• умеет создавать статичные страницы (куда ж без них?)
• автоматически генерирует многоуровневое меню
• SEO-оптимизирован (ключевые слова, описания, ЧПУ (pretty URLs) и т.д.)
• уже есть блог с возможностью премодерации комментариев, лентами рассылки по RSS и email
• система новостей и мини-каталогов
• гибкое управление дизайном на основе шаблонов с использованием шаблонизатора (smarty)
• поддержка тем оформления (каждому пользователю - своя тема, каждой странице - свой шаблон)
• встроенный WYSIWYG-редактор (TinyMCE)
• интегрированный в редактор менеджер файлов с возможностью закачки файлов на сервер
• неограниченное количество RSS-лент и списков независимых e-mail рассылок
• система отправки е-мэйлов пользователям прямо с сайта (без "засветки" адресов получаетелей)
• встроенная система редиректов, позволяющая скрывать ссылки (защита от обрезки партнерских кодов и "вытекания PR")
• навороченная система статистики (пока в разработке)
• поддержка тэгов страниц с генерацией облака тэгов
• автоматическая генерация карты сайта
• автоматическая генерация списков страниц (оглавлений) с гибкой настройкой отображаемых данных
• многопользовательская система на основе групп и прав доступа
• многосайтовая система - одна копия кода движка способна обслуживать неограниченное количество сайтов
• поддержка мульти-контентных страниц
• полноценная поддержка AJAX
• полноценная панель администрирования
• многоуровневое кэширование данных любых типов
• и многое-многое другое...   

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

Как хранить данные в БД? Этот вопрос рано или поздно встает перед любым проектировщиком сайта.

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

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

Статичная страница.

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

• Уникальный идентификатор (id) - куда ж без него?
• Идентификатор родительского элемента сайта (parent_id - мы же строим иерархическую систему)
• Заголовок (title)
• Описание (description)
• Краткое содержание (summary - используется в качестве анонса)
• Собственно текст старницы (content)
• Ключевые слова (keywords)
• Идентификатор автора (user_id)
• Дата создания (created)
• Дата последнего изменения (modified)
• Флаг опубликованности (published)
• Идентификатор логического раздела (category)

Вроде ничего не забыл....

Статья в блоге.

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

Комментарий к статье блога.

В плане хранения информации, отличия от статичной страницы минимальны. Список полей:

• Уникальный идентификатор (id)
• Идентификатор статьи с в блоге, к которой относится данный комментарий (parent_id)
• Заголовок (title)
• Собственно текст (content)
• Идентификатор автора (user_id)
• Дата создания (created)
• Флаг промодерированности (published)

Как видим, поля всё теже, что и для статичной страницы, отличие лишь в количестве.

Пост в форуме.

Полностью совпадает со статической страницей.

Ответ к посту в форуме.

Полностью совпадает с комментарием к статье блога.

Запись в новостной ленте.

Полностью совпадает со статической страницей. Лишь будет иметь одно дополнительное поле:

• Дата, начиная с которой новость уже не актуальна (expiried)

Товар в магазине.

Используются все теже поля, что и для записи в новостях, но с небольшими дополнениями:

• цена единицы товара (price)
• количество товара на складе (number)
• картинка товара, лишь для удобства - никто не запрещает ее вставить в само описание товара (image)

Итог.

Проанализировав описанное выше, можно легко сделать вывод, что при проектировании CMF логично создать всего одну (большую) универсальную таблицу в базе данных для хранения практически любого вида контента. При этом для разработчиков модулей можно упростить многие рутинные операции, такие как, программирование ввода одних и тех же данных в разных модулях (created, modified, title, decsription, keywords и т.д.). Разработчику модуля нужно лишь сообщить системе, какие именно поля будет использовать его модуль и система сама сможет создать все необходимые формы для ввода/редактирования данных, с необходимой валидацией.

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

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

Да и работать оно должно веселее, т.к. БД постоянно будет использовать одну таблицу, а значит часть ее всегда будет торчать в памяти (кэше), соответственно запросы должны выполняться гораздо быстрее...

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

Один мой знакомый как-то изрек прекрасную фразу (правда я не уверен, что именно он является автором сего изречения, скорее всего где-то вычитал), которая звучала так:

- Любая идея, она как ребенок - должна быть сначала выношена и только потом рождена.

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

Итак, хотя рабочее название у этого творения "FlatCMS", на самом деле это будет не CMS (Content Management System), а скорее CMF (Content Management Framework), ибо возможности того, что обычно зовется CMS, изначально ограничены и сами эти CMS как-правило узко-специфичны. Кроме того они очень неохотно масштабируются, да и гибкостью особой тоже не отличаются.

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

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

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

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

ЗЫ
Если есть идеи, которые хотелось бы иметь в движке, но ни в одном их (к сожалению) не реализовали, то делитесь - если мне оно приглянется, я его сделаю .