Pull to refresh

Comments 48

Спасибо за обзор.
Я вот ранее использовал Wicket и GWT для создания интранет приложений. Впечатление сложилось такое же — замечательно для не очень сильно нагруженных проектов. Можете посоветовать что-то для более нагруженных?
Пока что в таких случаях использую JSP, но как-то уже надоело.
мой выбор для нагруженных приложений — это как раз GWT
в отличие от JSF-фреймворков, в GWT вы сами определяете, когда клиенту ходить на сервер и какие данные с него получать

ну, есть ещё самый крайний случай — с наибольшими возможностями по оптимизации, но при этом наиболее трудоёмкий в разработке и отладке
это клиент на JQuery и HTTP/JSON сервер, на чём удобнее, скажем на каком-нибудь RESTeasy
gwt штука хорошая, главное вовремя сказать нет, когда заказчик захочет превратить интернет приложение в интернет. Подтачивать gwt под браузеры это маленький ад, особенно при использовании сторонних компонентов.
Эх, люблю я Джаву, отличный топик.
>К сожалению, RichFaces и PrimeFaces не понимают, что при рендерении набора табов
не надо рендрить то, что в «Second tab», если выбранный таб — «First tab». RichFaces и PrimeFaces всегда создают дерево объектов, включая всё содержимое TabSet, т.е. все невыбранные табы в том числе.

У RichFaces есть атрибут для настройки этого. Разве он не работает?
<rich:tabPanel switchType="ajax">

</rich:tabPanel>
Как я понимаю, тут требуется, чтобы DOM-дерево не строилось, но все данные выгрузились скопом.
Просто очевидно, что просто загрузка данных тормозит работу не сильно, а вот работа со страницей с монструозным домом — будет медленной.
атрибут есть, да
это управление тем, как происходит переключение таба
но всё равно — рендрятся все элементы во всех табах

вот одно из описаний проблемы
на момент 4.1.0.Milestone3 воз был всё ещё там, я не смотрел на Milestone 4 и CR1
Если Вы про рендеринг на события ajax, их надо разделять регионами.
Спасибо, хороший обзор. Хотел уточнить вещь: бэкенд интерфейс — вы что под этим подразумеваете? Мониторинг утилизации ресурсов, судя по скриншотам?

От сбя дбавлю про jsf. Не знаю что там поменялось в версии 2, но версия 1.2 имела веселые вещи, типа различия имплементаций саном и myfaces. Вроде как richfaces работали только с одной. Так же там постоянно протекали абстракции динамических компонентов, что заставляло подписывать свой javascript с бошими трудностями по его дебагу.

Другой забавной штукой было хранени состояния view. Либо ты его хранишь на сервере, где он хранится в сессии, либо на клиенте. Состояние — это сериализоанный граф jsf компонентов. Если использовать всякие няшки от jsf по и18ции, а также например больше одной формы на странице, то просто можно получить страницу весом мегабайт 5 чистого хтмла из-за сериализованного там viewstateа. При использовании по-моему richfaces, компонент который хранит состояние на клиенте переопределен и тупо вовращает null при попытке его получить (хвала opensource).

Вообщем, можно сказать, чо jsf я готовить не умею, но впечатление он ( в купе с улучшайзерами ) произвел очень протекающей абстракции.
в данном случае это был бэкенд к digital asset management, но в принципе может быть какой угодно интранетный интерфейс — екоммерц, CMS, CRM, ERP и т.п.

на клиенте стейт действительно можно хранить, но в данном случае я этого не делал
вообще в глубины реализации я не спускался, но содержимое AJAX-запросов, которые ICEFaces гоняет туда сюда — это тоже сериализованный стейт компонентов
но его там не мегабайты

собственно на мой взгляд, достоинство JSF 2.1 и ICEFaces в частности именно в том, что удалось добиться того, что было обещано изначально — сложность реализации и абстракции прикрыты не уродливо выглядящими и не сложными в освоении фасадами
чтобы можно было заниматься бизнес-программированием пользовательского интерфейса на уровне код+маркап… короче, как во Flex, только сразу с привязкой к объектам на сервере
У меня вопрос про JRebel. Вы ведь пишите, что разрабатываете на IntelliJ IDEA, но она позволяет своими средствами редеплоить приложение без остановки сервера. У JRebel есть какие-то плюсы перед штатными средствами IDEA? Почему вы выбрали именно его?
А можно поподробнее про штатные средства? Как это работает? И что для этого нужно — собирать проект идеей?
Да, чтобы это работало, нужно собирать проекты идеей. У нее есть такое понятие, как артефакты. Это то, как в конце будет выглядеть проект. Можно выбрать war-архив, тогда проект каждый раз при деплое будет собираться в war и он будет каждый раз распаковываться на сервере. А можно выбрать war-exploded. Тогда IDEA создаст папку в вашем проекте, куда будет скидывать скомпилированный проект, и будет перенаправлять сервер приложений использовать эту папку(как бы подменяя ею war). И в этом случае можно будет не перезапускать каждый раз сервер при изменении кода(IDEA использует Hot Swap для этого).
Правда есть и ньаюнсы. Такой вариант подходит не для всего. Например, изменение аннотаций у меня не подхватываются, приходится перезапускать каждый раз заново. Это наверное из за специфики, в которой я особо глубоко не копал. Поэтому и спрашиваю, может быть JRebel более продвинутый в этом плане инструмент.
А. ну так это проблемы HotSwap — изменения подхватываются внутри метода only. Дело в том, что JRebel работает по другому — он прямо в контейнер засовывает новый байткод класса, а поэтому может работать с чем угодно — можно добавлять методы и поля классов, менять методы и прочее. Не работает только смена super-класса. Алсо, JRebel в последнее время научился вроде как подхватывать и аннтационные изменения, т.е. работать с CDI, но я не проверял. Алсо, JRebel требует от сервера больший размер PermGen. Для работы JRebel в идее нужен плагин(но это только чтобы дебаг работал по измененным классам).

