Development logger

Несколько особенностей контекстов Spring MVC или история о невнимательности

2011-08-19T12:06:00.000+04:00

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

Так получилось, что занимаясь конфигурацией (по старой привычке в основном на уровне xml) я не особо задумывался о том, как Spring MVC организует работу с контекстами, а оказалось, что это весьма интересно и понимание этой работы могло бы избавить меня от ряда нудных ошибок...

Контекст задачи

Исторически сложилось, что текущий проект целиком поднимался с разворачиванием самого обычного DispatcherServlet:

<servlet>
    <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
         <param-name>contextConfigLocation</param-name>
         <param-value>/WEB-INF/spring/*.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

Все было очень просто, все наши репозитории, компоненты, контроллеры, сервисы (@Repository, @Component, @Controller, @Service) поднимались в одном контексте. Из параметра contextConfigLocation также понятно, что каши не было и различные конфигурации были разнесены по разным файлам.

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

Реальность

При оценке задачи все казалось очень просто, но на практике получить контекст диспетчера в обычном фильтре (который не находится под управлением Spring) можно только кривым путем через копание в сессии и обладая сакральными знаниями о имени диспетчера в web.xml. Этот кривой путь был сразу отвергнут. Как самый наивный я решил просто передать фильтр под управление Spring, сделать это очень легко через предоставляемый прокси фильтр:

<filter>
    <filter-name>ExampleFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>ExampleFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

Что будет происходить за кулисами при разворачивании этого фильтра? Благодаря такому проксированию наш реальный фильтр будет находится прод управлением Spring, только теперь наш настоящий фильтр должен подниматься в контексте Spring, что я и сделал указав в фильтре аннотацию @Component("ExampleFilter"), собственно по имени компонента произойдет состыковка DelegatingFilterProxy с нашим реальным фильтром:

...
@Component("ExampleFilter")
public class ExampleFilter implements Filter {
...

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

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

Решение

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

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/spring/root/*.xml</param-value>
</context-param>
 
<filter>
    <filter-name>ExampleFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>ExampleFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
 
<servlet>
    <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
         <param-name>contextConfigLocation</param-name>
         <param-value>/WEB-INF/spring/dispatcher/*.xml</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
 
<servlet-mapping>
    <servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

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

<!-- In ROOT context -->
<context:component-scan base-package="your.package.mvc" >
     <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>
...
<!-- In dispatcher context -->
<context:component-scan base-package="your.package.mvc" >
     <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

После таких манипуляций получится следующее:

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

Необходимо так же помнить, что существует еще инструкция <mvc:annotation-driven/>, про которую не стоит забывать.

Тонкости решения

В описанной истории опустилось, что в проекте так же использовался фреймворк Hibernate, с которым тоже произошел сюрприз...

Каково же было мое удивление, когда после все моих изменений и попытки обратиться к своему контроллеру я получил следующее исключение: org.hibernate.HibernateException: No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here at... Думаю любой разработчик рано или поздно сталкивался таким исключением

Понятно, что дело оказалось в том, что по каким-то причинам перестала открываться транзакция в цепочке контроллер-репозиторий. В данном конкретном проекте управление транзакциями было организованно классически: DataSource-SessionFactory-TransactionManager. И с помощью милой инструкции <tx:annotation-driven mode="proxy" /> управление транзакциями происходило с помощью аннотации @Transactional.

Оказалось, что данная инструкция ограничивается одним контекстом (!!!). Это достаточно странно, так как контекст диспетчера является дочерним. Собственно, поэтому если вы хотите использовать аннотацию @Transactional и в контроллерах и в компонентах, то данную инструкцию придется дублировать в обоих контекстах.

Заключение

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

Ретроспектива: СSS меню в IE6 без использования JavaScript

2010-12-01T19:18:00.001+03:00

Как обычно - случилось, пришлось вспоминать использование различных шаманских бубнов для пожилого и по старчески вредного браузера Internet Explorer 6. И как обычно - вспомнилось, в отдаленных участках моего сознания все же были аккуратно сложены воспоминания о былых противостояниях молодых сознанием и уже не молодого браузера...

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

Решения

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

<ul class="menu">
    <li>
        <a href="#" title="Main">Main</a>
        <ul>
            <li><a href="#" title="Services">Services</a></li>
            <li><a href="#" title="Products">Products</a></li>
            <li><a href="#" title="Job">Job</a></li>
        </ul>
    </li>
    <li>
        <a href="#" title="Portfolio">Portfolio</a>
        <ul>
            <li><a href="#" title="Projects">Projects</a></li>
            <li><a href="#" title="Styles">Styles</a></li>
            <li><a href="#" title="Private clients">Private clients</a></li>
        </ul>
    </li>
    <li>
        <a href="#" title="FAQ">FAQ</a>
        <ul>
            <li><a href="#" title="Q&A">Q&A</a></li>
            <li><a href="#" title="Wiki">Wiki</a></li>
        </ul>
    </li>
</ul>

И сотворим примерное работающее меню с помощью CSS:

a {
    color:#555;
}
a:hover {
    color:#000;
}
.menu {
    list-style:none;
    margin:0;
    padding:0;
}
.menu li {
    position:relative;
    float:left;
    margin:0;
    padding:0.2em 1em;
}
.menu li:hover {
    background:#CCC;
}
.menu ul {
    display:none;
    position:absolute;
    left:0;
    top:1.5em;
    list-style:none;
    margin:0;
    padding:0;
    background:#EEE;
}
.menu ul li{
    float:none;
}
.menu li:hover ul{
    display:block;
}

Решение стандартное и опять таки в тех или иных вариациях используется часто, но оно не работает в IE6... А справляются с этим следующим образом:

Первое решение:

Идея состоит в том, что для всех современных брайзеров будут обрабатываться hover события для li элементов, что является естественным решением, а для IE6 будет привязываться специальный обработчик, который будет менять классы у li элементов. Таким образом в CSS придется одинаково описывать стиль представления для события наведение (:hover) и для класса с аналогичным названием (.hover).

В этом случае верстка не изменяется, но расширяется СSS:

.menu li:hover,
.menu li.hover{
background:#CCC;
}
.menu li:hover ul,
.menu li.hover ul,{
display:block;
}

И добавляется js-обработчик. А следовательно, и само решение становиться зависимым от JavaScript:

menuEventer = function() {
      if (document.all && document.getElementsByTagName) {
            var elements = document.getElementsByTagName("LI");
            for (var i=0; i < elements.length; i++) {
                elements[i].onmouseover=function() {
                      this.className+=" hover";
                }
                elements[i].onmouseout=function() {
                      this.className=this.className.replace(" hover", "");
                }
            }
      }
}
window.onload = menuEventer;

Такой не сложный обработчик заставляет работать меню, но такое решение, найденное в свое время Патриком Гриффитс и Даном Уэбб, нельзя назвать красивым...

Второе решение:

Второе решение частично вытекает из первого и связно с тем, что возможно избавиться от ручного расширения css и добавления js-обработчиков, но по сути оно является аналогичным. Основывается оно на использование скриптов поведения подключаемых через css-свойство behavior. Найти подобный скрипт не сложно, а разработчику достаточно только включить новое правило в css:

body {
behavior: url("csshover3.htc");
}

Такое решение так же заставляет IE6 работать и является куда более элегантным, однако зависимость от JavaScript по-прежнему осталась...

Третье решение:

Третье решение основано на специфическом изменении верстки, которое позволило бы использовать hover для элемента a. При этом ясно, что зависимость от JavaScript уйдет и может получиться интересное решение.

Идея верстки состоит в том, чтобы вложить в элемент a все подменю (элемент ul) с его ссылками:

<ul class="menu">
    <li>
        <a href="#" title="Main">Main
            <ul>
                <li><a href="#" title="Services">Services</a></li>
                <li><a href="#" title="Products">Products</a></li>
                <li><a href="#" title="Job">Job</a></li>
            </ul>
        </a>
    </li>
    <li>
        <a href="#" title="Portfolio">Portfolio
            <ul>
                <li><a href="#" title="Projects">Projects</a></li>
                <li><a href="#" title="Styles">Styles</a></li>
                <li><a href="#" title="Private clients">Private clients</a></li>
            </ul>
        </a>
    </li>
    <li>
        <a href="#" title="FAQ">FAQ
            <ul>
                <li><a href="#" title="Q&A">Q&A</a></li>
                <li><a href="#" title="Wiki">Wiki</a></li>
            </ul>
        </a>
    </li>
</ul>

В таком случае изменив CSS следующим образом можно было бы ожидать нормальное решение:

a {
    color:#555;
}
a:hover {
    color:#000;
}
.menu {
    list-style:none;
    margin:0;
    padding:0;
}
.menu li {
    float:left;
    margin:0;
}
.menu a {
    display:block;
    position:relative;
    padding:0.2em 1em;
}
.menu a:hover {
    background:#CCC;
}
.menu a ul {
    display:none;
    position:absolute;
    left:0;
    top:1.5em;
    list-style:none;
    margin:0;
    padding:0;
    background:#EEE;
}
.menu a ul li{
    display:block;
    float:none;
}
.menu a:hover ul {
    display:block;
}

Это решение во-первых, является не валидным решением, а во-вторых, ни один современный браузер подобного сделать не даст и будет исправлять верстку до первоначального варианта. Однако с некоторыми проблемами IE6 это проглотит, правда может вылетать через некоторое время после активного пользования "таким" меню.

Обойти такую проблему можно еще более страшным изменением верстки, вложить все вложенное меню в таблицу, а уже таблицу вложить в ссылку первого уровня (^_^ знаю, pepelsbey на меня нет):

<ul class="menu">
    <li>
        <a href="#" title="Main">Main
            <table><tr><td>
                <ul>
                    <li><a href="#" title="Services">Services</a></li>
                    <li><a href="#" title="Products">Products</a></li>
                    <li><a href="#" title="Job">Job</a></li>
                </ul>
            </td></tr></table>
        </a>
    </li>
    <li>
        <a href="#" title="Portfolio">Portfolio
            <table><tr><td>
                <ul>
                    <li><a href="#" title="Projects">Projects</a></li>
                    <li><a href="#" title="Styles">Styles</a></li>
                    <li><a href="#" title="Private clients">Private clients</a></li>
                </ul>
            </td></tr></table>
        </a>
    </li>
    <li>
        <a href="#" title="FAQ">FAQ
            <table><tr><td>
                <ul>
                    <li><a href="#" title="Q&A">Q&A</a></li>
                    <li><a href="#" title="Wiki">Wiki</a></li>
                </ul>
            </td></tr></table>
        </a>
    </li>
</ul>

А CSS подправив следующим образом:

a {
    color:#555;
}
a:hover {
    color:#000;
}
.menu {
    list-style:none;
    margin:0;
    padding:0;
}
.menu li {
    float:left;
    margin:0;
    height:1%;
    position:relative;
}
.menu a {
    display:block;
    padding:0.2em 1em;
}
.menu a:hover {
    background:#CCC;
}
.menu a table {
    display:none;
    position:absolute;
    left:0;
    top:1.5em;
}
.menu a table ul {
    list-style:none;
    margin:0;
    padding:0;
}
.menu a ul li{
    float:none;
    display:block;
    margin:0;
    padding:0;
}
.menu a:hover table {
    display:block;
    background:#EEE;
}

Однако в результате получается, что такое "специфическое" решение нормальные браузеры и IE6 понимают и обрабатывают, а вот более IE7 и выше уже не понимают...

Последнее решение:

Идея этого решения, собственно на котором я и остановился, состоит в объединении естественного решения для нормальных браузеров и специфического решения для IE6. Такое объединение позволяет организовать механизм условных комментариев (conditional comments), поддерживаемый в браузерах Internet Explorer.

Изменяем верстку с использованием условных комментариев:

<ul class="menu">
    <li>
        <a href="#" title="Main">Main
        </a>
        
        <ul>
            <li><a href="#" title="Services">Services</a></li>
            <li><a href="#" title="Products">Products</a></li>
            <li><a href="#" title="Job">Job</a></li>
        </ul>
        
    </li>
    <li>
        <a href="#" title="Portfolio">Portfolio
        </a>
        
        <ul>
            <li><a href="#" title="Projects">Projects</a></li>
            <li><a href="#" title="Styles">Styles</a></li>
            <li><a href="#" title="Private clients">Private clients</a></li>
        </ul>
        
    </li>
    <li>
        <a href="#" title="FAQ">FAQ
        </a>
        
        <ul>
            <li><a href="#" title="Q&A">Q&A</a></li>
            <li><a href="#" title="Wiki">Wiki</a></li>
        </ul>
        
    </li>
</ul>

Для современных браузеров оставляем изначальную верстку, а для IE6 переопределяем правила:

.menu li {
    position: relative;
    padding:0;
    height:1%;
}
.menu li a {
    display:block;
    padding:0.2em 1em;
}
.menu li a:hover {
    background:#CCC;
}
.menu a ul {
    background:none;
}
.menu a ul li{
    display:inline;
}
.menu a:hover ul {
    display:block;
    background:#EEE;
}

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

Таким образов, получаем кроссбраузерное решение, которое можно значительно усложнить, что продемонстрировал Stu Nicholls.

Конец ретроспективе, возвращаемся в будущее! ^_^

Смешиваем, но не взбалтываем: Apache Tiles & Spring MVC

2010-11-25T14:31:00.001+03:00

По совершенно обычному стечению обстоятельств наткнулся на весьма легкий проект - Apache Tiles, оказавшийся весьма популярным. Это простой и со своей второй версии весьма гибкий шаблонизатор пришедший из Struts. Собственно, мне не приходилось с ним сталкивался, тем более не слышал о том что в Spring уже есть поддержка этого легковесного шаблонизатора с совершенно незамысловатым устройством.

Что же это за шаблонизатор и с чем его готовить?
Так вот ничего революционного этот проект собой не представляет, но как оказалось он весьма удобен. Концепция проста - зачем работать с различного рода "обвесами" на странице (headers, footers, sidebars), если в действительности в контексте логики приложения нас интересует только конкретный динамический блок (при этом, совершенно необязательно, что "обвесы" являются статическими блоками). Таким образом, основная выгода - это разделение логики представления по нескольким уровням (да, это тривиально).

Что дает такое простое разбиение:

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

Очень простая вещь, которая в совокупности с некоторыми дополнительными удобствами становиться настолько естественной, что лично у меня возник вопрос: "Почему я раньше не слышал о таком простом фреймворке?"

По полочкам...

Каким же образом использовать этот инструмент? Все достаточно просто, необходимо сделать следующее:

Сконфигурировать Tiles в контексте Spring контейнера. Spring уже включает поддержку Tiles, поэтому для этого достаточно лишь создать Configurer и соответствующий ViewResolver:

<bean id="tilesConfigurer" class="org.springframework.web.servlet.view.tiles2.TilesConfigurer">
    <property name="definitions" value="/WEB-INF/tiles/tiles-templates.xml" />
    <property name="preparerFactoryClass" value="org.springframework.web.servlet.view.tiles2.SpringBeanPreparerFactory"/>
</bean>

<bean id="viewResolver" class="org.springframework.web.servlet.view.tiles2.TilesViewResolver">
    <property name="viewClass" value="org.springframework.web.servlet.view.tiles2.TilesView"/>
</bean>
Создать tiles-конфигурацию ("/WEB-INF/tiles/tiles-templates.xml" из spring-конфига), в которой описываются шаблоный, отдельные элементы шаблона.
Реализовать представление для описанных шаблонов

Как правило после этого (с учетом, что будет готов уровень контроллера) уже можно будет посмотреть на результат.

Начинаем разработку

Прежде чем перейти к конфигурации Spring и Tiles в качестве примера определим структуру шаблона. В качестве примера возьмем следующую структуру:

Исходя из такой структуры можно заметить, что фактическая работа приложения сводиться к работе блоком CONTENT, все остальное либо не связанно с контентом, либо является статическими блоками (конечно, бывают исключения ^_^).

Конфигурируем Spring

В конфигурации Spring MVC ничего особенного нет, кроме выше изложенного ничего специфического не добавляем.
/WEB-INF/web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

    <servlet>
        <servlet-name>dispatcher</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <init-param>
                  <param-name>contextConfigLocation</param-name>
                  <param-value>
                     /WEB-INF/spring/*.xml
                  </param-value>
        </init-param>
        <load-on-startup>0</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>dispatcher</servlet-name>
        <url-pattern>*.page</url-pattern>
    </servlet-mapping>

    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>
    <welcome-file-list>
        <welcome-file>index.page</welcome-file>
    </welcome-file-list>

</web-app>

И /WEB-INF/spring/mvc-config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
            http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
            http://www.springframework.org/schema/context
            http://www.springframework.org/schema/context/spring-context-3.0.xsd">

    
    <context:component-scan base-package="ru.sultry.controllers">
        <context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
    </context:component-scan>

    
    <bean id="tilesConfigurer" class="org.springframework.web.servlet.view.tiles2.TilesConfigurer">
        <property name="definitions" value="/WEB-INF/tiles/tiles-templates.xml" />
        <property name="preparerFactoryClass" value="org.springframework.web.servlet.view.tiles2.SpringBeanPreparerFactory"/>
    </bean>

    <bean id="viewResolver" class="org.springframework.web.servlet.view.tiles2.TilesViewResolver">
        <property name="requestContextAttribute" value="requestContext"/>
        <property name="viewClass" value="org.springframework.web.servlet.view.tiles2.TilesView"/>
    </bean>

</beans>

Более тут добавить нечего, кроме того, что необходимо реализовать контроллер для нашего примера. Нужно заметить, что ничего принципиально не меняется и здесь, кроме того, что нас больше не интересуют данные для любых других блоков шаблона, кроме контентного:

package ru.sultry.controllers;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.servlet.ModelAndView;

/**
* @author tsarev.oi@mail.ru
*         User: Oleg Tsarev
*         Date: 10.11.2010
*         Time: 14:17:42
*
*/
@Controller
public class MainController {

