Jaka jest potrzeba JSF, gdy UI można osiągnąć za pomocą bibliotek JavaScript, takich jak jQuery i AngularJS

Czytałem o JSF, że jest to framework UI i zawiera pewne komponenty UI. Ale w jaki sposób jest lepszy lub różni się od liczby komponentów, które są dostępne z jQueryUI, AngularJS, ExtJS, a nawet zwykłego HTML, CSS i JavaScript.

Dlaczego ktoś miałby się uczyć JSF?

JSF do zwykłego JSP / Servlet / HTML / CSS / JS jest jak jQuery do zwykłego JS: rób więcej przy mniejszej ilości kodu. Aby wziąć PrimeFaces ( oparty na jQuery + jQuery UI) jako przykład, przejrzyj jego prezentację, aby zobaczyć pełne przykłady kodu. BootsFaces ( oparty na jQuery + Bootstrap UI) ma również prezentację z kompletnymi przykładami kodu. Jeśli dokładnie przestudiujesz te przykłady, zobaczysz, że w zasadzie potrzebujesz prostej klasy Javabean jako modelu i pliku XHTML jako widoku.

Zauważ, że nie powinieneś postrzegać JSF jako zamiennika samego HTML / CSS / JS, powinieneś również wziąć pod uwagę część po stronie serwera (w szczególności: JSP / Servlet). JSF eliminuje konieczność gromadzenia parametrów żądania HTTP, ich konwersji / walidacji, aktualizowania wartości modelu, wykonywania odpowiedniej metody Java w celu wykonania zadań biznesowych i generowania standardowego kodu HTML / CSS / JS. Z JSF w zasadzie otrzymujesz stronę XHTML jako definicję widoku i klasę Javabean jako definicję modelu. To znacznie przyspiesza rozwój.

Podobnie jak w przypadku każdego szkieletu internetowego MVC opartego na komponentach, w JSF masz mniej szczegółową kontrolę nad renderowanym HTML / CSS / JS. Dodanie niestandardowego kodu JS nie jest takie proste, ponieważ musisz wziąć pod uwagę stan widoku JSF po stronie serwera (np. Włączenie wyłączonego przycisku po stronie JS nie spowoduje włączenia przycisku po stronie JSF, co z kolei jest ogromna zaleta w zakresie bezpieczeństwa). Jeśli jest to jednak główny showstopper, szukaj raczej opartej na akcji internetowej platformy MVC, takiej jak Spring MVC . Będziesz tylko brać pod uwagę, że trzeba napisać wszystko, HTML / CSS / JS kod (i zapobieganie przed XSS, CSRF i DOM-manipulacja!) Siebie . Również jeśli powrócisz z Facelets do JSP, przegapisz również zaawansowane możliwości tworzenia szablonów.

Z drugiej strony, jeśli masz dużą witrynę internetową opartą na JSP / Servlet / HTML / CSS / JS / jQuery i chcesz refaktoryzować powtarzany standardowy kod JSP / Servlet / HTML / CSS / JS / jQuery na komponenty wielokrotnego użytku, to jednym z rozwiązań byłby JSF. Mogą w tym pomóc niestandardowe szablony, pliki tagów i komponenty. Z tego punktu widzenia JSF stoi ponad JSP / Servlet / HTML / CSS / JS / jQuery (i dlatego też jest bardzo ważne, aby zrozumieć te podstawy przed zanurzeniem się w JSF).

Możesz znaleźć prawdziwy projekt startowy oparty na JSF tutaj: Aplikacja Java EE Kickoff . Zobaczysz, że zawiera obok JSF dobre HTML5 , CSS3 i jQuery .

Zobacz też:

• Różnica między Request MVC a Component MVC
• Różnica między JSP, Servletem i JSF
• Jakie są główne wady JSF 2.0?
• Czy można używać JSF + Facelets w HTML 4/5?
• Kiedy używać <ui: include>, plików znaczników, komponentów złożonych i / lub komponentów niestandardowych?

JSF został stworzony, aby sklepy java nie musiały uczyć się rzeczy takich jak jQuery i budować złożony JS, ale zamiast tego skupić się na stosie czysto Java. W świecie, w którym czas to pieniądz, a wiele miejsc już skupia się na programowaniu w Javie, jeden język mniej na sztukę w stosie sprawia, że ​​szkolenie i utrzymanie jest szybsze, a tym samym tańsze.

Dodam, że JavaScript łatwo staje się koszmarem konserwacji w dużych zespołach, zwłaszcza jeśli niektórzy programiści projektu nie są zbyt obeznani z Internetem.

Dzięki Javascript i frameworkom, takim jak jQuery, masz pełną elastyczność i pełną kontrolę. Z rozszerzeniami itp. Tracisz dużo kontroli i musisz dostosować się do frameworka. Z JSF całkowicie tracisz kontrolę i musisz całkowicie dostosować się do frameworka. Jesteś przywoływany w cyklach życia itp. Iw końcu nie masz kontroli, kiedy można nawiązać połączenie z serwerem, a kiedy nie. Jeśli masz robić coś, co jest uważane za „wyjątkowe”, jesteś w bardzo trudnej sytuacji. A w świecie JSF nawet takie podstawowe rzeczy, jak wielokolumnowe sortowanie tabel lub pola, w których można wpisać tylko ograniczony zestaw znaków (np. Pole liczbowe), są uważane za „specjalne”.