И для идеи не обязательно делать сборку самостоятельно. Просто в ней надо сказать, чтобы она классы компилировала туда же, куда собирает ваш сборщик — ant, maven и так далее.
Алсо, JRebel в последнее время научился вроде как подхватывать и аннтационные изменения


Да вобщем то не в последнее время, а давольно давно :)
Подхватить аннотацию — это не довольно небольшая задача. Большая задача — в зависимости от изменения аннотации правильно подкрутить фреймворк, для которого данная аннотация используется.

Плагин, в IntelliJ, как и в других IDE нужен по существу для автоматизации — просто так удобней инсталлировать и запускать. Ну и да — дебаггер тоже подкручивается. Но по сути можно и без плагина (кроме дебаггера) всё настроить.
>
И в этом случае можно будет не перезапускать каждый раз сервер при изменении кода(IDEA использует Hot Swap для этого).


eclipse умеет использовать HotSwap и для приложений задеплоенных как WAR, собственно HotSwap и есть средство загрузки перекомпилированного кода в JVM (Class File Replacement), вне зависимости от того как приложение было запущено

другое дело, что HotSwap действительно сильно органичен по тому какие изменения допустимы
JRebel позволяет обойтись без редеплоя. Этим и отличается.
По ссылке как раз сравнение с Hot Swap.
Да, да, увидел. Спасибо за информацию.
Я неправильно выразился. IDEA тоже не редеплоит каждый раз приложение на сервер. Я в значении «редеплоить» имел ввиду отражение изменений в коде на сервере.
да, именно
если меняется логика на стороне сервера, в IDEA достаточно нажать Ctrl F9, и JRebel перегружает изменённые классы
при этом приложение не останавливается, и HTTP сессия остаётся, т.е. можно достичь фактической скорости разработки как в PHP или Django
Подскажите, что нужно использовать для разработки GWT в Idea, дабы серверные изменения подхватывались на лету?
Дело в том, что для модуля gwt нельзя указать использование exploded. Прикручивать JRebel?
Спасибо за подсказку, но Update Project при дебаге (ctrl+f10) действительно подхватил изменения! Я счастлив!
Правильно ли я понял, что JRebel дает возможность Idea подхватывать значительные изменения кода — добавление методов, полей и т.д.?
У PrimeFaces в последних версиях по крайней мере в p:dialog есть атрибут dynamic. Не то?
Важный итог: теперь я знаю, для чего можно использовать JSF (то есть не вообще JSF, а конкретно ICEFaces) — для backend-интерфейсов, не очень сильно нагруженных (порядка сотен пользователей)…

Из статьи совершенно не понятно откуда взялся такой вывод. Почему «сотен пользователей» а не десятков или тысяч?
Хотелось бы видеть хотя бы минимальные замеры или сравнения производительности
вывод делается просто из архитектуры

любые динамические изменения страницы (вплоть до «открыть/закрыть диалог») требуют обмена с сервером или же придётся спускаться на уровень JS, существенно проиграв в скорости разработки и сложности получившегося кода

нет контроля над обменом с сервером, вообще нет программирования «клиентского приложения» (JS, исполняемого в браузере) как такового
поэтому при прочих равных, я бы не стал рекомендовать JSF как технологию для е-коммерс фронтенда

если хочется оптимизировать, то, как мне показалось, PrimeFaces даёт наибольшую открытость в смысле встраивания JS/JQuery логики
но создавать такой странный гибрид мне в данном случае не захотелось
Поддерживаю, что это прослеживается из архитектуры.

Вообще, ИМО, такие библиотеки и надстройки (это и JSF, Wicket, Vaadin, GWT ) позволяют сделать где-то 50% функционала любой морды просто, 35% делается тяжело или очень тяжело, а 15 или 10 процентов вообще сделать не возможно, поэтому стоит прежде чем комитатся на какие-то дедлайны с этими технологиями, стоит понимать их возможности и предстоящую работу.
В таком случае на чем писать остается? :-)
Не хочу показаться снобом, но Frontend developer'а не должно пугать написания JS'а. :) Не говорю, что каждый раз с нуля, фреймворки никто не отменял.
Я недопонял сначала, что идет речь о написании 90% на фреймворке, и 10% на JSe. Я думал, речь про то, что эти 10% делают фреймворк полностью непригодным для проекта. Поэтому и спросил — что остается.
Нет, я как раз говорил о фреймворках, которые я перечислил, и о 10% задач, которые делают их непригодными.