    public static final String INDEX_PAGE = "/index.page";
    public static final String INDEX_VIEW = "main";

    public static final String INFO_PAGE = "/info.page";
    public static final String INFO_VIEW = "info";

    @RequestMapping(value=INDEX_PAGE)
     public ModelAndView index(Model model) {

        model.addAttribute("message", "Message from main controller to main page!");

        return new ModelAndView(INDEX_VIEW);
    }

    @RequestMapping(value=INFO_PAGE)
     public ModelAndView info(Model model) {

        model.addAttribute("message", "Message from main controller to info page!");

        return new ModelAndView(INFO_VIEW);
    }

}

Конфигурируем Tiles

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

Все элементы конфигурации - definitions являются дочерними к корневому элементу tiles-definitions:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE tiles-definitions PUBLIC
"-//Apache Software Foundation//DTD Tiles Configuration 2.1//EN"
"http://tiles.apache.org/dtds/tiles-config_2_1.dtd">

<tiles-definitions>

</tiles-definitions>

Приступим к объявлению нового шаблона под выбранную выше структуру. На данном этапе предположим, что все блоки шаблона кроме контентного будут статическими:

<definition name="base-template" template="/WEB-INF/templates/base-template.jsp">
    <put-attribute name="title" value="Default title" />
    <put-attribute name="header" value="/WEB-INF/templates/header.jsp" />
    <put-attribute name="navigation" value="/WEB-INF/templates/navigation.jsp" />
    <put-attribute name="content" value="" />
    <put-attribute name="footer" value="/WEB-INF/templates/footer.jsp" />
