Знакомство со Stripes

Есть такой хороший фреймворк Stripes для написания веб-приложений на Java. Не так много людей, которые о нем хотя бы слышали.

Tim Fennell создал данный фреймворк в 2005 году. Он решил использовать плюшки, которые появились в Java5: аннотации, generic - и. И что самое приятное для меня, всякую конфигурацию из xml файлов.Все в Stripes нацелено на простоту. Не надо под него сильно адаптировать свой код. Он заботится о повторяющихся низкоуровневых операциях, так что разработчику остается только писать чистый, читаемый и легко поддерживаемый код.

Несмотря на свою простоту и легкость, мы получаем следующие плюшки:

1. Умную привязку (URL, параметров и событий от HTTP к Java коду).
2. Автозагрузка (Stripes сам заботится об автоподгрузке своих классов, без какой-либо XML конфигурации).
3. Валидация (Stripes предоставляет мощный механизм валидации, основанный на аннотациях).
4. Конвертация типов и форматирование (конвертация в том числе и в свои типы).
5. Слои (за счет всего лишь 3 тегов поддержка механизма повторно используемых слоев на UI).
6.  Локализация
7. Обработка исключений (собственные страницы ошибок и страницы для каких-то типовых ошибок).
8. Перехватчики (Interceptors), между request и response происходит несколько различных этапов, так вот перехватчики позволяют изменять данные на различных этапах
9. Кастомизируемые URL (можно задать паттерн для представления URL)
10. Легкая интеграция с AJAX (можно использовать для front-end части свой любимый ajax фреймворк, а об backend позаботится Stripes).
11. Тестирование (Stripes создает mock объекты, что значительно облегчает процесс автоматизированного тестирования).
12. Легкая расширяемость и возможность адаптировать  под свои нужды.
    
      

Если кратко описать суть работы Stripes, то каждый класс контроллер реализует интерфейс ActionBean и ему необходимо реализовать методы 

public ActionBeanContext getContext() { return ctx; }

public void setContext(ActionBeanContext ctx) { this.ctx = ctx; }

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

1. Они д.б. объявлены как public 
2. Они д. возвращать объект типа Resolution
3. Они не должны принимать параметров.
4. Они д.б. определены в классе, реализующем интерфейс ActionBean.

Также об ограничениях как минимум один из обработчиков событий в одном Action Bean должен иметь аннотацию @DefaultHandler (за исключением если он только один в ActionBean, но его все равно всегда рекомендуется добавлять для единообразия), иначе будет исключение. Также исключение будет в том случае, если добавить аннотацию @DefaultHandler на нескольких обработчиках в одном ActionBean. 

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

Вообще, Resolution, это интерфейс, который содержит один метод

public interface Resolution {

void execute(HttpServletRequest request,

HttpServletResponse response)

throws Exception;

} 

Существуют следующие реализации интерфейса Resolution

1. ForwardResolution (пересылает по пути такому как JSP или другой ActionBean)
2. RedirectResolution (тоже что и ForwardResolution, но использует перенаправление за счет клиентской стороны)
3. StreamingResolution (направляет поток непосредственно обратно к клиенту, например создавая бинарный файл)
4. JavaScriptResolution (конвертирует Java объект в Javascript код, который отправляется обратно на клиент и его можно расшифровать, использую Javascript функцию eval(). Это особенно полезно, когда используется Ajax).
5. ErrorResolution (отправляет HTTP ошибку обратно на клиент, используя статус ошибки и необязательное сообщение об ошибке).

Вообщем, как-то так, я сама об этом ничего не знаю, но мне это уже как-то отдаленно напоминает смесь JSF cо Struts.