Comments 38
Я услышал достаточно чтобы НЕ использовать wicket…
jquery? seriously?
А что не так с jQuery? Вам же не предлагают на нем делать SPA, Wicket не так устроен.
jquery это зло. Надо отдать должное за все, забыть, отпустить и забыть. Если команда wicket'а этого не понимает или застряла на нем по историческим причинам — мне с ними не по пути.
Пусть зло, но на что его менять авторам Wicket?
Не на что. Они решают проблему которой уже нет. Про management state in session последний раз я слышал когда писал под struts.
Вы уверены? Я вот не знаю как без jQuery повесить обработчик на элементы, которых ещё на странице нет. В jQuery это что-то вроде $(“.button”).on(“click”), .button не обязательно есть на странице, но когда будет у него появится обработчик.
А вы перестаньте думать jquery way и вам не надо будет добавлять handlers на элементы которых ещё нет. Даже angular помагает вам поиметь state management.
А вы перестаньте думать jquery way и вам не надо будет добавлять handlers на элементы которых ещё нет.
Добавление обработчиков на элементы, которых еще нет это постоянно возникающая задача. Она решается и в Angular и в React, но если эти библиотеки не использовать, то решение из jQuery это самое оно. Пока писал вам ответ нашел youmightnotneedjquery.com, там видно зачем он таки нужен, даже в современном браузере.
Даже angular помагает вам поиметь state management.
В Wicket не нужен angular, Wicket используют как раз ради того, чтобы не иметь дела с angular, react и прочим JS добром.
Я понимаю ваш сентимент, jQuery это архаичная библиотека и все такое. Но архаичная она для целей построения сложных UI. А как набор батареек, похоже очень даже ничего. Я думаю в этом качестве он и используется в Wicket и в этом нет ничего плохого.
PS: думаю года через 3-4 Angular и прочие SPA подвинутся и станут популярными решения, которые с сервера выплевывают куски HTML и он вставляется в нужные части страницы.
Спешу вам сообщить что react server side rendering работает уже несколько лет. Идея jquery влезать в DOM своими грязными ручками больше не имеет права на существование сегодня.
Спешу вам сообщить что react server side rendering работает уже несколько лет.
Очень рад. Но при чем тут Wicket, который как раз нужен, чтобы не знать о react с его server side rendering?
Идея jquery влезать в DOM своими грязными ручками больше не имеет права на существование сегодня.
Прекрасно, тогда расскажите как делать тупые crud приложения, в которых react и angular совершенно не нужны, ноское какой интерактив все же хочется?
parcel + react + любое апи на сервере
Хух, я же говорю, речь идёт о crud в которых react и angular это перебор.
Хах, не соглашусь, да вы и скорее всего не поймёте, пока не попробуете. Сейчас надо 3 строчки кода написать чтобы получить минимальное приложение на реакте.
Ну что ж вы меня «хороните», все я прекрасно понимаю, и react использую, там где он нужен. Очень хотел избежать этого длинного поста, но вы меня меня заставляете капитанаствовать.
Не забывайте, что в дополнение к 3м строчкам вам еще понадобится
- отдельный фронтендер, потому что бекендер в современном front стеке ничего не понимает и не должен
- API с документацией, желательно в swagger, чтобы фронтендер знал как с ним работать.
- комплект интеграционных тестов становится из желательного обязательным, иначе фронтендер будет работать тестером
- web pack и конфиг а 1000 и более строк потому что у нас hot reload, упаковка ресурсов, ещё 3 варианта сборки, транспиляция, генерация source maps и т.п.
- type script, куда же без него современному фронтендеру
- redux и тонны boilerplate — попробуйте заставить фронтендера отступить от best practices. Boilerplate решаемо, но вы тогда тащите мало известные библиотеки, который этот boilerplate по своему «прячут» и усложняете вход в проект следующему разработчику.
- комплект тестов фронтенда, какой же приличный фронтендер будет без них работать.
- API где-то в облаке, доступное фронтендеру — не будет же он весь бек у себя разворачивать. И все заморочки связанные с обновлением этого API и коммуникацией по этому поводу.
Итого к 3м строкам прилагается ещё и 2 человека уровня senior, которые очень заняты полезным делом. Продуктивность этой связки в фича-часах такая же и даже ниже чем простого трудяги с старым добрым Razor или Wicket, не забываем, говорим о простом crud, суть которого «вытащил из базы, показал, обновил». Причём этот трудяга может быть даже джуном и все равно выдавать рабочие фичи. Все что нужно — дать ему адекватную схему БД и он уже к ней наколотит запросов. Будет не оптимально, но переписать 2 запроса из 100 это копейки.
В связке react + api два джуна утонут, один зафейлит API, а второй застрянет на каком-нибудь баге npm/webpack или одной из сотни библиотек и плагинов. В итоге вам нужны будут senior разработчики и куча коммуникации типа «а что это поле в ответе означает?» и прочие «радости» командной работы.
- webpack выкидывается, берётся parcel, в котором нет конфигурации
- в новом реакте можно все на хуках, редукс совсем не обязателен
- окружение можно поднять в докере одной кнопкой
- документация не особо нужна, все вполне решаемо коммуникацией
- это все может делать бэкэндер: если товарищ справился с jquery, то реакт будет удобнее, а в некоторых местах в разы проще
Смотрите, 3 строчки куда-то испарились, но добавилась необходимость знать react+redux+hooks+webpack+parcel. Иначе как выбрать parcel vs webpack или redux vs hooks? Вы просто подтвердили мой тезис — сделать можно, но количество необходимых знаний в разы больше, трудозатраты выше, сложность UI выше.
Смиритесь, react это не серебряная пуля и есть куча мест где он не нужен.
Я пробовал vaadin раньше… Dead еnd. React наше все
Для админки очень должно быть хорошо. Я вот на Blazor начал админки делать — очень рад, довольно удобно, что не нужно знать JS и заморачиваться со всем зоопарком который там живет.
раньше это когда?
JS лезет же в бэк — почему Java нельзя во фронт? и да, Java во фронты залезла кажется сильно раньше, чем JS только подумал про "а может мне в бек сходить?"
Как выглядит жизненный цикл запроса? Внутри используется конвейер или подписка на события (ставлю на события)? Как реализуется DI? Как предлагают организовывать доступ к данным и работу с кэшем? Есть ли из коробки механизмы управления доступом?
iskateli я всё ещё жду ответы, мне очень интересно
Чем то мне это напомнило JSF, а когда я перешел с JSF на AngularJS это был словно глоток свежего воздуха после длительного заключения в подземелье.
Собственно платформа показалась интересной, но полное отсутствие «взгляда сверху» убивает любое желание ковыряться неделями в предлагаемых авторами производных от их секретного подхода к разработке веб-приложений.
В чём главный недостаток современного образования (особенно курсов)? В полном непонимании глубин. Учат «делай так, потом вот так», а почему именно так, вот этому как раз не учат. Ну и вот результат — плодятся инструменты, которые вроде бы содержат полезные идеи, но объяснять эти идеи никто из разработчиков не готов. Хотя готовы писать длинные мануалы. Противоречие? Нет, закономерность. Потому что привыкли писать документацию для самых тупых юзеров — делай раз, делай два, если не работает — звони 101.
По платформе, если вдруг переводчик не от балды тему выбрал, всё же задам вопросы.
1. Опишите коротко жизненный цикл разработки на данной платформе.
2. Укажите место и объём кодогенерации в жизненном цикле разработки с использованием платформы.
3. Укажите способы придания интерактивности содержимому страницы в браузере.
4. Укажите отличия от базового жизненного цикла разработки на основе чистого JS+AJAX плюс столь же чистый ServerSide.
Хотя уже сам испугался — для ответа автор должен хорошо понимать альтернативные платформы, чего вряд ли стоит ожидать от очень многих авторов.
2. В справочном руководстве выполните поиск по оглавлению части слова «generat». В основном это генерация html страниц и url, если выполнить поиск по содержимому, а не оглавлению, то конечно сложно найти в таком объёме.
3. An interactive HelloWorld
4. Серверный или клиентский рендеринг на вебе: что лучше использовать у себя в проекте и почему
А вообще про Wicket к сожалению мало концентрированной информации в виде хороших гайдов.
Первый вопрос был о типичных видах деятельности разработчика. То есть в самом простом случае виды деятельности включают работы по написанию JS, html, server-side Java, созданию объектов БД. Ваша ссылка на жизненный цикл приложения даёт некоторый намёк на необходимые действия на серверной стороне, но не даёт понимания других задач, встающих перед разработчиком.
По серверной стороне. Wicket обрабатывает запросы из браузера с использованием фильтра, внутри которого он делает то же самое, что делает любой JEE сервер, то есть раздаёт запросы на обработку конкретным обработчикам. Отсюда вопрос — а зачем повторно создавать диспетчер запросов? Он уже есть в каждом известном сервере. Называется — сервлет-контейнер. Видимо авторы Wicket решили, что распределение запросов по обработчикам при помощи селектора из запроса почему-то «не комильфо». Ну ладно, можно и так, но всё же почему для этого использован фильтр? По смыслу фильтр именно фильтрует, а не обрабатывает. То есть на уровне понятий сразу вносится некоторая путаница. И так же по всей остальной части обработки запроса на сервере можно задать подобные вопросы, но это уже выльется в целую статью.
По остальным вопросам. Интерактивность веб-странице придаёт JS, а не серверная сторона. Серверная обработка не успевает за такими простыми потребностями пользователя, как банальное ожидание мгновенной реакции на действие. Плюс страница моргает, когда перегружается. Поэтому сегодня все бросились компилировать свои языки в JS (ибо это единственное животное, которое допущено в большинство браузеров). Я ожидал и от Wicket некой компиляции действий программы, описываемых на Java, в тот же JS. Но похоже, что вся интерактивность заканчивается на всего лишь передаче данных из формы на сервер с получением в ответ новой страницы. Собственно сериализация данных формы в Java была реализована в самом начале 2000-х в известной библиотеке (тогда ещё не включенной в Java), под названием Swing. Поэтому такой подход нельзя назвать новым и интересным. Но может всё же есть какая-то часть проекта, ответственная именно за работу на стороне клиента (в браузере)?
Поэтому я и спрашивал про отличия от простейшего варианта работы трёхзвенного веб-приложения. Но вы оставили ссылку на чьи-то рассуждения по поводу «рендеринга», на который вообще-то нельзя списывать всё, что происходит на сервере и на клиенте. Слово rendering имеет много значений в английском языке, но в IT используется для указания на процесс создания изображений. Веб-страницу, конечно, особенно при большом желании и недостаточном понимании, можно назвать изображением, но так ведь вы под сурдинку «рендеринга» всю деятельность разработчиков отнесёте куда-то в сферу дизайна и вёрстки страниц, что очень и очень далеко от действительности.
В общем, если на данной платформе нельзя обеспечить реальную интерактивность (то есть через JS) средствами, привычными разработчикам на Java, то всё остальное можно отнести лишь к очередной попытке переосмыслить работу на стороне сервера. И за исключением ряда отдельных идей, которые обязательно появляются у любого разработчика новой платформы просто потому, что ему надо как-то (уже по новому) решать все стандартные задачи серверной обработки, в новом решении пока не видно серьёзного шага вперёд по сравнению с другими похожими попытками.
Но тем не менее, авторам можно сказать — пилите, Шура, пилите, они в итоге обязательно станут золотыми (в смысле знания и опыт к вам в итоге поступят по расписанию).
В свое время архитектура викета мне настолько понравилась что я портировал его на PHP.
Пять причин, по которым следует использовать Apache Wicket