</definition>

В данном объявлении шаблон под именем base-template связывается с представлением, расположенным в "/WEB-INF/templates/base-template.jsp". Кроме этого, в качестве атрибутов предаются ссылки на статические элементы - header, navigation, content, footer, а также строковый атрибут со значением заголовка по умолчанию. К реализации представления и применению в шаблоне внедренных атрибутов мы перейдем позже, а сейчас необходимо отметить следующее - при попытке обращения к шаблону из контроллера (при обращении к представлению base-template) получим (должны получить, так как представление еще не реализовано) страницу с заголовком по умолчанию, заполненными блоками header, footer, navigation, но с отсутствующим контентным блоком.

Приступим к наследованию этого шаблона для конкретных страниц, обрабатываемых нашим контроллером:

<definition name="main" extends="base-template">
    <put-attribute name="title" value="View: main" />
    <put-attribute name="content" value="/WEB-INF/templates/layouts/main.jsp" />
</definition>

<definition name="info" extends="base-template">
    <put-attribute name="title" value="View: info" />
    <put-attribute name="content" value="/WEB-INF/templates/layouts/info.jsp" />
</definition>

Объявлять представление для каждой новой страницы? Необязательно, в определениях tiles можно использовать регулярные выражения (причем допустимы два синтаксиса), поэтому предыдущее объявление можно заменить на следующее:

<definition name="*" extends="base-template">
<put-attribute name="title" value="View: {1}" />
<put-attribute name="content" value="/WEB-INF/templates/layouts/{1}.jsp" />
</definition>

У подобного объявления есть недостатки, при обращении к несуществующей странице в браузер будет выкинуто сообщение об исключении при поиске соответствующего файла для контентного блока. Но эта ситуация обходится несколькими способами, кроме того никто не мешает переопределить поведение Tiles в этом случае, так как доступны исходники. ^_^

Реализуем представление

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

/WEB-INF/templates/base-template.jsp:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="tiles" uri="http://tiles.apache.org/tags-tiles" %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>
            <tiles:getAsString name="title" />
        </title>
        <link rel="stylesheet" href="/css/style.css" type="text/css"/>
    </head>
    <body>

        <tiles:insertAttribute name="header" />
        <tiles:insertAttribute name="navigation" />
        <tiles:insertAttribute name="content" />
        <tiles:insertAttribute name="footer" />

    </body>
</html>

/WEB-INF/templates/header.jsp:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<div id="header">Header</div>

/WEB-INF/templates/navigation.jsp:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<div id="navigation">
    <ul>
        <li>
            <a href="/index.page" title="Main page">Main page</a>
        </li>
        <li>
            <a href="/info.page" title="Information page">Information page</a>
        </li>
    </ul>
</div>

/WEB-INF/templates/footer.jsp:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<div id="footer">Footer</div>

Представления для самого шаблона реализованы, в base-template.jsp происходит вызов вложенных представлений по ссылкам, которые уже были переданы через атрибуты.

Теперь необходимо реализовать представление конкретных страниц, обрабатываемых контроллером.
/WEB-INF/templates/layouts/main.jsp и /WEB-INF/templates/layouts/info.jsp:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<div id="content">
    <c:if test="${message != null}">
        <c:out value="${message}"/>
    </c:if>
</div>

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

Независимые динамические блоки

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

Предобработчики должны расширять класс ViewPreparerSupport, предоставляемый Tiles. Так как других требований нет, то этот предобработчик может диспетчезироваться из Spring как обычный контроллер, что позволяет использовать автоприсвоение (autowiring) и т.д. и т.п.

В качестве примера динамического блока возьмем статический на данный момент блок заголовка. НО начнем с написания контроллера:

package ru.sultry.controllers;

import org.apache.tiles.AttributeContext;
import org.apache.tiles.context.TilesRequestContext;
import org.apache.tiles.preparer.ViewPreparerSupport;
import org.springframework.context.annotation.Scope;
import org.springframework.stereotype.Controller;

