Первая половина 2000-х годов стала временем создания многих популярных веб-фреймворков, используемых до сегодняшнего времени. Большая их часть так или иначе реализовывала модель web-MVC, также широко известную под именем Model 2, например Struts, WebWork (позднее переименованный в Apache Struts 2[англ.]), Spring MVC, Velocity, Stripes[2]. Подход к проектированию, применяемый в этих фреймворках, помогал отделить код, отвечающий за логику работы программы, от кода, отвечающего за отображение информации на экране пользователя. Однако ни один из этих фреймворков не предлагал полноценный объектно-ориентированный уровень абстракции от механизмов функционирования WEB-сервера, и разработчик был вынужден учитывать множество специфичных нюансов, например особенности работы HTTP/HTTPS-протоколов, обработку запросов и ответов сервера, способы хранения данных в пользовательской сессии, генерацию и обработку URL страниц и т.д. Но основным ограничением MVC шаблона стало то, что протокол HTTP/HTTPS, используемый для передачи данных, не имеет встроенных механизмов для сохранения информации о предыдущих действиях пользователя (т.е. является stаteless-протоколом), в то время как логика работы большинства web-приложений, напротив, подразумевала необходимость совершить множество связанных действий с различными веб-страницами, передавая данные и результаты их обработки между ними. Т.е. шаблон Model 2 хорошо подходил для сайтов, где требовалось отображать пользователю статичные документы, и на которых не требовалось совершать цепочки действий на нескольких страницах. Но в веб-приложениях, напротив, пользователи зачастую работали со множеством связанных компонентов, заполняли последовательно множество форм, требовали возможность вернуться к ранее введенным данным и т.д. И для этих целей Model 2, в силу своей архитектуры, привязанной к реализации передачи данных по протоколу HTTP, подходил очень плохо. Это фундаментальное ограничение, присущее шаблону web-MVC, стало причиной разработки новой плеяды веб-фреймворков, которые получили название компонентно-ориентированных, с совершенно другим подходом к проектированию архитектуры веб-приложений, который позволял сделать комфортной работу со всем массивом введенных пользователями данных и позволял строить сложные интерфейсы с богатой функциональностью, практически ничем не уступающие классическим десктоп-приложениям. И одним из этих фреймворков стал Wicket[3][4].
Разработка над первоначальной версией Wicket была начата весной 2004 года двумя сотрудниками компании Sun Microsystems - Джонатаном Локком (Jonathan Locke) и Мико Матцумурой (Miko Matsumura). Название Wicket было дано проекту Мико Матцумурой. В игре крикет термин wicket обозначает небольшие ворота, в которые боулер[англ.] должен попасть мячом (a small framework at which the bowler aims the ball), т.е. в названии фреймворка используется игра слов на английском языке[5].
Первая альфа-версия Wicket была опубликована на хостинге свободного программного обеспечения Codehaus.org под свободной лицензией Apache license[6]. После публикации она привлекла внимание группу программистов из Датской консалтинговой компании Topicus, под руководством Элко Хилениуса (Eelco Hillenius), Мартина Дашорста (Martijn Dashorst) и Йохана Компайнера (Johan Compagner), также к ним присоединились Юрген Доннерстаг (Juergen Donnerstag) и Крис Тюрнер (Chris Turner). Эта группа людей стала основоположниками сообщества Wicket и внесла значительный вклад в разработку и популяризацию фреймворка во всём мире[5].
Первая стабильная версия Wicket 1.0 была опубликована 7 июня 2005 года[7].
Особенности Wicket как компонентно-ориентированного фреймворка
Компонентно-ориентированные фреймворки отличаются от классических веб-фреймворков тем, что в них на стороне сервера создаётся и сохраняется модель веб-страницы, которая была открыта пользователем. HTML-код генерируется исходя из содержимого этой модели и затем отсылается клиенту. С таким подходом всё содержимое веб-страницы и все её компоненты (формы, поля ввода, ссылки, и т.д.) представлены в программе в виде чистых java-объектов, что делает возможным их обработку всеми средствами языка java. Данный подход очень похож на тот, что применяется в GUI фреймворках (таких как AWT, Swing или SWT) по отношению к графическому окну приложения и его компонентам. По сути Wicket и другие похожие фреймворки привнесли в веб-разработку подход, который ранее использовался для создания интерфейса классических десктоп-приложений. В большинстве из этих фреймворков детали работы с HTTP протоколом скрыты от разработчика, а также в них довольно естественным образом решены проблемы с сохранением пользовательских данных на стороне сервера[9].
Основные преимущества, присущие в той или иной степени всем компонентно-ориентированным фреймворкам можно свести к следующим[10]:
Веб-страницы и их элементы — это объекты, а не просто текст, передающийся от сервера клиенту. Соответственно к ним возможно применять весь инструментарий объектно-ориентированного подхода к программированию, например наследование или полиморфизм.
Веб-страницы и их элементы — это сущности, хранящие своё состояние (statefull entities), что следует из их объектной природы. Они могут хранить данные и ссылки на другие компоненты веб-приложения естественным образом. Как правило разработчику не требуется управлять механизмами сохранения пользовательских данных, например, на уровне http-сессии.
Тестирование веб-приложения значительно упрощается, так как страницы и их компоненты являются чистыми java-объектами, что позволяет использовать классические способы тестирования программного кода, такие как JUnit. Кроме того, как правило фреймворки имеют дополнительные встроенные инструменты для тестирования приложений.
Отличие Wicket от других компонентно-ориентированных фреймворков
Среди популярных фреймворков-аналогов Wicket, реализующих схожий подход к проектированию веб-приложений, можно отметить GWT, JSF, Tapestry и Vaadin. По сравнению с ними Wicket имеет следующие преимущества[11]:
Wicket полностью развивается сообществом программистов и не принадлежит какой-то коммерческой структуре;
Архитектура Wicket направлена на то, чтобы как можно больше функциональности было достигнуто с помощью синтаксических средств чистого java-кода и простого HTML. Это касается в том числе взаимодействия компонентов на странице при помощи AJAX, которое можно реализовать без написания кода на JavaScript. При этом программный код полностью разделён с HTML и состоит только из Java, а в HTML добавляются только простые wicket-теги;
С помощью Wicket можно использовать POJO и Java-beans, т.е. простые java-классы, на уровне веб-приложения, что значительно упрощает обработку пользовательских данных;
Для работы с Wicket не требуется сложных конфигурационных XML-файлов, все настройки делаются в коде.
Версии
На текущий момент являются актуальными следующие версии Wicket[12]:
