Чем заменить JSF(primefaces)

Question

[n4ela]

Всем привет.
В трех своих последних проектах использовал primefaces, пришлось кастомизировать пару компонентов, но в целом все понравилось и писалось быстро и легко.
Хочется попробовать что нибудь новое, что бы на серверой стороне была java а на клиентской JS.
Но так что бы были как в JSF уже набор готовых компонентов.

Answer 1

[Руслан Лопатин]

Просто не используйте JSF, JSP и прочие технологии рендеринга на стороне сервера. Это бесполезная трата времени.

Сейчас нет никаких проблем с реализацией всего, что нужно, на стороне клиента средствами одного из JS-фреймворков, таких как AngularJS например (см. single page web applications). В этом случае Java-backend превращается в RESTful-сервис.

Набор доступных компонентов в JavaScript заведомо богаче, а время на разработку экономится очень существенно.

Comments

[tsegorah]

Соглашусь. Выбрал в одной работе связку клиента на чистом html5+js и сервера в виде jax-rs сервисов. Довольно гибко получается, если заранее продумать архитектуру приложения.

[Денис И.]

Не согласушсь.
И попрошу автора быть менее категоричным ;)
Вы просто не видели в какой "содом и гомору" может превратиться попытка развивать систему построенную по приницпам "толстый js + rest_сервисы" если у вас сложная бизнес-логика.

т.е. построить то вы это построите, но потом начнется такой ППЦ когда вы начнете навешивать на это сложные проверки и валидации, особенно если они связаны с чем-то что надо провреить на сервере (например, вы назначаете номер, и надо проверить соответвует ли этот номер тому, что уже есть в системе - в базе, и если есть - то надо будет пересчитать соседние номера элементов по хитроме алгоритму - например вы всавляете элемент в середину иерархического списка, и номера надо раздвинуть)... и пересчитать на клиенте вы не можете, потмоу что пересчитывать надо из нескольких мест в нескольких формах и событиях.

Вы скажете что что тут сложного? сложного в одном запросе - ничего. Но когда у вас десяток таких условий только на одну форму, то вы просто напрость потеряете хвосты того что где кончается когда начинается и что за что у вас отвечает. У вас очень быстро потеряется зависимость между формами и рест-сервисами (т.е. глядя на рест сервис вы не сможете точно скзаать какие из 50+форм системы у вас вызывают этот сервис, и какие куски процессов он поддерживает, потому вы быдете очень сильно очковать его менять)...

В общем в тяжелых случаях, ув. tsegorah - поверьте, есть очень большой смысл выносить логику работы формы на сервер, поверьтте мне. Вас просто проклинать не будут те, кто будет это развивать и поддерживать.

[Руслан Лопатин]

Денис И. Отчего же не видел? Видел. И называется это - плохая архитектура. И связано это с интеллектуальными способностями автора такой архитектуры, а никак не самим подходом.
В случае сложной логики, которая присутствует и на клиенте и на сервере, вовсе не нужно её повторять и там и там. Можно реализовать её единожды. На TypeScript, например. И спокойно использовать дважды. Возможно, с некоторыми вариациями, которые тоже нужно продумать.

[Денис И.]

Руслан Лопатин, имхо, вы просто ещё не прошли стадию отрицания одной важной истины :
"js+rest нелья приготовить правильно" ))
Вернее можно, но только небольшие закуски.

Сложный интерпрайз и разного рода АРМ операторов всех мастей делать на рестах и джейсонах - крайне рискованное дело. Настоятельно не советую. Трудозатраты и сложность после определенного момента сложности начинают расти совсем не линейно.

В случае сложной логики, которая присутствует и на клиенте и на сервере, вовсе не нужно её повторять и там и там.

Я говорю совем не про логику которая присутсвует "и на клиенте и на сервере", не упрощайте)

Я говорю про логику, которая не может присутствовать на клиенте.

Про проверки, которые можно провести _только_на_сервере_, но необходимость в которых возникает в рантайме при обработке на клинете, и которые надо "вплетать" в логику работы клиента.

Напрмер, вы не можете реализовать эти проверки на клиенте, просто потому что клиенту нелья показывать эти данные - т.е. данные с которыми вы сверяетесь нельзя сгружать на клиент. Или вы банально не можете это делать на клиенте (например, вам надо зарезервировать коды в БД в процессе редактирвоания табличных данных).

Делать это "правильно и красиво нарестах" (как вы предлагаете, как я понял) - будет очень сложно и долго. При первом-же рефакторинге эта конструкция у вас развалится, потому что вы банально не вспомните за что отвечает каждый из трех сотен созданных вами рестами, и где какая форма отвалится, "если поменять вот этот рест".

Answer 2

[Владимир Смирнов]