/**
* @author tsarev.oi@mail.ru
*         User: Oleg Tsarev
*         Date: 10.11.2010
*         Time: 15:06:25
*
*/
@Controller("headerController")
@Scope("session")
public class HeaderController extends ViewPreparerSupport{

    @Override
    public void execute(TilesRequestContext tilesContext,
                        AttributeContext attributeContext) {

        // Get access to model parameters from MainController as example
        String message = (String) tilesContext.getRequestScope().get("message");

        tilesContext.getRequestScope().put("headerMessage", "Message from header!");

    }

}

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

Теперь необходимо изменить представление блока заголовка и связать definition с конкретным предобработчиком. Представление измениться следующим образом:

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<div id="header">
    Header<br/>
    <c:if test="${headerMessage != null}">
        <c:out value="${headerMessage}"/>
    </c:if>
</div>

А для того, чтобы связать заголовок с предобработчиком придется изменить и описание шаблона:

<definition name="base-template" template="/WEB-INF/templates/base-template.jsp">
    <put-attribute name="title" value="Default title" />
    <put-attribute name="header" value="header" />
    <put-attribute name="navigation" value="/WEB-INF/templates/navigation.jsp" />
    <put-attribute name="content" value="" />
    <put-attribute name="footer" value="/WEB-INF/templates/footer.jsp" />
</definition>

<definition name="header"
                 preparer="headerController"
                 template="/WEB-INF/templates/header.jsp">
</definition>

Вот и все, теперь контроллер будет передавать собственное сообщение в представление.

Важно обратить внимание, что предобработчики отрабатывают после основного конроллера, поэтому при неосторожности можно переопределить те данные которые вернул главный контроллер.

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

Пишем Compressing Filter для js и css ресурсов

2010-11-13T19:47:00.001+03:00

Задумавшись об оптимизации своих web приложений через n-ое количество времени я заинтересовался различного рода сжатием статики, о котором написано невероятно много интересных и занимательных статей. Более всего меня заинтересовало сжатие css и js. Заинтересованность эта была связана с тем, что сам разработчик правит js и css достаточно часто и постоянное ручное сжатие рано или поздно приводит либо к пересмотру всего процесса разработки и размещения, либо приводит к отказу от сжатия.

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

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

В качестве достоинств такого подхода можно выделить следующее:

Разработчик не тратит свое время на сжатие
Не нужен специальный механизм размещения
Для подключения сжатия к проекту будет достаточно подключить фильтр

Но у любого решения есть свои недостатки:

Статика отдается сервером приложения, а не оберткой в виде, например, nginx.
При простой реализации сжатия через фильтр повторное обращение к css или js будет приводить к повторному сжатию, что будет только загружать сервер приложения.
Любая модификация отдаваемого контента через фильтра потенциально может привести к тому, что контент из-за некоторых сбоев в обработке может не дойти до конечного пользователя.

Исходя из этих особенностей можно выделить ряд ключевых моментов для сжимающего фильтра:

Необходима проверка на соответсвие отдаваемого контента формату css или js . Это необходимо в том случае если пользователь повесит фильтр не только на js и css .
При любой ошибке или даже намеке на то, что она может произойти необходимо отменить все модификации и просто пропустить несжатый контент.
Чтобы избавиться от лишней нагрузки на сервер приложений необходимо реализовать кэширование с возможностью сброса или обхода.
Так как фильтр может работать в цепочке фильтров необходимо предоставить response wrappers для того чтобы избежать работу нескольких фильтров с одним ответом (что будет вызывать исключение)

Инструментарий и интерфейс фильтра

В качестве компрессора я выбрал YUICompressor , ознакомиться с которым можно здесь: http://developer.yahoo.com/yui/compressor/. Конечно, можно выбрать и другой компрессор, но тогда придется реализовать другой интерфейс к вашему компрессору.

Итак, нам необходимо скачать jar файл и поместить его в недры classpath, чтобы был доступ к следующим классам: com.yahoo.platform.yui.compressor.CssCompressor и com.yahoo.platform.yui.compressor.JavaScriptCompressor.

YUICompressor имеет не так много параметров, поэтому их легко можно перенести в конфигурацию самого фильтра. Более того не все параметры реально нужны для функционирования фильтра, поэтому вполне логично оставить следующие:

line-break - перенос по строкам сжатого контента
nomunge - минимизация без обфускации
preserve-semi - сохранять ли необязательные ";"
disable-optimizations - выключение микро-оптимизаций

Конечно, вероятно понадобиться настройка кодировки, но я предпочел зафиксировать ее со значением UTF-8. Реализовать настройку кодировки ничего не стоит, можно будет легко это сделать.

Собственно, интерфейс определен, что позволяет определить и подключение фильтра:

<filter>
        <filter-name>CompressingFilter</filter-name>
        <filter-class>com.sultry.web.filters.CompressingFilter</filter-class>
        <init-param>
                <param-name>lineBreak</param-name>
                <param-value>8000</param-value>
        </init-param>
        <init-param>
                <param-name>noMunge</param-name>
                <param-value>false</param-value>
        </init-param>
        <init-param>
                <param-name>preserveSemi</param-name>
                <param-value>false</param-value>
        </init-param>
        <init-param>
                <param-name>disableOptimizations</param-name>
                <param-value>false</param-value>
        </init-param>
</filter>

<filter-mapping>
        <filter-name>CompressingFilter</filter-name>
        <url-pattern>*.css</url-pattern>
</filter-mapping>
<filter-mapping>
        <filter-name>CompressingFilter</filter-name>
        <url-pattern>*.js</url-pattern>
</filter-mapping>

или с помощью аннотаций в самом коде

@WebFilter(filterName = "CompressingFilter",
                     initParams = {
                           @WebInitParam(name = "lineBreak", value="8000"),
                           @WebInitParam(name = "noMunge", value="false"),
                           @WebInitParam(name = "preserveSemi", value="false"),
                           @WebInitParam(name = "disableOptimizations", value="false"),
                     },
                     urlPatterns = {"*.css", "*.js"})

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

package com.sultry.web.filters;

@WebFilter(filterName = "CompressingFilter",
                     initParams = {
                           @WebInitParam(name = "lineBreak", value="8000"),
                           @WebInitParam(name = "noMunge", value="false"),
                           @WebInitParam(name = "preserveSemi", value="false"),
                           @WebInitParam(name = "disableOptimizations", value="false"),
                     },
                     urlPatterns = {"*.css", "*.js"})
public class CompressingFilter implements Filter {

    private static final String LINE_PARAM = "lineBreak";
    private static final String MUNGE_PARAM = "noMunge";
    private static final String PRESERVE_PARAM = "preserveSemi";
    private static final String OPT_PARAM = "disableOptimizations";

    private static final String CHARSET = "UTF-8";

//Filter implementation

}

Инициализация фильтра

Первое с чего необходимо начать непосредственную реализацию - это инициализация фильтра. Что необходимо сделать во время инициализации:

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

Ничего особенно в такой инициализации нет, поэтому достаточно быстро можно прийти к такому или аналогичному коду:

    @Override
    public void init(FilterConfig config) throws ServletException {
        this.config = config;
        String lineBreakParam = normalize(this.config.getInitParameter(LINE_PARAM));
        String noMungeParam = normalize(this.config.getInitParameter(MUNGE_PARAM));
        String preserveSemiParam = normalize(this.config.getInitParameter(PRESERVE_PARAM));
        String disableOptimizationsParam = normalize(this.config.getInitParameter(OPT_PARAM));

        this.lineBreak = isNumber(lineBreakParam) ? Integer.parseInt(lineBreakParam) : this.lineBreak;
        this.noMunge = isBoolean(noMungeParam) ? Boolean.parseBoolean(noMungeParam) : this.noMunge;
        this.preserveSemi = isBoolean(preserveSemiParam) ? Boolean.parseBoolean(preserveSemiParam) : this.preserveSemi;
        this.disableOptimizations = isBoolean(disableOptimizationsParam) ? Boolean.parseBoolean(disableOptimizationsParam) : this.disableOptimizations;
    }

