Продолжение истории про замечательную инициативу группы французских web-разработчиков под названием Diem CMS.

В этой статье вас ждут

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

Привет, ребята! С этого момента я хочу начать цикл статтей с подробностями по созданию сообственного MVC фреймворка для node.js, название которому будет — Spirit.

Первая статья будет состять из четырех частей:
1. Идея и миссия фреймворка
2. Настройка сервера
3. Создание каркаса фреймворка
4. Создание продвинутого и удобного роутера

Предупреждаю сразу, что статья — огромна, с кучей текста и большими блоками кода.

Предисловие

Столкнулся с насущной проблемой, которая автоматически становится задачей:
Как реализовать универсальный механизм перевода контента сайта, который удовлетворял бы потребности как маленьких сайтов, так и больших порталов?


Хотелось бы услышать мнение компетентных хабрапользователей, которые сталкивались с данной или подобной задачей.

Существует удобный формат для работы с векторной графикой в вебе — SVG. Если бы полная поддержка его всеми браузерами, завоевал бы он большую популярность, чем есть сейчас.

Но мы в своем фреймворке Mozart можем активно его использовать, не глядя на все проблемы совместимости. Фишка в том, что средствами фреймворка мы можем транскодировать один поток данных в другой. В случае с SVG мы трансформируем его в изображение JPEG, GIF или PNG формата, который и отдаем клиенту (браузеру).

Делаем мы это при помощи Java-based (как и сам Mozart) Batik SVG Toolkit.

Понадобилось мне в разделе Статьи одного из проектов, что использует в качестве базиса Mozart (mozartframework.ru), реализовать в конце каждой статьи ссылку на следующую и предыдущую. Нет ничего проще, дальше по большей части будет инструкция по использованию XSLT.

Итак, в своей первой статья я сделал несколько предположений об архитектуре предметной области в CMF/CMS системах. Тогда я сделал предположение об объектной модели я связанном с нею сервисе, который умел обрабатывать входящие запросы и выдавать нужный результат на основании внутренней структуры модели.

Сегодня, сейчас, я бы хотел коснуться вопроса непосредственного использования такой системы в существующем фреймворке Mozart, не так давно впущенном компанией ADV под лицензией GPLv3.

Основой API Mozart'а служат newt-контейнеры. Newt — это XML-контейнер (в XML-фрагменте), который специальным образом обрабатывается XML-парсером. Newt может быть как одиночным тэгом (закрытым тэгом <newt />), так и контейнером (содержит в себе другие контейнеры (newt'ы, инструкции)). Аналог newt'а — это функция, задачей которой является произвести какие-то действия (и вернуть результат, если требуется).

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

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

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