Работал с JSF пару лет на паре проектов, впечатления не из лучших. JSF красив только в примерах, типа написал десяток строчек — получил полнофункциональный интерфейс. Когда пишешь реальные приложения, вот так красиво можно разве что прототип накидать, когда же дело доходит до специфических рюшечек, да и просто сложной функциональности, все становится плохо. Код превращается в мешанину, в которой все спутано: логика размазана между страницами и серверными компонентами, на клиенте часть логики, на сервере — работа с интерфейсом. Сами страницы — гремучая смесь html/el/javascript и еще черт знает чего. Всегда надо помнить о цикле обработки JSF-страницы, чтобы, например, не читать из базы 7 раз одни и те же данные в момент обновления пары визуальных элементов на странице. Также надо держать в голове некие магические правила, при которых все работает, и не дай Бог применить неправильную комбинацию акшонов/онкликов/онкомплитов при которой все просто перестает работать, причем каких-либо возможностей нормального дебага не существует. Да, когда уже наработаны готовые рабочие решения, типа «если надо при закрытии диалога кроме выполнения акшона, еще обновить вон тот элемент, и сообщить тому бину что-то, то делается это ТАК», то основная часть работы делается без непонятных глюков. Но даже при этом, у меня лично, рисование каждой новой JSF-странички вызывает аллергию.

Насчет связки JavaScript-фреймоврков с Java ничего не скажу, не пробовал, но подозреваю схожую с JSF историю — сначала что-то легко и красиво заработает, а потом может начать вылазить такой ужас, что JSF покажется цветочками. Не хочу этим сказать, JavaScript-фреймоврки — это плохо, а только лишь что если будете пробовать, проверяйте что-то более сложное, чем демо-странички, прежде чем применять в серьезном проекте.

Насколько мне известно, Java в вебе в большинстве случаев применяется в корпоративных приложениях, имеющих ограниченное количество постоянных пользователей. Для таких случаев очень хорошо подходит GWT — писать на нем очень удобно, т.к. всё пишется на Java. Сгенерированный клиентский JavaScript весит обычно немало, но, загружается один раз, и лежит закешированный в браузере до следующего обновления вашего ПО. А все это время между клиентом и сервером ходят только чистые данные, и никаких html-оберток над ними. За счет такой экономии, за пару часов работы первоначальная загрузка большого JavaScript-а полностью компенсируется. GWT не очень подходит для обычных сайтов в Интернете, т.к. там пользователи обычно непостоянные (открыл страничку, посмотрел, ушел и не вернулся), и каждому загружать большой JavaScript затратно. В GWT есть готовый набор основных компонентов. Также есть фреймворки над GWT, предоставляющие более комплексные компоненты, но с ними вы опять вернетесь к истории с JSF — отлично работает и быстро разрабатывается только пока просто, потом начинается ступор, раскопки и научный тык.

Comments

[1nd1go]

Мне определенно нравится ваш взгляд на вещи! У самого именно такие же мысли, особенно про:

отлично работает и быстро разрабатывается только пока просто, потом начинается ступор, раскопки и научный тык.

Answer 3

[Serious_Sem]

Мы в текущем проекте используем Tapestry framework. Тоже компонентно-ориентированный, как и JSF. Имеет свою библиотеку tapestry-hibernate, так что можно работать прям из коробки. Своя реализация CDI. Поддержка JQuery: tapestry-Jquery-Components, Ajax и прочее. Очень хорошая документация, мгновенно-отвечающее комьюнити. Единственное, что после JSF может смущать - посроен tapestry не по jsr, так что аннотации не стандартные. Вобщем полистайте документацию, посмотрите пример, может и понравится.

Comments

[Борис Ванин]

Тапестри очень специфичный и порог для входа у него очень высокий, но если уже разобрался, то наслаждайтесь грамотной архитектурой, неплохим качеством исходников, очень высокой гибкостью и большим числом готовых для расширения компонентов.

[Serious_Sem]

@fogone К сожалению (или радости), работал только с Tapestry на javaee. Как Вы считаете, сложно на jsf перейти после него? И сложнее ли в принципе jsf, чем tapestry?

[Борис Ванин]

jsf довольно муторный и чрезмерно переусложнен абстрактностью на мой взгляд. Про переход не возьмусь судить.

Answer 4

[Losted]

Посмотрите wicket. Для внутренних проектов (а я подозреваю, что именно на таких вы и использовали JSF) подходит очень хорошо.

Answer 5

[Артем Маринов]

Если обязательно нужен набор готовых компонентов - посмотрите в сторону ZK http://www.zkoss.org/zkdemo/getting_started?rfi=1 но учитывайте что его достаточно тяжело кастомизовать (привет jsf), однако обладает гибким механизмом байндингов и другими вкусными плюшками.

Answer 6

[AlexSerov]

В основе Wicket и Tapestry лежат очень здравые идеи компонентной ориентированности. Однако в HybridJava эти идеи реализованы гораздо чище.