И, соответственно, добавляем необходимые локальные переменные:

    private FilterConfig config;

    private int lineBreak = -1;
    private boolean noMunge = false;
    private boolean preserveSemi = false;
    private boolean disableOptimizations = false;
    private boolean useCahce = true;

При инициализации используются несколько вспомогательных функций для следующих целей:

Приведение к нижнему регистру и обрезание лишних пробельных символов
Проверка на соответствие значения параметра фильтра целому числу
Проверка на соответствие значения параметра фильтра логическому числу

Реализация функций очень простая, добавляем их к фильтру:

    private String normalize(String configValue) {
        if (configValue!=null)
            return configValue.trim().toLowerCase();
        return null;
    }

    private boolean isNumber(String configValue) {
        if (configValue != null && configValue.matches("[0-9]+")){
            return true;
        }
        return false;
    }

    private boolean isBoolean(String configValue){
        if (configValue != null && configValue.matches("true|false")){
            return true;
        }
        return false;
    }

Кроме этого добавим переопределение метода деструктора для избавления от ранее инкапсулированного FilterConfig:

    @Override
    public void destroy() {
        this.config = null;
    }

А что нужно?

Одной из задач, описанных ближе к началу, было определение отдаваемого контента. Зачем это нужно? Нужно это для тех ситуаций, когда фильтр настраивается на перехват не только js и css ресурсов, а некоторого множества возможных ресурсов. Ведь не всегда отдаваемый js контент храниться с расширением *.js, более того рассчитывать на расширение вообще не очень хорошо, хотя я для удобства это делаю.

Кроме расширения ресурса, которое может нас и обмануть, возможно определить тип возвращаемого контента по заголовку "Content-Type", что в большинстве случаем вполне достаточно. Но для этого необходимо определиться какие именно значения этого заголовка нас интересуют и какие расширения бывают у css и js ресурсов.

В качестве примера я выбрал следующие значения "Content-Type":

text/javascript
application/x-javascript
application/json
text/css

и следующие расширения:

.js
.json
.css

Получается, что для определения контента, которого необходимо сжимать, достаточно проверить на соответствие выбранным значениям заголовок "Content-Type" или расширение отдаваемого ресурса.

Определим константы необходимые нам для проверки:

    private static final String JS_EXT = ".js";
    private static final String JSON_EXT = ".json";
    private static final String CSS_EXT = ".css";

    private static final String JS_CONTENT = "text/javascript";
    private static final String JS_X_CONTENT = "application/x-javascript";
    private static final String JSON_CONTENT = "application/json";
    private static final String CSS_CONTENT = "text/css";

На основании данных констант определим функции проверки:

    private boolean isJSResource(String url) {
        if (url.endsWith(JS_EXT) || url.endsWith(JSON_EXT)) {
            return true;
        }
        return false;
    }

    private boolean isJSContentType(ServletResponse wrapper) {
        if (wrapper.getContentType() != null && (wrapper.getContentType().equals(JS_CONTENT) || wrapper.getContentType().equals(JS_X_CONTENT) || wrapper.getContentType().equals(JSON_CONTENT))) {
            return true;
        }
        return false;
    }

    private boolean isCSSResource(String url) {
        if (url.endsWith(CSS_EXT)) {
            return true;
        }
        return false;
    }

Основываясь на данной проверке возможно определить что за ресурс обрабатывается и какой компрессор нам необходим для сжатия.

Оборачиваем, упаковываем...

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

Для определения "обертки" необходимо перекрыть метод getWriter или getOutputStream, а в случае, когда в цепочке фильтров присутствуют другие модифицирующие фильтры, то желательно переопределить оба метода, так как неизвестно с каким методом будет работать другой фильтр. Чтобы определить "обертку" для модификации ответа, необходимо расширить ServletResponseWrapper или HttpServletResponseWrapper:

class CharResponseWrapper extends HttpServletResponseWrapper {

    private CharArrayWriter output;

    @Override
    public String toString() {
       return output.toString();
    }

    public CharResponseWrapper(HttpServletResponse response){
       super(response);
       output = new CharArrayWriter();
    }

    @Override
    public ServletOutputStream getOutputStream() throws IOException {
     return new CharOutputStream(this.output);
    }

    @Override
    public PrintWriter getWriter(){
       return new PrintWriter(output);
    }
}

class CharOutputStream extends ServletOutputStream {

    private CharArrayWriter output;

    public CharOutputStream(CharArrayWriter output){
     this.output = output;
    }

    @Override
    public void write(int b) throws IOException {
     output.write(b);
    }

}

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

Наличие такой обертки позволяет приступить к реализации основного метода doFilter:

    @Override
    public void doFilter(ServletRequest sRequest, ServletResponse sResponse, FilterChain next) throws IOException, ServletException {

        HttpServletRequest request = (HttpServletRequest)sRequest;
        HttpServletResponse response = (HttpServletResponse)sResponse;

        String url = request.getRequestURI().toLowerCase();

        if (config != null){

                // Оборачиваем оригинальный ответ и передаем его по цепочке
                PrintWriter writer = response.getWriter();
                CharResponseWrapper wrapper = new CharResponseWrapper(response);
                next.doFilter(request, wrapper);

                // Получаем модифицированный wrapper
                StringWriter temp = new StringWriter();
                StringReader reader = new StringReader(new String(wrapper.toString().getBytes(), CHARSET));

                // Проверяем необходимость сжатия
                if (isJSResource(url) || isJSContentType(wrapper)) {
                    // Сжимаем js
                } else if (isCSSResource(url) || isCSSContentType(wrapper)) {
                    // Сжимаем css
                } else {
                    // Возвращаем без сжатия
                    temp.write(wrapper.toString());
                }

                writer.write(temp.toString());

                writer.flush();
                writer.close();
            }
        } else {
            // Что-то пошло не так... Переходим дальше по цепочке
            next.doFilter(request, response);
        }

    }

Сжимаем содержимое

YUICompressor предоставляет два необходимых нам класса, выполняющих непосредственное сжатие:

JavaScriptCompressor
СsstCompressor

Вызвав метод compress этих классов получим сжатое содержимое. Собственно, больше нам ничего и не нужно. Только нужно заметить, что процесс компрессии может выбросить исключение, которое необходимо обработать.

На основании этих классов реализуем методы, производящие компрессию:

    private void compressJSResource(String url, StringWriter temp, StringReader reader, CharResponseWrapper wrapper) {
        try {
            JavaScriptCompressor compressor =  new JavaScriptCompressor(reader,null);
            compressor.compress(temp, this.lineBreak, !this.noMunge, false, this.preserveSemi, this.disableOptimizations);
        } catch (Exception e) {
            temp.write(wrapper.toString());
        }
    }

    private void compressCSSResource(String url, StringWriter temp, StringReader reader, CharResponseWrapper wrapper) {
        try {
            CssCompressor compressor =  new CssCompressor(reader);
            compressor.compress(temp, this.lineBreak);
        } catch (Exception e) {
            temp.write(wrapper.toString());
        }
    }

Ничего сложного здесь нет и теперь можно дописать метод doFilter:

                if (isJSResource(url) || isJSContentType(wrapper)) {
                    compressJSResource(url,temp,reader,wrapper);
                } else if (isCSSResource(url) || isCSSContentType(wrapper)) {
                    compressCSSResource(url,temp,reader,wrapper);
                } else {
                    temp.write(wrapper.toString());
                }

Первая версия фильтра готова, ее можно опробовать, но...

Обдумываем результат

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

Добавляем кэширование

Исходя из имеющихся проблем необходимо добавить следующий функционал:

Сохранение сжатого ресурса
Проверка на существование уже сжатой копии по запросу
Получение ресурса из кэша
Очистка кэша
Механизм обхода кэша

