Apache Wicket - это фреймворк для веб-разработки на Java. Я чувствую, что ему не уделяют столько внимания, сколько он того заслуживает. Я профессионально использую Wicket для реальных проектов последние 6 лет и мне это нравится! В этом посте давайте рассмотрим пять причин, по которым вам стоит подумать об его использовании.
1. Простое управление состоянием
Опыт разработки приложений Wicket очень похож на разработку для настольных компьютеров. Иногда вы можете почти забыть о том, чтоб вы работаете с HTTP, т.к. нет необходимости сохранять состояния. Это связано с тем, что в Wicket веб-страница и все ее компоненты (кнопки, текстовые поля и т. д.) Являются объектами Java, которые поддерживают свое собственное состояние. Состояние компонентов сериализуется в сеансе пользователя и десериализуется в нужное время.
Проще говоря, предположим, что у вас есть форма с полями, которые пользователь заполняет и отправляет. В приложении Wicket эта форма, ее поля и кнопка отправки являются компонентами (объектами Java), которые создаются и добавляются на веб-страницу. При нажатии кнопки отправки:
1.У нас автоматически есть доступ к вводу пользователя, обычно в виде полей POJO.
2.Нам не нужно связывать запрос HTTP POST с запросом GET.
Нам также не нужно думать о заполнении полей формы отправленными значениями. Это делается с помощью моделей, которые являются основной концепцией Wicket.
2. Стандартная интеграция HTML
HTML в Wicket не требует каких-либо специальных тегов, в отличие от некоторых других фреймворков. Фактически, вы можете взять любой существующий HTML и интегрировать его с вашим приложением Wicket практически без изменений. Для подключения HTML-тегов к компонентам Wicket необходим только один атрибут: wicket: id
Рассмотрим пример:
<div wicket:id="userName">Roman</div>
add(new Label("userName", getUsername()));
wicket:id "userName"
используется для подключения HTML элемента с компонентом Wicket. Компонент Wicket Label получит имя пользователя и отобразит div
тег . Ничего страшного, если сейчас это не совсем понятно. Это становится привычным и интуитивно понятным, когда вы начинаете экспериментировать с ним. Компоненты Wicket являются объектами первого класса и могут инкапсулировать собственную разметку HTML / CSS / JS, как в некоторых популярных фреймворках, таких как React. Это позволяет нам создавать код, который можно многократно использовать.
3. Не требуется Javascript (по большей части)
В какой-то момент вы закончите писать код JS. Поддержка AJAX, предоставляемая Wicket, означает, что вам не нужно писать собственный JS-код для наиболее распространенных задач. За кулисами Wicket использует JQuery и автоматически генерирует JS-код на веб-странице. Давайте рассмотрим для примера страницу с раскрывающимся списком и различными другими компонентами, которые зависят от выбора этого раскрывающегося списка. Когда выбор изменяется, нам нужно обновить эти различные другие компоненты на странице. На самом деле для этого не требуется код Javascript . Это делает Wicket идеальным решением для создания сложных интерфейсов со сложной бизнес-логикой.
4. Система событий / сообщений
События Wicket - это способ взаимодействия компонентов и страниц между собой. Используя эту функцию, мы можем создавать очень сложные, но не связанные друг с другом структуры компонентов. Компонент может транслировать сообщение, не зная, кто его получит. Когда компонент заинтересован в конкретном типе сообщения, он может просто подписаться, чтобы получать уведомление, когда это сообщение будет транслироваться. Компонент может транслировать событие критического обновления с полезной нагрузкой всем другим компонентам на странице следующим образом:
send(getPage(), Broadcast.BREADTH, new CriticalUpdate(target, payload));
И если какой-то компонент заинтересован в получении CriticalUpdate , он будет регистрироваться следующим образом:
public void onEvent(IEvent event) {
if (event.getPayload() instanceof CriticalUpdate) {
String msg = ((CriticalUpdate)event.getPayload()); //do something with the msg
}
}
5. Модульное тестирование
Компонентный / сохраняющий состояние характер Wicket означает, что мы можем писать модульные тесты для внешнего интерфейса так же, как мы пишем их для уровня сервиса или нашего уровня доступа к данным. Wicket предоставляет полезные утилиты, упрощающие написание модульных тестов. Давайте рассмотрим пример простого сценария, который может оказаться не таким простым для тестирования в других средах. У нас есть веб-страница с интерфейсом CRUD: таблица с именами и кнопками удаления. Форма с текстовым полем и кнопкой для добавления новых строк в таблицу. Мы можем написать тест, который отобразит страницу, имитирует заполнение и отправку формы пользователем, обеспечит правильное обновление таблицы, имитирует нажатие кнопки удаления пользователем и так далее. Все это может быть выполнено с использованием чистого кода Java и JUnit, не прибегая к Selenium, Puppeteer или аналогичным библиотекам.
Заключение
Надеюсь, вы услышали достаточно, чтобы попробовать Wicket. Если вам интересно узнать больше:
Перейдите на официальный сайт, где есть отличная документация.
Взгляните на примеры кода часто встречающихся практик в веб-разработке.
furic
Я услышал достаточно чтобы НЕ использовать wicket…
jquery? seriously?
andreyverbin
А что не так с jQuery? Вам же не предлагают на нем делать SPA, Wicket не так устроен.
furic
jquery это зло. Надо отдать должное за все, забыть, отпустить и забыть. Если команда wicket'а этого не понимает или застряла на нем по историческим причинам — мне с ними не по пути.
andreyverbin
Пусть зло, но на что его менять авторам Wicket?
furic
Не на что. Они решают проблему которой уже нет. Про management state in session последний раз я слышал когда писал под struts.
andreyverbin
Вы уверены? Я вот не знаю как без jQuery повесить обработчик на элементы, которых ещё на странице нет. В jQuery это что-то вроде $(“.button”).on(“click”), .button не обязательно есть на странице, но когда будет у него появится обработчик.
furic
А вы перестаньте думать jquery way и вам не надо будет добавлять handlers на элементы которых ещё нет. Даже angular помагает вам поиметь state management.
andreyverbin
Добавление обработчиков на элементы, которых еще нет это постоянно возникающая задача. Она решается и в Angular и в React, но если эти библиотеки не использовать, то решение из jQuery это самое оно. Пока писал вам ответ нашел youmightnotneedjquery.com, там видно зачем он таки нужен, даже в современном браузере.
В Wicket не нужен angular, Wicket используют как раз ради того, чтобы не иметь дела с angular, react и прочим JS добром.
Я понимаю ваш сентимент, jQuery это архаичная библиотека и все такое. Но архаичная она для целей построения сложных UI. А как набор батареек, похоже очень даже ничего. Я думаю в этом качестве он и используется в Wicket и в этом нет ничего плохого.
PS: думаю года через 3-4 Angular и прочие SPA подвинутся и станут популярными решения, которые с сервера выплевывают куски HTML и он вставляется в нужные части страницы.
furic
Спешу вам сообщить что react server side rendering работает уже несколько лет. Идея jquery влезать в DOM своими грязными ручками больше не имеет права на существование сегодня.
andreyverbin
Очень рад. Но при чем тут Wicket, который как раз нужен, чтобы не знать о react с его server side rendering?
Прекрасно, тогда расскажите как делать тупые crud приложения, в которых react и angular совершенно не нужны, ноское какой интерактив все же хочется?
Chaak
parcel + react + любое апи на сервере
andreyverbin
Хух, я же говорю, речь идёт о crud в которых react и angular это перебор.
Chaak
Хах, не соглашусь, да вы и скорее всего не поймёте, пока не попробуете. Сейчас надо 3 строчки кода написать чтобы получить минимальное приложение на реакте.
andreyverbin
Ну что ж вы меня «хороните», все я прекрасно понимаю, и react использую, там где он нужен. Очень хотел избежать этого длинного поста, но вы меня меня заставляете капитанаствовать.
Не забывайте, что в дополнение к 3м строчкам вам еще понадобится
Итого к 3м строкам прилагается ещё и 2 человека уровня senior, которые очень заняты полезным делом. Продуктивность этой связки в фича-часах такая же и даже ниже чем простого трудяги с старым добрым Razor или Wicket, не забываем, говорим о простом crud, суть которого «вытащил из базы, показал, обновил». Причём этот трудяга может быть даже джуном и все равно выдавать рабочие фичи. Все что нужно — дать ему адекватную схему БД и он уже к ней наколотит запросов. Будет не оптимально, но переписать 2 запроса из 100 это копейки.
В связке react + api два джуна утонут, один зафейлит API, а второй застрянет на каком-нибудь баге npm/webpack или одной из сотни библиотек и плагинов. В итоге вам нужны будут senior разработчики и куча коммуникации типа «а что это поле в ответе означает?» и прочие «радости» командной работы.
Chaak
andreyverbin
Смотрите, 3 строчки куда-то испарились, но добавилась необходимость знать react+redux+hooks+webpack+parcel. Иначе как выбрать parcel vs webpack или redux vs hooks? Вы просто подтвердили мой тезис — сделать можно, но количество необходимых знаний в разы больше, трудозатраты выше, сложность UI выше.
Смиритесь, react это не серебряная пуля и есть куча мест где он не нужен.
Chaak
В целом согласен, знания нужны. Но, если знаешь можно использовать и получится даже проще.
Я вот уже не помню что такое jquery, поэтому пользуюсь react и не парюсь.
stardust_kid
У них там в примерах еще и верстка таблицами. Не хочу ничего плохого про Java сказать, пол-интернета на нем работает. Но зачем лезть с бэкенд-технологиями во фронт? При этом всячески демонстрировать свое халатное отношение. Дескать, вот вам фронты «передовые» технологии 15-летней давности, кушайте не обляпайтесь.
furic
Я пробовал vaadin раньше… Dead еnd. React наше все
andreyverbin
Для админки очень должно быть хорошо. Я вот на Blazor начал админки делать — очень рад, довольно удобно, что не нужно знать JS и заморачиваться со всем зоопарком который там живет.
xdenser
раньше это когда?
stardust_kid
Знакомые фулстеки больше к Vue склоняются. Но реакт, конечно, — наше все.
iskateli Автор
Vaadin для интранета или предсказуемой нагрузки, а Wicket хорошо масштабируется.
Borz
JS лезет же в бэк — почему Java нельзя во фронт? и да, Java во фронты залезла кажется сильно раньше, чем JS только подумал про "а может мне в бек сходить?"
stardust_kid
Если вы про апплеты, то так себе примерчик, до сих пор вздрагиваю. А так, конечно, java имеет право «лезть» во фронт, как и любой другой язык. Нюанс в том, как это делать. Хороший пример — react.js, который был создан явистами, отсюда и классы, и jsx. Вот это был хороший заход. Мы, фронт энд разработчики, читали мануалы с отвисшей челюстью, в хорошем смысле.
А тянуть jquery в проект в 2021 это немного другое.
iskateli Автор
Потому что подход этого фреймфорка — server side rendering (серверный рендеринг). Есть и другие популярные веб-фреймворки, которые поддерживают такой подход и него есть свои преимущества, автор их перечислил (причём не все кстати).
stardust_kid
А причем здесь SSR? На беке можно в string рендерить хоть BolgenOS UIKit, серверу, понятно, без разницы. Разница есть для юзера, который эту кашу в браузере гоняет и для разработчика, который утомится поддерживать все это.
iskateli Автор
ну это ответ на
Wicket как раз уменьшает эту кашу их разных технологий и состояний, если ты следуешь идеологии этого фреймворка, то компилятор твой друг и товарищ.
DbLogs
Не нравится JQuery? Используйте Vue.JS вместе с Wicket: habr.com/ru/company/orienteer/blog/514938