Jednak im większa masz elastyczność, tym więcej błędów lub złych praktyk możesz popełnić. Wysoka elastyczność działa tylko z wysoce inteligentnymi programistami, inni zmienią projekt w niewyobrażalny koszmar.

Ale z JSF i jego ograniczoną elastycznością, zawsze jest tylko kilka (lub nawet tylko jeden) poprawny sposób na zrobienie czegoś. Jesteś bardzo ograniczony, nie możesz tworzyć skrótów, musisz pisać więcej XML itp. - ale dostosowując się do standardu, masz lepszą kontrolę nad kodem, który stworzą niedoświadczeni lub nisko wykwalifikowani programiści. W rezultacie duże korporacje kochają JSF, ponieważ jest dla nich „bezpieczniejszy”.

Kiedy przeniosłem się z GWT do JSF, byłem zszokowany, jak wiele rzeczy, co było dla mnie naturalne, zostało uznanych za wysoce nietypowe, a ile prostych rzeczy jest tak trudnych do osiągnięcia. Co więcej, nawet wprowadzenie najmniejszych zmian, takich jak dodanie znaku ':' po etykiecie, która w aplikacji opartej na GWT / jQuery zmieniałaby jedną etykietę generującą funkcję, wymagało zmiany dziesiątek plików ze zlokalizowanymi właściwościami, co nie było nawet brane pod uwagę przez ktoś oprócz mnie dziwny ...

Korzyści z używania JSF to nie tylko generowanie xhtml + css + js. Czasami JSF nakłada ograniczenie na kod, który możesz wygenerować, jak każdy framework oparty na komponentach. Ale JSF nie służy tylko temu, jego cykl życia bardzo pomaga. Po zatwierdzeniu danych wejściowych może zaktualizować model i zsynchronizować komponenty bean po stronie serwera bez żadnego wysiłku. po prostu mówisz "cokolwiek użytkownik tu wpisze, sprawdź, czy to liczba, jeśli tak, zapisz ją we właściwości YY w obiekcie XX", a JSF zrobi to wszystko.

Więc tak, nadal możesz używać JQuery, JS itp. Ale JSF zapewnia wiele korzyści, jeśli chodzi o pisanie kodu po stronie serwera i oszczędza ci wielu problemów.

Zdecydowanie nie zgadzam się, że jsf coś dodaje. To tylko dodaje narzut. Robienie rzeczy ui na serwerze to najbardziej absurdalna rzecz, jaką kiedykolwiek słyszałem. A javascript w dużych zespołach działa świetnie - nazywa się to ponownym wykorzystaniem kodu.

Po prostu zawiń jquery w kilka tagów jsp, to wszystko, czego potrzebujesz i gotowe, i nie znoś problemów z szeklami i skalowalnością w plikach.jsf i richfaces.

Pracując z JSF, Spring MVC, Struts, Grails, JQuery i ExtJS, uważam, że Grails + ExtJS to jedna potężna kombinacja.

Każdego dnia wybrałbym Grails zamiast JSF. Podoba mi się kompletność ExtJS jako frameworka i biblioteki po stronie klienta, ale ma bardziej stromą krzywą uczenia się niż JQuery.

Oto największe różnice między jQuery i JSF:

• brak architektury MVC
• brak kontroli stanu (zapisywanie daty w sesji lub konwersacji, automatyczne czyszczenie itp.)
• no (domyślna) biblioteka walidacyjna
• brak biblioteki szablonów
• brak zaawansowanej nawigacji / wyznaczania tras
• Strona klienta

jQuery nigdy nie miał być używany jako platforma sieciowa z pełnym stosem. Był bardziej przeznaczony do zastąpienia kodu JS niskiego poziomu, aby pisanie JS stało się łatwiejsze i bardziej wydajne w mniejszej liczbie wierszy kodu.

Dlatego powinien być używany głównie do dodawania zachowania do elementów HTML.

Korzystając z frameworka ExtJS dla dużej aplikacji internetowej, wiem, jak łatwy jest w użyciu. ExtJS (Schena) najlepiej nadaje się do interakcji z bazami danych (Oracle 11g) w architekturze MVC. Widok służył do interakcji wizualnych / użytkownika. Kontroler określił „przetwarzanie” i wyzwalacze, które musiały zostać użyte z pakietów PLSQL (API dla CRUD, zapytania wybierające SQL itp.). Model i pliki sklepu zostały użyte do „mapowania” elementów danych do przeglądarki / wejść.

ExtJS nie nadaje się do interfejsów internetowych, które nie wymagają intensywnego korzystania z baz danych - gdzie Angular JS może być lepszym rozwiązaniem.