Есть множество стратегий кэширования, для разных масштабов проектов следует использовать соответствующие стратегии. В качестве примера приведу простой вариант, рассчитанный на в целом малое количество статических ресурсов. В качестве основного хранилища будем использовать HashMap для получения ресурса по ключу - его имени:

private Map<String, String> cache = Collections.synchronizedMap(new LinkedHashMap<String, String>());

Кроме этого необходимо добавить имена параметров запроса, которые будем использовать для управлением кэшем. Нам необходимо три таких параметра:

Для сброса кэша
Для пропуска процесса кэширования
Для отладки, когда кэширование так же не выполняется

Естественно, в таком простом варианте поведение при втором и третьем варианте идентичное, но при усложнении фильтра в любом случае понадобиться эти ситуации разделять. Добавляем имена параметров:

    private static final String CLEAR_PARAM = "CF_CLEAR";
    private static final String SKIP_PARAM = "CF_SKIP";
    private static final String DEBUG_PARAM = "CF_DEBUG";

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

...
        if (config != null && isValidResource(url)){
            tryToResetCache(request.getParameter(CLEAR_PARAM));
            ...

Сам сброс кэша выглядит следующим образом:

    private void tryToResetCache(String param) {
        if(param != null){
            this.cache.clear();
        }
    }

Таким образом, когда с клиентской стороны приходит параметр CLEAR_PARAM, то кэш будет сбрасываться.

Запись и чтение сжатого содержимого из кэша осуществляется следующим образом:

            // Получение значения по имени запрашиваемого ресурса
            String cachedValue = cache.get(url);
            // Сохранение сжатого результата с именем
            cache.put(url, temp.toString());

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

            // Узнаем, можно ли использовать кэш
            boolean useCache = this.useCahce &&
                               request.getParameter(SKIP_PARAM) == null &&
                               request.getParameter(DEBUG_PARAM) == null;

            // Пытаемся достать сжатый результат
            String cachedValue = cache.get(url);
            // Если результат есть и можно использовать кэш
            if (useCache && cachedValue != null){
                // Отдаем кэшированное значение
                PrintWriter writer = response.getWriter();
                writer.write(cachedValue);

                writer.flush();
                writer.close();

            } else {

                // Производим сжатие и кэширование резальтата

                cache.put(url, temp.toString());

            }

Результат

package com.sultry.web.filters;

import java.io.CharArrayWriter;
import java.io.IOException;
import java.io.PrintWriter;
import java.io.StringReader;
import java.io.StringWriter;
import java.util.Collections;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.logging.Level;
import java.util.logging.Logger;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpServletResponseWrapper;

import com.yahoo.platform.yui.compressor.CssCompressor;
import com.yahoo.platform.yui.compressor.JavaScriptCompressor;

import javax.servlet.annotation.WebFilter;
import javax.servlet.annotation.WebInitParam;

/**
* @author Oleg Tsarev<br/>
* <b>mail:</b> tsarev.oi@mail.ru
*
*/

/*
* <filter>
* <filter-name>CompressingFilter</filter-name>
* <filter-class>com.sultry.web.filters.CompressingFilter</filter-class>
* <init-param>
* <param-name>lineBreak</param-name>
* <param-value>8000</param-value>
* </init-param>
* <init-param>
* <param-name>noMunge</param-name>
* <param-value>false</param-value>
* </init-param>
* <init-param>
* <param-name>preserveSemi</param-name>
* <param-value>false</param-value>
* </init-param>
* <init-param>
* <param-name>disableOptimizations</param-name>
* <param-value>false</param-value>
* </init-param>
* <init-param>
* <param-name>useCache</param-name>
* <param-value>true</param-value>
* </init-param>
* </filter>
*
*      <filter-mapping>
*          <filter-name>CompressingFilter</filter-name>
*          <url-pattern>*.css</url-pattern>
*      </filter-mapping>
*      <filter-mapping>
*          <filter-name>CompressingFilter</filter-name>
*          <url-pattern>*.js</url-pattern>
*      </filter-mapping>
*/

@WebFilter(filterName = "CompressingFilter",
           initParams = {
                @WebInitParam(name = "lineBreak", value="8000"),
                @WebInitParam(name = "noMunge", value="false"),
                @WebInitParam(name = "preserveSemi", value="false"),
                @WebInitParam(name = "disableOptimizations", value="false"),
                @WebInitParam(name = "useCache", value="true")
           },
           urlPatterns = {"*.css", "*.js"})
public class CompressingFilter implements Filter {

    private static final Logger LOGGER = Logger.getLogger(CompressingFilter.class.getName());

    private static final String LINE_PARAM = "lineBreak";
    private static final String MUNGE_PARAM = "noMunge";
    private static final String PRESERVE_PARAM = "preserveSemi";
    private static final String OPT_PARAM = "disableOptimizations";
    private static final String CACHE_PARAM = "useCache";

    private static final String JS_EXT = ".js";
    private static final String JSON_EXT = ".json";
    private static final String CSS_EXT = ".css";

    private static final String JS_CONTENT = "text/javascript";
    private static final String JS_X_CONTENT = "application/x-javascript";
    private static final String JSON_CONTENT = "application/json";
    private static final String CSS_CONTENT = "text/css";

    private static final String CLEAR_PARAM = "CF_CLEAR";
    private static final String SKIP_PARAM = "CF_SKIP";
    private static final String DEBUG_PARAM = "CF_DEBUG";

    private static final String CHARSET = "UTF-8";

    private FilterConfig config;

    private int lineBreak = -1;
    private boolean noMunge = false;
    private boolean preserveSemi = false;
    private boolean disableOptimizations = false;
    private boolean useCahce = true;

    private Map<String, String> cache = Collections.synchronizedMap(new LinkedHashMap<String, String>());

    @Override
    public void init(FilterConfig config) throws ServletException {
        this.config = config;

        LOGGER.log(Level.INFO,"Init CompressingFilter");

        String lineBreakParam = normalize(this.config.getInitParameter(LINE_PARAM));
        String noMungeParam = normalize(this.config.getInitParameter(MUNGE_PARAM));
        String preserveSemiParam = normalize(this.config.getInitParameter(PRESERVE_PARAM));
        String disableOptimizationsParam = normalize(this.config.getInitParameter(OPT_PARAM));
        String useCacheParam = normalize(this.config.getInitParameter(CACHE_PARAM));

        this.lineBreak = isNumber(lineBreakParam) ? Integer.parseInt(lineBreakParam) : this.lineBreak;
        this.noMunge = isBoolean(noMungeParam) ? Boolean.parseBoolean(noMungeParam) : this.noMunge;
        this.preserveSemi = isBoolean(preserveSemiParam) ? Boolean.parseBoolean(preserveSemiParam) : this.preserveSemi;
        this.disableOptimizations = isBoolean(disableOptimizationsParam) ? Boolean.parseBoolean(disableOptimizationsParam) : this.disableOptimizations;
        this.useCahce = isBoolean(useCacheParam) ? Boolean.parseBoolean(useCacheParam) : this.useCahce;

    }

    private boolean isNumber(String configValue) {
        if (configValue != null && configValue.matches("[0-9]+")){
            return true;
        }
        return false;
    }

    private boolean isBoolean(String configValue){
        if (configValue != null && configValue.matches("true|false")){
            return true;
        }
        return false;
    }

    private String normalize(String configValue) {
        if (configValue!=null)
            return configValue.trim().toLowerCase();
        return null;
    }

    private boolean isValidResource(String url) {
        if (url.endsWith(JS_EXT) || url.endsWith(JSON_EXT) || url.endsWith(CSS_EXT)) {
            return true;
        }
        return false;
    }

    private boolean isJSResource(String url) {
        if (url.endsWith(JS_EXT) || url.endsWith(JSON_EXT)) {
            return true;
        }
        return false;
    }

    private boolean isJSContentType(ServletResponse wrapper) {
        if (wrapper.getContentType() != null && (wrapper.getContentType().equals(JS_CONTENT) || wrapper.getContentType().equals(JS_X_CONTENT) || wrapper.getContentType().equals(JSON_CONTENT))) {
            return true;
        }
        return false;
    }

    private boolean isCSSResource(String url) {
        if (url.endsWith(CSS_EXT)) {
            return true;
        }
        return false;
    }

    private boolean isCSSContentType(ServletResponse wrapper) {
        if (wrapper.getContentType() != null && (wrapper.getContentType().equals(CSS_CONTENT))) {
            return true;
        }
        return false;
    }

    @Override
    public void doFilter(ServletRequest sRequest, ServletResponse sResponse, FilterChain next) throws IOException, ServletException {

        LOGGER.log(Level.INFO,"Start CompressingFilter");

        HttpServletRequest request = (HttpServletRequest)sRequest;
        HttpServletResponse response = (HttpServletResponse)sResponse;

        String url = request.getRequestURI().toLowerCase();

        LOGGER.log(Level.INFO, "CompressingFilter:{0}", url);

        if (config != null && isValidResource(url)){

            tryToResetCache(request.getParameter(CLEAR_PARAM));

            boolean useCache = this.useCahce &&
                               request.getParameter(SKIP_PARAM) == null &&
                               request.getParameter(DEBUG_PARAM) == null;

            String cachedValue = cache.get(url);
            if (useCache && cachedValue != null){

                LOGGER.log(Level.INFO, "Get resource ({0}) from cache", url);

                PrintWriter writer = response.getWriter();
                writer.write(cachedValue);

                writer.flush();
                writer.close();

            } else {

                PrintWriter writer = response.getWriter();
                CharResponseWrapper wrapper = new CharResponseWrapper(response);
                next.doFilter(request, wrapper);

                StringWriter temp = new StringWriter();
                StringReader reader = new StringReader(new String(wrapper.toString().getBytes(), CHARSET));

                if (isJSResource(url) || isJSContentType(wrapper)) {
                    compressJSResource(url,temp,reader,wrapper);
                } else if (isCSSResource(url) || isCSSContentType(wrapper)) {
                    compressCSSResource(url,temp,reader,wrapper);
                } else {
                    temp.write(wrapper.toString());
                    LOGGER.log(Level.WARNING, "Resource skiping: {0}", url);
                }

                cache.put(url, temp.toString());
                LOGGER.log(Level.INFO, "Added to cache: {0}", url);

                writer.write(temp.toString());

                writer.flush();
                writer.close();
            }
        } else {
            next.doFilter(request, response);
        }

    }

    private void tryToResetCache(String param) {
        if(param != null){
            this.cache.clear();
        }
    }

    private void compressJSResource(String url, StringWriter temp, StringReader reader, CharResponseWrapper wrapper) {
        try {
            JavaScriptCompressor compressor =  new JavaScriptCompressor(reader,null);
            compressor.compress(temp, this.lineBreak, !this.noMunge, false, this.preserveSemi, this.disableOptimizations);
            LOGGER.log(Level.INFO, "Compress js resource: {0}", url);
        } catch (Exception e) {
            LOGGER.log(Level.WARNING, "Can not compress resource:{0}", url);
            temp.write(wrapper.toString());
        }
    }

    private void compressCSSResource(String url, StringWriter temp, StringReader reader, CharResponseWrapper wrapper) {
        try {
            CssCompressor compressor =  new CssCompressor(reader);
            compressor.compress(temp, this.lineBreak);
            LOGGER.log(Level.INFO, "Compress css resource: {0}", url);
        } catch (Exception e) {
            LOGGER.log(Level.WARNING, "Can not compress resource:{0}", url);
            temp.write(wrapper.toString());
        }
    }

    @Override
    public void destroy() {
        this.config = null;
    }

}

class CharResponseWrapper extends HttpServletResponseWrapper {

    private CharArrayWriter output;

    @Override
    public String toString() {
       return output.toString();
    }

    public CharResponseWrapper(HttpServletResponse response){
       super(response);
       output = new CharArrayWriter();
    }

    @Override
    public ServletOutputStream getOutputStream() throws IOException {
     return new CharOutputStream(this.output);
    }

    @Override
    public PrintWriter getWriter(){
       return new PrintWriter(output);
    }
}

class CharOutputStream extends ServletOutputStream {

    private CharArrayWriter output;

    public CharOutputStream(CharArrayWriter output){
     this.output = output;
    }

    @Override
    public void write(int b) throws IOException {
     output.write(b);
    }

}

Вот и все, дальше экспериментируем сами! ^_^

Google Developer Day 2010 Moscow

2010-11-13T13:51:00.002+03:00

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

К сожалению, я не догадался взять с собой хотя бы мыльницу, поэтому пришлось обходиться только камерой моего андройда:

Об опыте использования рефлексии...

2010-09-10T12:27:00.005+04:00

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

Написание такого кода привело меня к выделению следующих особенностей:

Самоанализ позволяет внедрить множественное конфигурирование на уровне самого кода, что делает систему гибкой и модульной.
Определившись с интерфесом (я не имею ввиду java интерфесы) анализируемых классов не нужно делать никаких(!) измений в коде. Возможно только вы захотите использовать аннотации, что все равно остается весьма гибким решением. ;)
Мы получаем независимость кода от существования и правильности CDI. Конечно, если вы правильно написали анализирующий код...
Из логики кода уходит огромное количество лишнего кода, проверяющего возможность использования зависимостей.
И самое привлекательное, что становиться возможным создать общий интерфейс обмена параметрами! Вам больше не нужно думать и беспокоиться о количестве параметров в вызываемом методе, вы просто создаете специальный объект, по свойствам которого и будет выбираться метод.

