Версия tomcat-плагина в https://mvnrepository.com/ от 2013г. Смутило.
Wildfly наверняка хорош, но у меня к нему предвзятое отношение как к JEE AppServer-у, в то время как Jetty — просто легкий контейнер сервлетов.
Тут стоит сказать что готовый проект я стараюсь уместить в ~128M оперативки с последующим запуском на Orange PI 2, но это исключительно мой фетиш и к теме «Подготовка» никакого отношения не имеет.
Задача статьи:
Подготовить «рыбу» для использования в след. частях что-бы не возвращаться к вопросу «а как проект создать?».
Учитывая «старость» статей по JSF — показать как создать проект в 2017. Т.к. базовая конфигурация проекта изменилась со времен прошлых публикаций.
Если речь про корректное завершение транзакций/закрытие соединений и пр. в бинах — работают аннотации PostConstruct и PreDestroy.
Если нет — прошу уточнить вопрос, т.к. по идее у протухших сессий и и должен разваливаться State.
JSF уже часть JEE6, т.е. http://docs.oracle.com/javaee/6/tutorial/doc/gmgkd.html верна и для JSF.
Нет, в JSF 2.2 тоже живет: https://javaserverfaces.java.net/docs/2.2/jsdocs/
Обратите внимание на «jsf.ajax.request»
А тут от IBM чтиво: http://www.ibm.com/developerworks/ru/library/j-jsf2fu-0410/index.html
Для разного рода JS на клиенте есть такое: https://javaserverfaces.java.net/docs/2.3/jsdocs/
Это JavaScript библиотека отправляемая на клиентскую сторону.
С ее помощью можно дергать элементы JSF страницы из js.
В остальном — для клиентской отрисовки нужен REST, а это не сюда… скорее к JAX-RS.
На странице вполне может быть контент генерируемый сервером и блок div с id в который JS отрисует свои контролы.
Мне тут как-то довелось проверить скорость рендеринга формы и таблички из БД на twisted+slqalchemy, tornado+slqalchemy и jsf+hibernate.
Результаты удивили: twisted и tornado рисовали страничку за 16-18 мс., jsf управился за 4-6 мс!
Грешил на БД и/или ORM. Убрал их как явление и отрисовывал данные из json файла. Py-like: 6-8 мс, JSF: 2-4 мс.
Много думал…
Обида тут совершенно не при чем.
Ожидал услышать что «JSF мертворожденный», «тормозной», «не гибкий из-за xml» и прочие болезни JSF 1.2, а услышал «да от него все отказались, а мы даже и пробовать не стали». о_О
Это от человека работающего в grails (основной костяк реализован на groovy, а он и сам не так давно был в подвешенном состоянии)!
Т.е. предметного разговора не получилось. Просто «он мертв». Все. Без альтернатив.
Опять же, вместо пустых разговоров я не поленился перепроверить мнение. Какие уж тут обиды?
Парадоксальные вещи творятся в сообществе — технология вроде мертва, но…
Меньше чем за сутки топик просмотрели без малого 2к раз! Т.е. она мертва, но не мертва.
Без обиняков — чую придется еще пару раз приложиться к черновику, и, таки написать о минимальном проекте на maven+JSF. Так обсуждение будет более предметным.
По теме — коллеги, боюсь большинство сталкивалось с JSF версии 1.2.
Так вот 1.2 — действительно мрак, сам плевался и пришел к выводу что JSP мне хватит «за глаза».
Но вот уже 2.2 — очень даже сильна и приятна в использовании. Рекомендую!
… и конечноже один из атрибутов таблицы/модели будет foreign key.
Ну а потом уже работа с инстансами/объектами конретной модели/таблицы.
Вот об этом я и говорил… :-)
«там все просто! вжик-вжик и побежали» — повсеместная трактовка алгоритма работы с ORM (и как следствие с БД). Многие думают что структура данных не важна, просто пиши код.
Знаете, ORM со своим ООП подходом создает илюзию что форма хранения не важна (мало кто разбирался как в памяти хранятся экземпляры обектов), можно просто делать «new» и все будет хорошо. Мое мнение: ЭТО НЕ ТАК!
Если пропустить Ваш выпад по поводу «вернитесь обратно», то весь текст поста можно заменить вашим коментарием. Серьезно. Я и хотел донести что ORM не панацея! Видимо стоит очень серьезно подумать над формой и содержанием собственных мыслей и их передачей…
Да, заголовок, как и содержание, получился очень провакационным… У меня есть подозрение что большинство негатива как раз вызвано формой и сумбурностью материала. Нет, я понимаю, что прописные истины на хабре идут плохо, но это повсеместное засилье «реализаций по оф. документации» которорые сводятся к прочтению примера из 2-х моделей — добивает.
Эх… этот прекрасный новый мир в котором есть разработчик ORM, прикладной разработчик и разработчик БД… очень часто считается что первого заменит офф. документация, второй есть в наличии (ну как же, код пишет) а третий не нужен, т.к. хватит все той-же офф. документации… да и вобще, зачем тогда ORM?
Поймите, я не свое мнение высказываю, просто сталкиваясь с таким подходом прибываю в шоке. Самый вопиющий подход который используют «прикладные разработчики» я и попытался рассмотреть.
Эмм… я скорее хотел поднять вопрос проблем использования orm программистами не понимающими как в конечном счете данные будут отображены в таблицы. Некоторые считаеют что orm — эта такая магия, используя которую можно просто указать драйвер, описать пару классов и все шоколадно. А проблемы миграции, сериализации, сохранения отображения (структуры) — им чужды.
Сложный вопрос…
Enyo разрабатывался для WebOS и позиционировался как UI framework.
На тек. момент поддержка Enyo заявлена в FirefoxOS и Tizen. Через PhoneGap его можно использовать в Android, iOS и WindowsPhone. LG для своих SmartTV выбрали синтаксис сильно схожий с Enyo, хоть и не совместимый. На хабре были статьи как написать расширение для Chrome на enyo.
Я бы сказал: мобильная разработка — конек Enyo, он позволяет людям слабо имеющим отношение к web, и html в частности, создавать интерфейсы довольно высокого качества, но это ответ из разряда «Qt круче GTK потому что там виджеты интереснее»…
Enyo — довольно широкий framework, в нем есть UI елементы специально разработанные для тач интерфейсов (шутка ли, Scroller в enyo научился обрабатывать тач евенты раньше, чем работать с колесом мыши), есть API для взаимодействия с WEB сервисами по Ajax, есть стек универсальных событий и т.д. Все это реализовано так чтобы не потерять связь с другими JavaScript framework-ами (у разрабов есть в вики нативных JavaScript вызовов для обращения к Enyo объектам).
Enyo не навязывает какой-то патерн в разработке (MVP/MVC/etc.), вы вольны сами решать как связывать данные и объекты, при этом позволяет поддерживать модульную структуру приложения через деление на пакеты и последующий динамический импорт.
Для меня Enyo стал интересен после приобретения HP Touchpad. :-) Очень уж мне интересно стало как под него кодить…
Впоследствии я понял что Enyo ведет себя достойно не только в мобильных системах, но и в классическом web.
Ну правда, разве не прекрасна конструкция:
enyo.kind({name: 'MyApp'}) // прототипируем. Определяем типы, отношения и поведение.
var data = //получаем данные в json или еще как, в которых уже есть поля "kind" "name" "components"
var my_app = new MyApp(data)
my_app.renderInto(document.body)
Wildfly наверняка хорош, но у меня к нему предвзятое отношение как к JEE AppServer-у, в то время как Jetty — просто легкий контейнер сервлетов.
Тут стоит сказать что готовый проект я стараюсь уместить в ~128M оперативки с последующим запуском на Orange PI 2, но это исключительно мой фетиш и к теме «Подготовка» никакого отношения не имеет.
Задача статьи:
Jetty, ибо:
Специфика работы с Jetty будет во 2-ой части, когда буду впиливать CDI (Weld).
Там же расскажу почему Weld стал нужен в JSF с 2.3.0.
Не все сразу! :-)
Если нет — прошу уточнить вопрос, т.к. по идее у протухших сессий и и должен разваливаться State.
JSF уже часть JEE6, т.е. http://docs.oracle.com/javaee/6/tutorial/doc/gmgkd.html верна и для JSF.
Обратите внимание на «jsf.ajax.request»
А тут от IBM чтиво: http://www.ibm.com/developerworks/ru/library/j-jsf2fu-0410/index.html
Это JavaScript библиотека отправляемая на клиентскую сторону.
С ее помощью можно дергать элементы JSF страницы из js.
В остальном — для клиентской отрисовки нужен REST, а это не сюда… скорее к JAX-RS.
На странице вполне может быть контент генерируемый сервером и блок div с id в который JS отрисует свои контролы.
Честно-честно будет.
Результаты удивили: twisted и tornado рисовали страничку за 16-18 мс., jsf управился за 4-6 мс!
Грешил на БД и/или ORM. Убрал их как явление и отрисовывал данные из json файла. Py-like: 6-8 мс, JSF: 2-4 мс.
Много думал…
Ожидал услышать что «JSF мертворожденный», «тормозной», «не гибкий из-за xml» и прочие болезни JSF 1.2, а услышал «да от него все отказались, а мы даже и пробовать не стали». о_О
Это от человека работающего в grails (основной костяк реализован на groovy, а он и сам не так давно был в подвешенном состоянии)!
Т.е. предметного разговора не получилось. Просто «он мертв». Все. Без альтернатив.
Опять же, вместо пустых разговоров я не поленился перепроверить мнение. Какие уж тут обиды?
Меньше чем за сутки топик просмотрели без малого 2к раз! Т.е. она мертва, но не мертва.
Без обиняков — чую придется еще пару раз приложиться к черновику, и, таки написать о минимальном проекте на maven+JSF. Так обсуждение будет более предметным.
По теме — коллеги, боюсь большинство сталкивалось с JSF версии 1.2.
Так вот 1.2 — действительно мрак, сам плевался и пришел к выводу что JSP мне хватит «за глаза».
Но вот уже 2.2 — очень даже сильна и приятна в использовании. Рекомендую!
Вот об этом я и говорил… :-)
«там все просто! вжик-вжик и побежали» — повсеместная трактовка алгоритма работы с ORM (и как следствие с БД). Многие думают что структура данных не важна, просто пиши код.
Знаете, ORM со своим ООП подходом создает илюзию что форма хранения не важна (мало кто разбирался как в памяти хранятся экземпляры обектов), можно просто делать «new» и все будет хорошо. Мое мнение: ЭТО НЕ ТАК!
Поймите, я не свое мнение высказываю, просто сталкиваясь с таким подходом прибываю в шоке. Самый вопиющий подход который используют «прикладные разработчики» я и попытался рассмотреть.
Enyo разрабатывался для WebOS и позиционировался как UI framework.
На тек. момент поддержка Enyo заявлена в FirefoxOS и Tizen. Через PhoneGap его можно использовать в Android, iOS и WindowsPhone. LG для своих SmartTV выбрали синтаксис сильно схожий с Enyo, хоть и не совместимый. На хабре были статьи как написать расширение для Chrome на enyo.
Я бы сказал: мобильная разработка — конек Enyo, он позволяет людям слабо имеющим отношение к web, и html в частности, создавать интерфейсы довольно высокого качества, но это ответ из разряда «Qt круче GTK потому что там виджеты интереснее»…
Enyo — довольно широкий framework, в нем есть UI елементы специально разработанные для тач интерфейсов (шутка ли, Scroller в enyo научился обрабатывать тач евенты раньше, чем работать с колесом мыши), есть API для взаимодействия с WEB сервисами по Ajax, есть стек универсальных событий и т.д. Все это реализовано так чтобы не потерять связь с другими JavaScript framework-ами (у разрабов есть в вики нативных JavaScript вызовов для обращения к Enyo объектам).
Enyo не навязывает какой-то патерн в разработке (MVP/MVC/etc.), вы вольны сами решать как связывать данные и объекты, при этом позволяет поддерживать модульную структуру приложения через деление на пакеты и последующий динамический импорт.
Для меня Enyo стал интересен после приобретения HP Touchpad. :-) Очень уж мне интересно стало как под него кодить…
Впоследствии я понял что Enyo ведет себя достойно не только в мобильных системах, но и в классическом web.
Ну правда, разве не прекрасна конструкция:
Эдакий WEB 3.0 на js. :-)