У чому полягає потреба JSF, коли користувацький інтерфейс можна досягти за допомогою бібліотек JavaScript, таких як jQuery та AngularJS

Я читав про JSF, що є його рамкою інтерфейсу та забезпечує деякі компоненти інтерфейсу. Але чим це краще чи відрізняється від кількості компонентів, доступних у jQueryUI, AngularJS, ExtJS або навіть простому HTML, CSS та JavaScript.

Чому хтось повинен вивчати JSF?

JSF до звичайного JSP / Servlet / HTML / CSS / JS - це як jQuery до звичайного JS: роби більше з меншим кодом. Щоб взяти PrimeFaces (на основі jQuery + jQuery UI) як приклад, перегляньте його вітрину, щоб побачити приклади повного коду. BootsFaces (jQuery + на основі інтерфейсу Bootstrap) також має вітрину з повними прикладами коду. Якщо ви уважно вивчите ці приклади, то побачите, що в основному вам потрібен простий клас Javabean як модель та XHTML-файл як перегляд.

Зауважте, що ви не повинні бачити JSF як заміну одного HTML / CSS / JS, ви також повинні враховувати бічну частину сервера (зокрема: JSP / Servlet). JSF усуває необхідність усієї шаблону збирання параметрів запиту HTTP, їх перетворення / перевірки, оновлення значень моделі, виконання правильного методу Java для ведення бізнесу та генерування кодового коду HTML / CSS / JS. З JSF ви в основному отримуєте сторінку XHTML як визначення перегляду та клас Javabean як визначення моделі. Це значно прискорює розвиток.

Як і у всіх компонентах MVC, що базується на компонентах, ви маєте в JSF менш тонкий контроль над виведеним HTML / CSS / JS. Додавання спеціального коду JS не так просто, оскільки вам потрібно врахувати стан перегляду JSF на стороні сервера (наприклад, включення відключеної кнопки на стороні JS не дозволить увімкнути кнопку на стороні JSF, що в свою чергу є величезна перевага безпеки). Якщо це, однак, є головним шоустоппером, то скоріше шукайте базування MVC на базі дій, як Spring MVC . Ви берете до уваги лише те, що весь цей код HTML / CSS / JS (і запобігання проти XSS, CSRF та DOM-маніпуляцій!) Потрібно писати самостійно . Крім того, якщо ви повернетесь з Facelets до JSP, ви також пропустите розширені можливості шаблонування.

З іншого боку, якщо у вас є великий веб-сайт на базі JSP / Servlet / HTML / CSS / JS / jQuery, і ви хочете переробити повторний код кодової панелі JSP / Servlet / HTML / CSS / JS / jQuery на компоненти, що використовуються для багаторазового використання, тоді одним із рішень буде JSF. У цьому можуть допомогти власні шаблони, файли тегів та компоненти. З цієї точки зору, JSF стоїть вище JSP / Servlet / HTML / CSS / JS / jQuery (і тому також досить важливо зрозуміти ці основи, перш ніж зануритися в JSF).

Ви можете знайти реальний світ на основі проекту Kickoff JSF тут: Java EE Kickoff App . Ви побачите, що він містить поряд із JSF як хороший HTML5 , CSS3 та jQuery .

Дивитися також:

• Різниця між MVC запиту та компонентним MVC
• Різниця між JSP, Servlet та JSF
• Які основні недоліки JSF 2.0?
• Чи можливо використовувати JSF + Facelets з HTML 4/5?
• Коли використовувати <ui: include>, файли тегів, складені компоненти та / або користувацькі компоненти?

JSF був створений для того, щоб java магазинам не довелося вивчати такі речі, як jQuery та будувати складні JS, а натомість зосередитись на суто Java стеці. У світі, де час - це гроші та багато місця, де вже зосереджено увагу на розробці Java, одна менша мова / шматок у групі робить навчання та підтримку швидше, а значить, і дешевше.

Додам, що для великих команд JavaScript легко стати кошмаром на технічному обслуговуванні, особливо якщо деякі розробники проекту не дуже підковані до Інтернету.