Достоинства весьма привлекательные для меня, но возможно они незначительны для других разработчиков из-за очевидных проблем:

Очень непросто определить правила анализа кода в конкретном проекте.
Сложно унифицировать данные правила для выделения универсального функционала.
Интерфейс обмена параметрами далеко не всегда можно унифицировать даже в каком-то одном модуле в проекте без излишнего усложнения архитектуры.

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

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

XSLT Templater - шаблонизация на стороне клиента

2010-07-23T19:22:00.002+04:00

В начале июля мне удалось съездить на Я.Субботник, на котором меня вдохновил Степан Резников своим докладом про клиентскую шаблонизацию...

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

В качестве технологической базы выбрал XSLT, хотя JS шаблонизация во многих случая предпочтительней, но уж больно давно мне полюбилась эта технология (благодаря, кстати, Mozart Framework). В результате этого моего увлечения появился плагин для jQuery:

XSLT Templater - плагин для фреймворка jQuery, реализующий следующие задачи:

XML/XSLT процессинг

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

Кэширование позволяет организовать хранение xml/xsl для повторного использования, что и реализует базовые возможности для шаблонизации с вычислительными возможностями XSLT. Кэширование организуется на двух уровнях:
- Пользовательский уровень
  Пользователь самостоятельно управляет кэшированием с доступом только к результатам последнего преобразования. Это очень удобно, когда при ручной обработке нужно повторно использовать предыдущие аргументы. А так как кэшируется сразу XMLDocument, то наглядно получаем некоторую прибавку в скорости... Хотя нужно отметить, что самой тяжелой операцией по-прежнему является сама трансформация.
- Базовый уровень
  Внутреннее кэширование плагина, включенное по умолчанию на кэширование только xsl. Можно переключать внутренний кэш между четырьмя различными уровнями, но на практике из четырех режимов понадобятся всего 2-3.
Кэширование ведется, только для аргументов со строковым типом – строковое представление xml или ссылка на ресурс - это необходимость ассоциативных массивов. Оба уровня кэширования можно использовать совместно, но при этом они являются полностью независимыми.

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

Плагин поддерживает следующие браузеры: IE 6+, Firefox, Opera, Chrome, Safari

Различные способы вызова

Преобразования осуществляются контекстно - относительно элемента контейнера для результирующего представления. И исходный xml и xsl могут представляться в трех различных формах.

