Подходит ли wicket framework для программирования на scala? Однозначно, да. Но есть ещё play framework, который написан непосредственно для scala - не лучше ли его использовать?
Когда задают такие вопросы, то в первую очередь, при ответах на них говорят о том, что wicket framework хранит состояние сесии (и это, якобы, проще для программиста), а play framework состояния не хранит и это, якобы, сложнее.
Это официальная позиция разработчиков фреймворков, но на самом деле всё не совсем так. Дело в том, что для программиста чем меньше сущностей, тем проще, то есть, хранение состояния сессии не упрощает разработку приложения, а усложняет её, так как вместо того, чтобы получить переменную из запроса, её надо брать из контекста. В чём тут может быть упрощение? Очевидно, никакого упрощения тут нет. Наоборот, использование любых глобальных переменных, в том числе и в десктопном приложении, приведёт к запутыванию кода. Причём, к запутыванию в буквальном смысле слова, то есть появлению избыточной связанности и сторонних эффектов.
К счастью, использовать состояние сесии вовсе не обязательно в wicket. Это с одной стороны, с другой же - даже в Spring REST framework может использоваться состояние сессии для хранения авторизационных реквизитов. Да, даже сейчас ещё попадаются разработчики авторизационных библиотек, не использующие JWT токены. О чём они думают? Неизвестно. Известно только, к чему это приводит - к проблемам с масштабированием, когда приходится заводить дополнительный лишний сервер, к примеру, тот же REDIS, для хранеия состояния сессии.
То есть, вопросы stateless/statefull давно следует вынести за рамки обсуждения фреймворков, ибо и в play framework никто не запрещает использовать состояние сесии, и в wicket никто не заставляет это делать.
Разница между ними несколько другого характера. Дело в том, что play framework - это шаблонизатор по типу всем известных JSP, позволяющий мешать в одном файле выполняемый код и разметку документа. То есть, это прямой путь к PHPизму только на scala - со всеми его недостатками - необходимостью дополнительно разбираться во фронтэнде, возможностью создать код из сильно связанных запутанных кусочков, которые работают с глобальными переменными, инициируемыми из запроса. В то же время, в wicket никакого кода в html нет и чтобы добавить в цикл обработки запроса какой-то левый код надо ещё постараться.
Это считается недостатком wicket - что на каждое действие надо подумать, как его делать, но это не недостаток, а главное достоинство - если вы хотите проверить логику приложения, какой-то сложный алгоритм, и написать для этого интерфейс, то изучать каждый раз заново новомодный JS framework - это избыточно. А вот написать классы модели и конструкторы классов страниц - это значит ещё раз разобраться в том, что планируется сделать и убедиться для себя - надо это делать или не надо.
Преимущество wicket в том, что для него не нужен фронтэндер, даже фронтэндер-phpшник. Понятно, что на страничку потом можно натянуть любую CSS шкурку и изменить внешний вид, но логику wicket позволяет целиком держать на сервере
Конечно, при использовании wicket не стоит забывать выделять сервисный слой и репозиторий, заменив классами wicket только контроллер, иначе можно получить тот же самый PHPизм уже внутри классов wicket приложения.
Wicket становится ужасным, когда его начинают ломать и делать так, как хочется, а не так, как в нём это предусмотрено. К примеру, посмотрите внутренности Apache OpenMeetings и попробуйте что-то существенно там поменять - будет не так просто. Особенно, если меняя вы будете продолжать настаивать на использовании своих правильных подходов, не принимая во внимание архитектуру wicket. OpenMeetings получился достаточно сложным как-раз из-за того, что в нём перемешаны куски логики в JavaScript и на сервере, что приводит к тому, что сложно разобраться, где что происходит, так что это отличный пример для того, чтобы понять, что такое wicket на java.
А вот на scala разработка в wicket практически ничем не отличается от разработки в wicket на java - всё благодаря тому, что это объектно ориентированный фреймворк без каких либо инъекций и переписываний кода через прокси классы. Даже на C++ вы можете написать реализацию wicket и работать точно так же как на java.
Единственное отличие, которое поначалу слегка пугает - это более строгое использование конструкторов при создании классов - в scala уже сразу надо передавать параметры в конструктор класса-предка, то есть, не получится сделать два конструктора с разными параметрами, вызывающие родительский класс. Однако, похоже на то, что это и не требуется при наследовании от wicket классов.
Написано на Dotty и Wicket
!без Web 2.0!
Адаптировано для работы в Lynx
канал в Дзен