Потому что подход «вам не надо думать о JS, пишите на уютной Java, мы все сделаем за вас» конкретно протекает, и делает он это в самый неподходящий момент. Поэтому писать что-то долгосрочное и agile — может быть рискованным.

Если это какая-то фиксированная CRUD морда, то ок — быстрее пишется именно так. Если ничего до конца не известно, берем plain HTML и навешиваем на него свисто-перделки на JS подключая JS фреймворки, код которых доступен и читаем, а также расширяем.
мм, я прошу прощения, но GWT — лишний в этом ряду

программирование на GWT ничем в принципе не отличается от программирования на HTML+JQuery — клиентское приложение у вас получается такой толщины, какой вы захотите
(при этм сервером теоретически может быть что угодно… хоть PHP, который JSON умеет отдавать, хотя родная GWT-сериализация удобнее конечно для Java)

все остальные технологии исполняют GUI-код в основном на сервере и с каким попало сервером работать не могут
Проценты того, что легко или сложно сделать, точно так же применимы для GWT
Может быть, но я не вижу как может быть кодогенерация (не трансляция) быть сколь угодно оптимальной и контролируемой.
высоконагруженные приложения нагружают сервер, а не клиента
используя GWT, можно оптимизировать паттерны передачи данных так, чтобы минимизировать нагрузку на сервер
тем же самым придётся заниматься, если вы пишете клиента на чистом JS или, скажем, Flex

также в пользу компилятора GWT могу сказать, что мне известен случай, когда им транслировали iText, чтобы в результате иметь генерацию PDF в браузере… вроде бы даже работало
вообще нет программирования «клиентского приложения» (JS, исполняемого в браузере) как такового

есть
JavascriptContext — это средство для интеграции, а не разработки

например в данном проекте с его помощью был подключен CodeMirror
иначе бы пришлось как-то грязно хакать в обход всей сложной машинерии ICEFaces, с риском потери совместимости со следующим ихим релизом
для интеграции чего? что мешает добавить вызов JavascriptContext.addJavascriptCall в произвольный листенер? не понимаю, где «нет программирования JS как такового»
ничего не мешает

я понял, вам не понравилось моё выражение «нет программирования JS как такового»

наверное, я должен был сказать иначе
к примеру:
«программирование JS как таковое необходимо лишь для отдельных специфических случаев, например для интеграции с JS-библиотеками»
Немного оффтоп: как вам Wicket vs Tapestry5?

Я когда-то их сравнивал, но с тех пор много времени прошло, интересно узнать ваше мнение.
c точки зрения пользователя API какой-то фундаментальной разницы обнаружено не было
и там и там markup + бины на сервере, т.к. ajax не использовался — про него ничего сказать не могу
Wicket субъективно показался удобнее, с более «человеческим лицом»
… просачивалась необходимость использования JavaScript, которой мне хотелось как раз избежать.
Я вот никак не пойму. Как у вас получается программировать под web и избегать javascript? И зачем его избегать? Он чем-то так ужасен?
избегать его хочется по причине того, что даже будучи завёрнут в нечто кошерное типа JQuery, он всё равно хрупок, сложен и проблематичен в отладке
JS — это ассемблер веб-разработки, если хочется максимального качества и производительности — придётся спускаться до этого уровня
если же важна скорость разработки, то чем меньше JS (в открытом виде) тем лучше
как-то так
Спасибо. Всегда хотел программировать на ассемблере. Как-то не сложилось. Теперь вот хоть для веба сложилось ) А вообще, как подумать сколько абстракций и слоев между веб приложением и машинным кодом, то плохо становиться
а вы подумайте, сколько слоёв и абстракций между процессом фотосинтеза и салатом у вас на столе
это вполне естественно — чем больше у устройства функций и чем человеку приятнее с ним работать, тем сложнее становится устройство
главное — чтобы всё работало в целом надёжно

а вообще всё зависит от решаемой задачи

цель программирования в бизнес-контексте — это добиваться удовлетворительного результата за вменяемое время
я бы рекомендовал использовать JSF только если цель — сделать _быстро_, за счёт возможной потери в качестве user experience, ну да ладно, бизнес-гуй не обязан быть идеальным

если надо вылизывать производительность/UX на клиенте и по возможности снижать нагрузку на сервер — надо использовать всё что ниже, вплоть до голого JS

Из коробки почему-то артефакт заработал странно. При первом нажатии на кнопку логина ничего не происходит, чтобы войти нужно повторное нажатие. Проовал в IE и Опере.
Нельзя ли было бы обойтись без Spring'а?
Sign up to leave a comment.

Articles