Строковые представления

Пусть существуют следующие строковые представления:
"<xml-message>"+
      "<message>It working with string representation of xml</message>"+
"</xml-message>"
и
'<?xml version="1.0"?>'+
'<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">'+
        '<xsl:template match="xml-message">'+
                '<p>Result: <xsl:value-of select="message/text()"/>!</p>'+
        '</xsl:template>'+
'</xsl:stylesheet>'
Тогда вызов xml/xsl трансформации будет выглядеть следующим образом:
$('#test1').xslt("<xml-message>"+
                               "<message>It working with string representation of xml</message>"+
                        "</xml-message>",
                        '<?xml version="1.0"?>'+
                        '<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">'+
                             '<xsl:template match="xml-message">'+
                                    '<p>Result: <xsl:value-of select="message/text()"/>!</p>'+
                             '</xsl:template>'+
                        '</xsl:stylesheet>'
);
или
var xmlString = "<xml-message>"+
                               "<message>It working with string representation of xml</message>"+
                         "</xml-message>";
var xslString = '<?xml version="1.0"?>'+
                         '<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">'+
                               '<xsl:template match="xml-message">'+
                                      '<p>Result: <xsl:value-of select="message/text()"/>!</p>'+
                               '</xsl:template>'+
                         '</xsl:stylesheet>';

$('#test1').xslt(xmlString,xslString);
Ссылка на ресурс

Пусть существует следующий файл или скрипт возвращающий следующую структуру:
/tests/data/message.xml
<?xml version="1.0"?>
<xml-message>
    <message>It working with loading xml file</message>
</xml-message>
и
/tests/xslt/message-template.xsl
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="xml-message">
     <p>Result: <xsl:value-of select="message/text()"/> and loading xslt file!</p>
    </xsl:template>
</xsl:stylesheet>
В этом случае вызов будет осуществляться следующим образом:
$('#test2').xslt("/tests/data/message.xml","/tests/xslt/message-template.xsl");
В виде XMLDocument (см. Работа с пользовательским кешем)

Комплексный пример:

var xslString = '<?xml version="1.0"?>'+
                        '<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">'+
                              '<xsl:template match="xml-message">'+
                                    '<p>Result: <xsl:value-of select="message/text()"/>!</p>'+
                              '</xsl:template>'+
                        '</xsl:stylesheet>';

$('#test2').xslt("/tests/data/message.xml",xslString);

Обратные вызовы

Для синхронизации работы нескольких вызовов и организации работы с кэшом существует механизм обратных вызовов:

$('#test2').xslt("/tests/data/message.xml","/tests/xslt/message-template.xsl", function(){
console.debug("Text message after transformation!");
});

Этот механизм позволяет организовывать цепочки вызовов, причем каждый обратный вызов уже будет иметь доступ к состоянию кеша после предыдущего вызова:

var xslString = '<?xml version="1.0"?>'+
                        '<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">'+
                              '<xsl:template match="xml-message">'+
                                     '<p>Result: <xsl:value-of select="message/text()"/>!</p>'+
                              '</xsl:template>'+
                        '</xsl:stylesheet>';

$('#test2').xslt("/tests/data/message.xml",xslString, function() {
            $('#test3').xslt("/tests/data/message.xml","/tests/xslt/message-template.xsl",  function() {
                   $('#test4').xslt("/tests/data/message.xml","/tests/xslt/message-template.xsl",function(){
                              console.debug("Text message after all transformations ");
                   });
            });
});

Работа с пользовательским кэшем

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

var xsltCache = $.getXSLTLocalCache({
        onUnlock: function(state) {
                console.debug ('New value in cache');
        }
});

Теперь этот экземпляр можно использовать в вызовах:

$('#test2').xslt("/tests/data/message.xml","/tests/xslt/message-template.xsl", function() {

$('#test3').xslt(xsltCache.getXmlDoc(),"/tests/xslt/message-template.xsl",null,xsltCache,false);
// using result of caching xml representation in callback function

},xsltCache, false);// insert local cache to transformation function and switch off base cache

В приведенном примере стоит обратить внимание на следующие особенности:

xsltCache.getXmlDoc() – получение XMLDocument исходного xml из предыдущего вызова
…null,xsltCache,false… во внутреннем вызове - null вместо функции обратного вызова, повторное использование локального кэша, полное отключение внутреннего (базового) кэширования плагина

Таким образом, после обработки первого вызова экземпляр кэша будет содержать XMLDocument для xml и xsl, которые можно использовать повторно.

Методы пользовательского кэша

Методы	Описание
checkXmlDoc()	Проверяет наличие в xml кэше значения. Возвращает true, если значение установлено, false – в обратном случае
checkXslDoc()	Проверяет наличие в xsl кэше значения. Возвращает true, если значение установлено, false – в обратном случае
getXmlDoc()	Возвращает значение xml кэша. Если значение не было установлено, то возвращает false
getXslDoc()	Возвращает значение xsl кэша. Если значение не было установлено, то возвращает false
lock()	Сервисный метод для проверки возможности работы с кэшом. Имеет только информативный смысл.
setXmlDoc(xml)	Устанавливает новое значение xml кэша. Используется внутри плагина.
setXslDoc(xml)	Устанавливает новое значение xsl кэша. Используется внутри плагина.
reset	Сбрасывает все значения кэша
unlock	Сервисный метод для проверки возможности работы с кэшом. Имеет только информативный смысл.

Работа с базовым кэшом

Базовый кэш используется внутри плагина для оптимизации преобразований. Кэширование происходит на основе строкового ключа (строковое представление xml или ссылка на ресурс) Возможны четыре состояния внутреннего кэша:

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

Настройка базового кэша

Для четырех различных случаев кэширование настраивается по-разному:

Кэшируется только xsl – режим по умолчанию
$('#test1').xslt(xmlString,xslString);
или
var cache = {
"xml":false,
"xsl":true
}
$('#test1').xslt(xmlString,xslString,null,null,cache);
Кэшируется только xml
var cache = {
"xml":true,
"xsl":false
}
$('#test1').xslt(xmlString,xslString,null,null,cache);
Кешируется и xml, и xsl
$('#test1').xslt(xmlString,xslString,null,null,true);
или
var cache = {
"xml":true,
"xsl":true
}
$('#test1').xslt(xmlString,xslString,null,null,cache);
Кеширование не происходит
$('#test1').xslt(xmlString,xslString,null,null,false);
или
var cache = {
"xml":false,
"xsl":false
}
$('#test1').xslt(xmlString,xslString,null,null,cache);

Комплексный пример

$(document).ready(function() {
        var time = new Date();
        var xmlString = "<xml-message>"+
                                         "<message>It working with string representation of xml</message>"+
                                 "</xml-message>";
        var xslString = '<?xml version="1.0"?>'+
                                 '<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">'+
                                        '<xsl:template match="xml-message">'+
                                             '<p>Result: <xsl:value-of select="message/text()"/>!</p>'+
                                        '</xsl:template>'+
                                 '</xsl:stylesheet>';

     $('#test1').xslt(xmlString,xslString);

        var xsltCache = $.getXSLTLocalCache({
                onUnlock: function(state) {
                        console.debug("Text message after setting new value in local cache!");
                }
        });

     $('#test2').xslt("/tests/data/message.xml",xslString, function() {
                  $('#test3').xslt(xsltCache.getXmlDoc(),"/tests/xslt/message-template.xsl",  function() {
                            $('#test4').xslt(xsltCache.getXmlDoc(),xsltCache.getXslDoc(),function () {
                                var time2 = new Date();
                                $("#time").text("Calculating time:"+(time2-time));
                        },xsltCache,false);
                  },xsltCache);
        },xsltCache, false);
});

Официальный сайт: http://www.xslt-templater.com
Страница проекта: http://code.google.com/p/xslt-templater/
Страница на jQuery.com: http://plugins.jquery.com/project/XSLTTemplater

Вот так, интересно ваше мнение...