З Javascript та рамками, такими як jQuery, ви маєте повну гнучкість та повний контроль. З ext і т. Д. Ви втрачаєте багато контролю і повинні адаптуватися до рамок. З JSF ви повністю втрачаєте контроль і повинні повністю адаптуватися до рамки. Ви викликаєте життєві цикли тощо, і, нарешті, у вас немає контролю, коли можна здійснити дзвінок на сервер, а де - ні. Якщо ви хочете зробити щось, що вважається "особливим", ви перебуваєте в дуже важкому становищі. А в світі JSF навіть такі основні речі, як різнокольоровий сортування таблиці або поля, де ви можете вводити лише обмежений набір символів (наприклад, числове поле), вважаються "спеціальними".

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

Але з JSF та його обмеженою гнучкістю завжди є лише кілька (або навіть лише один) правильний спосіб зробити щось. Ви дуже обмежені, не можете створювати ярлики, ви повинні писати більше XML тощо. - але при адаптації до стандарту краще контролювати код, який вироблять недосвідчені або низькокваліфіковані програмісти. Як результат, великі корпорації люблять JSF, оскільки це "безпечніше" для них.

Коли я перейшов з GWT до JSF, я був шокований, скільки речей, що було для мене природним, вважалося вкрай нетиповим і скільки простих речей було так важко досягти. Більше того, навіть внесення найменших змін, таких як додавання знаку ":" після мітки, яке в додатку, що працює на GWT / jQuery, змінило б одну функцію, генеруючи мітку, вимагало змінити десятки файлів з локалізованими властивостями, які навіть не враховували нікому, крім мене дивно ...

Переваги використання JSF полягають не лише у створенні xhtml + css + js. Іноді JSF накладає обмеження на розмітку, яку ви можете генерувати, як і будь-який базовий компонент. Але JSF не тільки для цього, його життєвий цикл допомагає значно. Після перевірки введення він може оновити модель та синхронізувати бокові серверні боби без будь-яких зусиль. ви просто говорите "що б тут не вводив користувач, перевірте, чи це число, якщо так, то збережіть його у властивості YY в об'єкті XX", і JSF зробить все це.

Так, так, ви все ще можете використовувати JQuery, JS тощо. Але JSF надає багато переваг, коли справа стосується написання коду на стороні сервера і заощаджує вас від великої кількості плит котла.

Я категорично не згоден, що jsf додає що-небудь. Це лише додає накладні витрати. Робити речі на інтерфейсі на сервері - це найсмішніша річ, яку я коли-небудь чув. І javascript для великих команд працює чудово - його називають повторним використанням коду.

Просто загорніть jquery в деякі jsp-теги, ось все, що вам потрібно, і ви зробили, і не переносьте проблеми.

Працюючи з JSF, Spring MVC, Struts, Grails, JQuery і ExtJS, я вважаю, що Grails + ExtJS - це одна потужна комбінація.

Я б забрав Граалі над JSF будь-якого дня. Мені подобається повнота ExtJS як клієнтської бази та бібліотеки, але вона постає з більш крутою кривою навчання, ніж JQuery.

Ось найбільші відмінності між jQuery та JSF:

• немає архітектури MVC
• відсутність державного контролю (дата зберігання в сеансі чи розмові, автоматичне очищення тощо)
• немає (за замовчуванням) бібліотеки перевірки
• немає бібліотеки шаблонів
• відсутність вдосконаленої навігації / маршрутизації
• сторона клієнта

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

Таким чином, його слід здебільшого використовувати для додавання поведінки щодо елементів HTML.

Використовуючи рамку ExtJS для великого веб-додатку, я знаю, наскільки це просто у використанні. ExtJS (Schena) найкраще підходить для взаємодії баз даних (Oracle 11g) в архітектурі MVC. Вид був для візуальної взаємодії з користувачем. Контролер вказав "обробку" та тригери, які потрібно використовувати для формування пакетів PLSQL (API для CRUD, запитів вибору SQL тощо). Файли Моделі та магазину використовувались для «відображення» елементів даних у програмі перегляду / введення.

ExtJS не підходить для веб-інтерфейсів без інтенсивних баз даних - де Angular JS може краще підходити.