mozartcms

Потребовалось на проекте выводить облако тэгов. Причем, не просто независимое облако, а с учетом введенных пользователем поисковых данных.

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

В качестве основы расчета облака была взята java open source библиотечка OpenCloud (http://opencloud.mcavallo.org/).

Кладем библиотеку OpenCloud в нужное место (WEB-INF/lib).
Создаем XML файл, в котором будут все вызовы.
Создаем соответствующий контроллер.
Создаем XSL файл, который занимается форматированием вывода.

Подробности.

На форуме сайта http://www.mozartframework.ru появился пример, как скрестить стандартный API Mozart (newt:base и инструкции get-set) с контроллером, а точнее его возможностями вызова собственных функций и использования в нем EL.

Ссылка

Mozart использует исключительно библиотеку Apache Commons Logging для ведения логов. Главное преимущество использование данной библиотеки в том, что Mozart можно настроить через конфигурационные файлы на использование различных систем логирования. Например, Java Logging, Log4j, CommonsLogging или собственную реализацию.

Фреймворк Apache Commons Logging предназначен для абстрагирования разработчика от конкретного фреймворка логирования. Он предоставляет некоторый унифицированный интерфейс, транслируя его вызовы в использование конкретных возможностей фреймворков.

В статье мы рассмотрим пример настройки 2-х библиотек логирования, которые удобно использовать с Mozart: пакет java.util.logging (идет стандартно с Tomcat) и библиотека Log4J (более расширенный функционал, удобство в настройке).

Подробнее (ссылка на сайт Mozart)

Если вы используете функционал интерфейса администрирования CMS под названием "Обмен данными", то в нем как раз для экспорта/импорта используется newt:tmanager.

У редактора CMS в собственном файле db-filters.xml (это отдельное приложение, имеющее соответствующее для Mozart-приложения структуру) определены вот такие фильтры атрибутов:

Copy Source | Copy HTML
<filter-map id="htmled" extends="default">
   <attr match="//attr[@dbt='timestamp']" input-filter="str2timestamp" output-filter="timestamp2str" />
   <attr match="//attr[@dbt='text']" input-filter="dummy" output-filter="dummy" />
   <attr match="//attr[@dbt='string']" input-filter="dummy" output-filter="dummy" />
   <attr match="//attr[@dbt='int']" input-filter="dummy" output-filter="dummy" />
   <attr match="//attr[@dbt='boolean']" input-filter="dummy" output-filter="dummy" />
   <attr match="//attr[@dbt='long']" input-filter="dummy" output-filter="dummy" />
   <attr match="//attr[@dbt='shortint']" input-filter="dummy" output-filter="dummy" />
   <attr match="//attr[@dbt='float']" input-filter="dummy" output-filter="dummy" />
   <attr match="//attr[@dbt='double']" input-filter="dummy" output-filter="dummy" />
   <!-- attr match="//attr[@dbt='file']" input-filter="dummy" output-filter="dummy" / -->
 
   <attr match="//attr[@dbt='date']" input-filter="dummy" output-filter="date" />
</filter-map>

Это значит, что при использовании редактора CMS все фильтры, описанные на уровне БД (base.xml) буду обнуляться (dummy - это определение пустого фильтра ru.adv.db.filter.Dummy).

Однако эту ситуацию можно обойти. Дело в том, что редактор CMS запускается в контексте корневного приложения (т.е. основного сайта), поэтому фильтры, описанные в db-filters.xml основного сайта также используются. Если мы определим в этом файле фильтры ниже инструкции mozart-include href="htdocs:///WEB-INF/db-filters.xml", то оно переопределяет те, что имеются у приложения CMS. Пример:

Copy Source | Copy HTML
<filters>
   <?mozart-include href="htdocs:///WEB-INF/db-filters.xml" match="/root/filters/*" ?>
   ...
   <filter-map extends="htmled" id="tmanageroverride">
      <attr input-filter="fullyeardatestr-to-time" match="//attr[@dbt='timestamp']" output-filter="date"/>
   </filter-map>
</filters>

extends="htmled" указывает на то, что созданный нами filter-map является дополнение описанного ранее filter-map с id="htmled" (он как раз определяется в редакторе).

Задача получить курсы валют с сайта Центробанка, который предоставляет соответствующие интерфейсы.

Делаем вызов в каком-нибудь xml-файле:

Copy Source | Copy HTML

1. <newt:action function="util.currentDateString" var="currentDateString"/>


2. <newt:transform id="currency-from-cbrf" template="copy.xsl"


3.   expires="3d" add-query="date=${{currentDateString}}">


4.   <!-- иcпользуем внутри трансформа, чтобы кешировать на диск с курсами валют-->


5.  


6.   <newt:action function="util.getCbrCurrencies"/>


7. </newt:transform>

В первом newt:action мы определяем дату и кладем ее в специальную переменную. Далее эту переменную мы отдаем в new:transform в качестве параметра, ключа, который и будет отвечать за кэширование. Как только ключ меняется, сбрасывается кэш элемента newt:transform. Внутрь кладем newt:action, который и отвечает за получение данных с сайта cbr.ru и их обработку. Если существует кэш newt:trancform, то вложенный newt:action отрабатывать не будет, т.к. содержимое newt:transform будет браться из кэша (который по инструкции в любом случае сбрасывается раз в 3 дня).

Теперь посмотрим на контроллер, написанный на Groovy:
( подробности )

Формы редко существуют без механизма проверки данных, которые через них передаются. У newt:form есть несколько примитивных встроенных проверок: required у полей question, а также проверка на тип данных, которая реализована совместно с объектным хранилищем. Разработчику должна быть предоставлена возможность накладывать произвольные проверки на все данные под все требования бизнес-логики приложения. Рассмотрим на примере, как это реализовать. Попутно обратите внимание, что подобным методом можно не только проверять, но и модифицировать данные.

XML

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

( Read more... )

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

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

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

Поглядим пример. Недавно запустили сайт одного агентства недвижимости, на котором было необходимо показывать план этажей в продаваемых объектах недвижимости с раскрашенными квартирными блоками. Разные квартиры имели разные цвета, уже купленные квартиры никак не должны оформляться вообще. Страница, где можно увидеть пример: http://www.monarch-realty.ru/floor/81/774/154/145#content

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

Методом простых трансформаций (в Mozart это можно сделать как через XSLT, так и на уровне API через java, groovy или даже javascript) при выводе каждой картинки-схемы этажа мы сопоставляем данные по квартирам в базе данных с пустым изображением этажа, закрашивая нужны блоки. Т.е. немного преобразовываем исходный SVG. Далее этот SVG трансформируется в изображение, которое кэшируется и отдается клиенту.

Все происходит динамически, т.е. при изменении данных в БД кэш сбрасывается, изображение перерисовывается при первом обращении.

Таким вот нехитрым способом мы используем по назначению SVG, не глядя на сложности поддержки формата в некоторых браузерах и другие проблемы.

Про Mozart можно почитать тут: http://www.mozartframework.ru

UPD: хочу пояснить суть такого решения. Ниже предложили варианты использовать чистый SVG и VML, применяя решения типа raphaeljs.com.
У нас исходными данными были PDF и ничего больше. Пришлось через векторные редакторы конвертить эти данные в SVG — каждая схема полачалась как огромное кол-во векторов, так уж нарисовано все. Занималось все это несколько МБ. Трансформировать все это в разные форматы, накладывая еще и какую-то динамику через JS — мучение для клиентов.

UPD2: что касается Flash, то, конечно, можно, но читайте первый UPD и возьмите в расчет необходимость иметь для такого решения еще и флэшера…

Мы опубликовали документацию по Mozart в HTML формате. Для этого такой вид, возможно, будет удобнее. Оформление простое, чтобы максимально быстро обновлять материалы из нашей внутренней системы в случае необходимости.

http://www.mozartframework.ru/docs/html/index.html

Ссылка также доступа из раздела Документация на самом сайте.

Что делать, если требуется реализовать авторизацию на сайте с Mozart на основе данных из внешнего хранилища? Хранилищем может быть что угодно, включая текстовый файл.
Возьмем пример, что пользователей надо взять из другой БД, на которой работает другой сайт. БД даже может быть на другом сервере.

На помощь приходит SecurityFilter (что-то вроде "Using standard J2EE authorization for Web Applications with Tomcat"). Это стандартная реализация закрытых зоны в Mozart. Вот как он выглядит:

( Read more... )