Jakie są główne wady Java Server Faces 2.0?

Wczoraj widziałem prezentację na temat Java Server Faces 2.0, która wyglądała naprawdę imponująco, mimo że obecnie jestem szczęśliwym programistą ASP.NET MVC / jQuery. W JSF najbardziej podobała mi się ogromna ilość komponentów interfejsu użytkownika obsługujących AJAX, które wydają się przyspieszać programowanie znacznie szybciej niż w przypadku ASP.NET MVC, szczególnie w witrynach obciążonych AJAX. Testy integracji również wyglądały bardzo ładnie.

Ponieważ prezentacja podkreślała tylko zalety JSF, chciałbym również usłyszeć o drugiej stronie.

Więc moje pytania to:

• Jakie są główne wady Java Server Faces 2.0?
• Co może skłonić programistę JSF do skorzystania z ASP.NET MVC zamiast JSF?

Wady JSF 2.0? Szczerze mówiąc, oprócz względnej stromej krzywej uczenia się, gdy nie masz solidnej wiedzy na temat podstawowego programowania WWW (HTML / CSS / JS, po stronie serwera w stosunku do strony klienta itp.) Oraz podstawowego Java Servlet API (żądanie / odpowiedź / sesja , przekazywanie / przekierowywanie itp.), nie przychodzą na myśl żadne poważne wady. JSF w obecnym wydaniu wciąż musi pozbyć się negatywnego wizerunku, jaki zyskał we wczesnych latach, podczas których występowało kilka poważnych wad.

JSF 1.0 (marzec 2004)

To była pierwsza wersja. Było zaśmiecone błędami zarówno w obszarach podstawowych, jak i wydajnościowych, o których nie chcesz wiedzieć. Twoja aplikacja internetowa nie zawsze działała zgodnie z intuicją. Jako programista ciężko uciekasz płacząc.

JSF 1.1 (maj 2004)

To była wersja poprawki. Wydajność wciąż nie była znacznie poprawiona. Była także jedna poważna wada: nie można bezbłędnie wstawiać HTML na stronie JSF. Cały zwykły waniliowy kod HTML jest renderowany przed drzewem komponentów JSF. Musisz zawinąć wszystkie zwykłe wanilie w <f:verbatim>znaczniki, aby zostały uwzględnione w drzewie komponentów JSF. Chociaż było to zgodne ze specyfikacją, spotkało się to z dużą krytyką. Zobacz także JSF / Facelets: dlaczego nie jest dobrym pomysłem mieszanie JSF / Facelets ze znacznikami HTML?

JSF 1.2 (maj 2006)

To było pierwsze wydanie nowego zespołu programistów JSF pod przewodnictwem Ryana Lubke. Nowy zespół wykonał świetną robotę. Wprowadzono także zmiany w specyfikacji. Główną zmianą była poprawa obsługi widoku. To nie tylko całkowicie oddzieliło JSF od JSP, więc można było użyć innej technologii widoku niż JSP, ale pozwoliło także programistom na wstawienie zwykłego waniliowego HTML na stronie JSF bez konieczności używania <f:verbatim>tagów. Kolejnym ważnym celem nowego zespołu była poprawa wydajności. W czasie istnienia implementacji Sun JSF Reference Implementation 1.2 (o nazwie kodowej Mojarra od kompilacji 1.2_08, około 2008 r.), Praktycznie każda kompilacja była dostarczana z (poważnymi) poprawami wydajności obok zwykłych (drobnych) poprawek błędów.

Jedyną poważną wadą JSF 1.x (w tym 1.2) jest brak zakresu pomiędzy zakresem żądania i sesji , tak zwanego zakresu konwersacji . Zmusiło to programistów do kłopotania się z ukrytymi elementami wejściowymi, niepotrzebnymi zapytaniami DB i / lub nadużywaniem zakresu sesji, ilekroć chce się zachować początkowe dane modelu w kolejnym żądaniu w celu pomyślnego przetworzenia sprawdzania poprawności, konwersji, zmian modelu i wywoływania akcji w więcej złożone aplikacje internetowe. Ból można złagodzić, przyjmując bibliotekę strony trzeciej, która przechowuje niezbędne dane w kolejnym żądaniu, takim jak komponent MyFaces Tomahawk <t:saveState> , zakres konwersacji JBoss Seam i MyFaces Orchestra ramy konwersacji.

Kolejną wadą purystów HTML / CSS jest to, że JSF używa dwukropka :jako znaku separatora ID, aby zapewnić unikalność elementu HTML idw generowanym pliku wyjściowym HTML, szczególnie gdy komponent jest używany więcej niż jeden raz w widoku (szablony, komponenty iterujące itp.) . Ponieważ jest to niedozwolony znak w identyfikatorach CSS, należy użyć znaku \ucieczki z okrężnicy w selektorach CSS, co spowoduje brzydkie i dziwnie wyglądające selektory, takie jak #formId\:fieldId {}lub nawet #formId\3A fieldId {}. Zobacz także Jak korzystać z generowanego przez JSF identyfikatora elementu HTML z dwukropkiem „:” w selektorach CSS? Jeśli jednak nie jesteś purystą, przeczytaj również Domyślnie JSF generuje bezużyteczne identyfikatory, które są niekompatybilne z częścią css standardów internetowych .

Ponadto JSF 1.x nie był dostarczany z urządzeniami Ajax po wyjęciu z pudełka. Nie była to wada techniczna, ale z powodu szumu w Web 2.0 w tym okresie stała się wadą funkcjonalną. Exadel wcześnie wprowadził Ajax4jsf, który został gruntownie opracowany przez lata i stał się podstawową częścią biblioteki komponentów JBoss RichFaces . Kolejne biblioteki komponentów zostały również dostarczone z wbudowanymi mocami Ajax, dobrze znaną jest ICEfaces .

Mniej więcej w połowie okresu życia JSF 1.2 wprowadzono nową technologię widoku opartą na XML: Facelets . Dało to ogromne korzyści nad JSP, szczególnie w zakresie szablonów.

JSF 2.0 (czerwiec 2009)

To było drugie główne wydanie, z Ajaxem jako modnym słowem. Było wiele zmian technicznych i funkcjonalnych. JSP jest zastąpiony przez Facelets jako domyślną technologię widoku, a Facelets został rozszerzony o możliwości tworzenia niestandardowych komponentów przy użyciu czystego XML (tak zwane komponenty kompozytowe ). Zobacz także Dlaczego Facelets jest lepszy od JSP jako język definicji widoku od JSF 2.0?

Moce Ajax zostały wprowadzone w smaku <f:ajax>komponentu, który ma wiele podobieństw z Ajax4jsf. Wprowadzono adnotacje i ulepszenia związane z konwencją nad konfiguracją, aby zabić pełny faces-config.xmlplik w jak największym stopniu. Również domyślny separator identyfikatora kontenera nazewnictwa :stał się konfigurowalny, dzięki czemu purystowie HTML / CSS mogli odetchnąć z ulgą. Wszystko, co musisz zrobić, to zdefiniować go tak, jak init-paramw web.xmlnazwie javax.faces.SEPARATOR_CHARi upewnić się, że nie używasz tej postaci w dowolnym miejscu w identyfikatorach klienta, np -.

Wreszcie wprowadzono nowy zakres, zakres widoku . Wyeliminowano kolejną poważną wadę JSF 1.x, jak opisano wcześniej. Wystarczy zadeklarować komponent bean, @ViewScopedaby włączyć zakres konwersacji, bez kłopotania się wszystkimi sposobami przechowywania danych w kolejnych (konwersacyjnych) żądaniach. @ViewScopedFasola będzie żył tak długo, jak jesteś następnie złożenie i przechodząc do samego widoku (niezależnie od karcie przeglądarki / okna otwarte!), Albo synchronicznie lub asynchronicznie (Ajax). Zobacz także Różnica między zasięgiem widoku a żądaniem w zarządzanych komponentach bean i Jak wybrać odpowiedni zakres komponentu bean?

Chociaż praktycznie wszystkie wady JSF 1.x zostały wyeliminowane, istnieją błędy specyficzne dla JSF 2.0, które mogą stać się hitem. @ViewScopedNie powiedzie się obsługą znaczników ze względu na problem z kurczaka jaj w częściowym oszczędności państwa. Zostało to naprawione w JSF 2.2 i backportowane w Mojarra 2.1.18. Również przechodząc atrybuty niestandardowe jak HTML5data-xxx nie jest obsługiwany. Zostało to naprawione w JSF 2.2 dzięki nowej funkcji elementów / atrybutów przekazywania. Ponadto implementacja JSF Mojarra ma własny zestaw problemów . Względnie wiele z nich jest związanych z czasem nieintuicyjnym zachowaniem<ui:repeat> , nową implementacją oszczędzania stanu częściowego i źle zaimplementowanym zakresem flashowania . Większość z nich została naprawiona w wersji Mojarra 2.2.x.

Około czasu JSF 2.0 wprowadzono PrimeFaces , oparty na interfejsie jQuery i jQuery. Stał się najpopularniejszą biblioteką komponentów JSF.

JSF 2.2 (maj 2013)

Wraz z wprowadzeniem JSF 2.2 HTML5 był używany jako modne słowo, mimo że technicznie było to obsługiwane tylko we wszystkich starszych wersjach JSF. Zobacz także obsługę JavaServer Faces 2.2 i HTML5, dlaczego XHTML jest nadal używany . Najważniejszą nową funkcją JSF 2.2 jest obsługa niestandardowych atrybutów komponentów, co otwiera świat możliwości, takich jak niestandardowe grupy przycisków opcji bez tablic .

Oprócz błędów specyficznych dla implementacji i niektórych „irytujących drobiazgów”, takich jak niemożność wstrzyknięcia EJB do walidatora / konwertera (już naprawionego w JSF 2.3), nie ma tak naprawdę poważnych wad w specyfikacji JSF 2.2.

MVC oparty na komponentach a MVC oparty na zapytaniach

Niektórzy mogą zdecydować, że główną wadą JSF jest to, że pozwala on na bardzo drobiazgową kontrolę nad generowanym HTML / CSS / JS. To nie jest własna platforma JSF, tylko dlatego, że jest to struktura MVC oparta na komponentach , a nie struktura MVC oparta na żądaniach (działaniach) . Jeśli wysoki stopień kontroli HTML / CSS / JS jest twoim głównym wymaganiem przy rozważaniu frameworka MVC, to nie powinieneś już patrzeć na frameworkową frameworkę MVC, ale na frameworkową platformę MVC, taką jak Spring MVC . Musisz tylko wziąć pod uwagę, że będziesz musiał sam napisać cały ten szablon HTML / CSS / JS. Zobacz także Różnica między Żądaniem MVC a Składnikiem MVC .

Zobacz też:

• Jaka jest różnica między JSF, Servlet i JSP? (aby zrozumieć podstawy)
• Używanie JSF do opracowywania układów bez tablic CSS (kolejny mit o JSF)
• JSF vs zwykły HTML / CSS / JS / jQuery (gdy JSF jest złym wyborem)
• Wzorce projektowe w aplikacjach internetowych (ilustruje ideologię stojącą za MVC)

Po 5 latach pracy z JSF myślę, że mogę dodać 2 centy.

Dwie główne wady JSF :

1. Duża krzywa uczenia się. JSF jest złożony, to po prostu prawda.
2. Jego składowa natura. Struktura oparta na komponentach próbuje ukryć prawdziwą naturę sieci, która wiąże się z ogromną liczbą komplikacji i katastrof (takich jak nieobsługiwanie GET w JSF w ciągu prawie 5 lat).
   Ukrywanie przez programistów żądań / odpowiedzi HTTP przez IMHO to ogromny błąd. Z mojego doświadczenia wynika, że ​​każda platforma oparta na komponentach dodaje abstrakcji do rozwoju sieci, a ta abstrakcja powoduje niepotrzebne koszty ogólne i większą złożoność.

I drobne wady, które przychodzą mi na myśl:

1. Domyślnie identyfikator obiektu składa się z identyfikatorów jego rodziców, na przykład form1: button1.
2. Nie ma łatwego sposobu na skomentowanie nieprawidłowego fragmentu strony. Tag <ui:remove>potrzebuje poprawnej składniowo treści, która i tak jest analizowana.
3. Niskie elementy zabawy jakość 3rd które np nie sprawdzasz isRendered()wewnątrz processXxx()metody przed kontynuowaniem.
4. Włączenie LESS & Sencha jest trudne.
5. Nie działa dobrze z REST.
6. Nie jest to łatwe dla projektantów UX, ponieważ gotowe do użycia komponenty mają własne style CSS, które należy zastąpić.

Nie zrozum mnie źle. Jako framework komponentowy JSF w wersji 2 jest naprawdę dobry, ale nadal jest oparty na komponentach i zawsze będzie ...

Proszę spojrzeć na niską popularność Tapestry, Wicket i niski entuzjazm doświadczonych programistów JSF (co jest jeszcze bardziej znaczące). Dla kontrastu, spójrz na sukces Railsów, Grailsów, Django, Play! Framework - wszystkie są oparte na akcjach i nie próbują ukryć przed programistą prawdziwego żądania / odpowiedzi i bezpaństwowości Internetu.

Dla mnie jest to poważna wada JSF. IMHO JSF CAN garnitury jakiś rodzaj aplikacji (intranet, tworzy intensywnie), lecz w rzeczywistych internecie aplikacji nie jest to dobra droga.

Mam nadzieję, że pomoże to komuś w dokonaniu wyborów dotyczących frontonu.

Przypomina mi się kilka wad:

1. JSF jest strukturą opartą na komponentach. Ma to nieodłączne ograniczenia związane z przestrzeganiem modelu komponentu.
2. AFAIK JSF obsługuje tylko POST, więc jeśli chcesz GET, musisz zrobić zwykły serwlet / JSP.
3. Większość komponentów próbuje udostępniać abstrakcje w domenach, takich jak relacyjne bazy danych i front-JavaScript, i wiele razy abstrakcje te są „nieszczelne” i bardzo trudne do debugowania.
4. Te abstrakcje mogą być dobrym punktem wyjścia dla młodszego programisty lub kogoś, kto nie czuje się dobrze z określoną domeną (np. JavaScript w interfejsie użytkownika), ale bardzo trudno jest zoptymalizować wydajność, ponieważ jest w to zaangażowanych kilka warstw i większość osób z nich korzysta nie rozumiem, co dzieje się pod maską.
5. Mechanizmy szablonów, które są zwykle używane z JSF, nie mają nic wspólnego z tym, jak działają projektanci stron internetowych. Edytory WYSIWYG dla JSF są prymitywne, a w każdym razie twój projektant da ci HTML / CSS, który będziesz musiał spędzić wieki na konwersji.
6. Rzeczy takie jak wyrażenia EL nie są sprawdzane statycznie, a zarówno kompilator, jak i IDE nie radzą sobie dobrze ze znajdowaniem błędów, więc będziesz mieć błędy, które będziesz musiał wychwycić w czasie wykonywania. Może to być dobre w przypadku dynamicznie pisanego języka, takiego jak Ruby lub PHP, ale jeśli muszę wytrzymać nadęty ekosystem Java, wymagam pisania dla moich szablonów.

Podsumowując: czas, który zaoszczędzisz dzięki JSF, od unikania pisania kodu JSP / serwletu / komponentu bean, spędzisz go x10, aby skalować i robić dokładnie to, co chcesz.

Dla mnie największą wadą JSF 2.0 jest krzywa uczenia się nie tylko JSF, ale także bibliotek komponentów, których należy użyć, aby uzyskać użyteczną pracę. Rozważ zdumiewającą liczbę specyfikacji i standardów, z którymi masz do czynienia, aby naprawdę być biegłym:

• HTML w różnych wcieleniach. Nie udawaj, że nie musisz tego wiedzieć.
• HTTP - kiedy nie możesz dowiedzieć się, co się dzieje, musisz otworzyć Firebug i zobaczyć. W tym celu musisz to wiedzieć.
• CSS - Polub to lub nie. Naprawdę nie jest tak źle, a przynajmniej jest kilka fajnych narzędzi.
• XML - JSF będzie prawdopodobnie pierwszym miejscem, w którym będziesz używać przestrzeni nazw do tego stopnia.
• Specyfikacja serwletu. Wcześniej czy później przejdziesz do metod wywoływania w tym pakiecie. Poza tym musisz wiedzieć, w jaki sposób twoje Facelets zamieniają się w XHTML lub cokolwiek innego.
• JSP (głównie po to, żebyś wiedział, dlaczego nie potrzebujesz go w JSF)
• JSTL (ponownie, głównie aby poradzić sobie ze starszymi ramami)
• Expression Language (EL) w różnych formach.
• ECMAScript, JavaScript lub cokolwiek innego, jak chcesz to nazwać.
• JSON - powinieneś o tym wiedzieć, nawet jeśli go nie używasz.
• AJAX. Powiedziałbym, że JSF 2.0 porządnie ukrywa to przed tobą, ale wciąż musisz wiedzieć, co się dzieje.
• DOM. I w jaki sposób przeglądarka go używa. Zobacz ECMAScript.
• Zdarzenia DOM - temat sam w sobie.
• Architektura Java Persistence Architecture (JPA), to znaczy, jeśli chcesz, aby Twoja aplikacja miała bazę danych zaplecza.
• Sama Java.
• JSEE, kiedy jesteś przy tym.
• Specyfikacja wstrzykiwania zależności kontekstowej (CDI) oraz sposób, w jaki koliduje ona z JSF 2.0 i jest z nim używana
• JQuery - Chciałbym, żebyś się bez tego dogadywał.

Teraz, gdy skończysz, możesz zacząć korzystać z zastrzeżonych specyfikacji, a mianowicie bibliotek komponentów i bibliotek dostawców, które wybierzesz po drodze:

• PrimeFaces (moja wybrana biblioteka komponentów)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (mój dostawca JPA)
• Hibernować
• Spawać

I nie zapomnij o pojemniku! I wszystkie te pliki konfiguracyjne:

• GlassFish (2, 3 itd.)
• JBoss
• Kocur

Więc - TO UŁATWIA TO? Jasne, JSF 2.0 jest „łatwy”, o ile wszystko, co chcesz zrobić, to najbardziej podstawowe strony internetowe z najprostszymi interakcjami.

Mówiąc najprościej, JSF 2.0 jest najbardziej skomplikowanym i uciążliwym miszmaszem sklejonych technologii, jakie istnieją obecnie we wszechświecie oprogramowania. I nie mogę wymyślić niczego, co wolałbym użyć.

1. Niedoświadczeni programiści zwykle tworzą aplikacje, które są boleśnie powolne, a kod będzie naprawdę brzydki i trudny w utrzymaniu. Jest zwodniczo prosty w uruchomieniu, ale w rzeczywistości wymaga inwestycji w naukę, jeśli chcesz pisać dobre programy.
2. Przynajmniej na początku często „utkniesz” w jakimś problemie i poświęcisz więcej czasu na czytanie balusc postów w Internecie niż faktyczne działanie :) Po pewnym czasie będzie to coraz mniej, ale wciąż może być denerwujące.
3. Jeszcze bardziej irytujące, gdy dowiadujesz się, że problem nie jest spowodowany brakiem wiedzy / pomyłki, ale w rzeczywistości błędem. Mojarra był (jest?) Dość wadliwy, a kolejna warstwa komponentów dodaje jeszcze więcej problemów. Richfaces to największy kawałek badziewnego oprogramowania, jaki kiedykolwiek napisano :) Nie wiem, jak to jest teraz w wersji 4. Mamy Primefaces, które są lepsze, ale nadal będziesz mieć błędy lub brak funkcji, szczególnie z bardziej egzotycznymi komponentami. A teraz będziesz musiał zapłacić za aktualizacje Primefaces. Powiedziałbym więc, że jest wadliwy, ale poprawia się, zwłaszcza po wersji 2.2, która naprawiła pewne problemy ze specyfikacją. Framework staje się bardziej dojrzały, ale wciąż daleki od ideału (może myfaces lepiej?).
4. Nie uważam tego za szczególnie elastyczne. Często, jeśli potrzebujesz czegoś bardzo dostosowanego i nie ma żadnych komponentów, które to robią - będzie to trochę bolesne. Znowu mówię ze średniego punktu widzenia programisty - tego z terminami, samouczkami do szybkiego czytania i przeszukiwania przepływu stosu, gdy utkniesz, ponieważ nie ma czasu na naukę, jak to naprawdę działa :) Często niektóre komponenty wydają się mieć „prawie” to, czego potrzebujesz, ale nie do końca, a czasem możesz poświęcić zbyt dużo czasu, aby zrobić coś, co chcesz :) Musisz być ostrożny w ocenie, czy lepiej jest stworzyć własny lub torturować istniejący element. Właściwie, jeśli tworzysz coś naprawdę wyjątkowego, nie poleciłbym JSF.

Krótko mówiąc, moje wady to: złożoność, niezbyt płynny postęp rozwojowy, buggy, nieelastyczny.

Oczywiście są też zalety, ale nie o to prosiłeś. W każdym razie takie jest moje doświadczenie z frameworkiem, że inni mogą mieć różne opinie, więc najlepszym sposobem jest po prostu wypróbowanie go na chwilę, aby sprawdzić, czy jest on dla ciebie (tylko coś bardziej złożonego - nie naiwnych przykładów - JSF naprawdę tam świeci :) IMHO najlepszy przypadek użycia dla JSF to aplikacje biznesowe, takie jak CRM itp.

„JSF wyświetli HTML i JavaScript warstwy widoku, których nie można kontrolować ani zmieniać bez wchodzenia w kod kontrolera.”

W rzeczywistości JSF zapewnia elastyczność, możesz albo używać standardowych / zewnętrznych komponentów, albo tworzyć własne, które masz pełną kontrolę nad tym, co jest renderowane. To tylko jeden xhtml, którego potrzebujesz, aby utworzyć niestandardowe komponenty za pomocą JSF 2.0.

W ogóle nie jestem ekspertem od Java Server Faces. Ale główną wadą IMHO jest to, że jest to strona serwera. Mam dość uczenia się i korzystania ze struktur warstwy prezentacji po stronie serwera, takich jak ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php framework i ruby ​​on framework. Pożegnałem się z nimi wszystkimi i przywitałem się z Angularjs i TypeScript. Moja warstwa prezentacji działa w przeglądarce. Nie ważne, czy jest obsługiwany przez system Windows IIS z php lub ASP.NET, czy też jest obsługiwany przez serwer WWW Apache działający w systemie Linux. Muszę tylko nauczyć się jednego frameworka, który działa wszędzie.

Tylko moje dwa centy.

Opracowaliśmy przykładowy projekt z JSF (były to trzytygodniowe badania, więc możemy stracić pewne rzeczy!)

Próbujemy użyć rdzenia jsf, jeśli potrzebny jest komponent, użyliśmy PrimeFaces.

Projekt był witryną internetową z nawigacją. Każda strona powinna zostać załadowana poprzez ajax po kliknięciu menu.

Witryna ma dwa przypadki użycia:

1. Strona z siatką. Siatka jest ładowana przez ajax i powinna obsługiwać sortowanie i stronicowanie
2. Trzystopniowa strona kreatora. Każda strona ma sprawdzanie poprawności po stronie klienta (dla prostych sprawdzeń) i sprawdzanie poprawności bazy po stronie serwera (dla kompleksowych sprawdzeń). Każdy wyjątek serwera (z warstwy usług) powinien być wyświetlany na tej samej stronie kreatora bez przechodzenia do następnej strony.

Znaleźliśmy to:

1. Aby naprawić stan widoku JSF, musisz użyć kilku hacków z omniFaces. Stan JSF zostanie uszkodzony, jeśli dołączysz do siebie strony za pośrednictwem ajax. To wydaje się być błędem w JSF i może zostać naprawione w następnych wydaniach (nie w 2.3).
2. Przepływ JSF nie działa poprawnie z ajax (lub nie mogliśmy sprawić, aby działał!) Staramy się zamiast tego użyć komponentu kreatora Primeface, ale sprawdzanie poprawności klienta wydaje się nie być obsługiwane i oznacza, że ​​nie jest to standardowy standard przepływu JSF.
3. Gdy używasz niektórych komponentów jQuery, takich jak jqGird, i musisz załadować wyniki JSON, zalecamy użycie czystego serwletu, JSF nic dla ciebie nie zrobi. Jeśli więc użyjesz tego rodzaju komponentów, twój projekt nie będzie pasował do JSF.
4. Próbujemy wykonać kilka skryptów klienckich po ukończeniu ajax ajaxCompletei stwierdziliśmy, że PF 4 zaimplementował własne zdarzenia ajax. Mieliśmy kilka składników jQuery i musimy zmienić ich kod.

Jeśli zmienisz powyższy przykład na projekt inny niż Ajax (lub przynajmniej mniej projektu ajax), nie napotkasz wielu powyższych problemów.

Podsumowujemy nasze badania jako:

JSF nie działa dobrze w pełni bazowej witrynie internetowej ajax.

Oczywiście w JSF znajduje się wiele fajnych funkcji, które mogą być bardzo pomocne w niektórych projektach, więc weź pod uwagę potrzeby swojego projektu.

Proszę zapoznać się z dokumentacją techniczną JSF, aby przejrzeć zalety JSF, a moim zdaniem największą zaletą JSF jest KOMPLETNE I OGROMNE wsparcie @BalusC ;-)

Dla mnie największą wadą JSF jest słaba obsługa stron generowanych programowo (dynamicznie).
Jeśli chcesz budować swoją stronę (stwórz model komponentu strony) dynamicznie z kodu java. Na przykład, jeśli pracujesz nad konstruktorem strony internetowej WYSIWYG. Odpowiednia dokumentacja tego przypadku użycia nie jest ogólnie dostępna. Jest wiele punktów, w których musisz eksperymentować, a rozwój jest cichy i powolny. Wiele rzeczy po prostu nie działa zgodnie z oczekiwaniami. Ale generalnie jest to możliwe jakoś zhakować.
Dobrą rzeczą jest to, że nie jest to problem filozofii ani architektury JSF. Po prostu nie jest wystarczająco rozwinięty (o ile wiem).

JSF 2 wprowadził Kompozytowe Komponenty, które powinny ułatwić tworzenie komponentów, ale ich wsparcie dla dynamicznej (programowej) konstrukcji jest bardzo słabe. Jeśli przezwyciężysz cichy, skomplikowany i prawie nieudokumentowany proces dynamicznej budowy Kompozytu Kompozytowego, przekonasz się, że jeśli zagnieżdżasz kilka Kompozytów nieco głębiej, przestaną one działać, rzucając pewne wyjątki.

Wygląda jednak na to, że społeczność JSF zdaje sobie sprawę z tych niedociągnięć. Pracują nad tym, jak widać z tych dwóch błędów
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

Sytuacja powinna być lepsza z JSF 2.2, przynajmniej jeśli mówimy o specyfikacji.

Komentując moje ostatnie miesiące doświadczenia Primefaces / JSF:

• Jeśli możesz użyć komponentów „z półki”, myślę, że nie jest to okropne.
• Jednak nie działa dobrze, gdy tylko wyjdziesz na zewnątrz i potrzebujesz niestandardowych interfejsów użytkownika. - Na przykład w naszym projekcie musieliśmy użyć paska startowego Twittera. (Nie bootstrap Primefaces).
  • Teraz nasze strony działają w następujący sposób:
    • Ładowanie strony.
    • Użytkownik wchodzi w interakcje z Primefaces, które mają funkcjonalność ajax
    • Powiązania javascript Bootstrap ulegają zerwaniu
    • Uruchamiamy dodatkowy javascript, aby wszystko ponownie powiązać

Obietnica JSF, że uniknie pisania javascript, przerodziła się w pisanie większej liczby javascript, niż gdybyśmy nie korzystali z Primefaces - i ten javascript jest naprawieniem tego, co psuje Primefaces.

To zlew czasu - chyba że ponownie użyjesz rzeczy „z półki”. Również bardzo brzydkie (Primefaces), kiedy trzeba pracować z Selenem. Można to wszystko zrobić - ale znowu - jest tylko tyle czasu.

Zdecydowanie unikaj tego, jeśli pracujesz z zespołem UX / projektantem i potrzebujesz szybko iterować w interfejsie użytkownika - możesz zaoszczędzić czas, ucząc się jquery / pisania prostego HTML - lub patrząc na reakcję / kąt.

JSF ma wiele zalet, ponieważ pytanie jest niekorzystne, pozwolę sobie dodać kilka punktów.

W praktycznym scenariuszu wdrażania projektu internetowego w ramach czasowych należy zwracać uwagę na następujące czynniki.

• Czy masz wystarczająco dużo starszych członków w swoim zespole, którzy mogą zaproponować najlepsze kontrole odpowiednie dla każdego scenariusza?

• Czy masz przepustowość, aby dostosować się do początkowej krzywej uczenia się?

• Czy masz wystarczającą wiedzę specjalistyczną w swoim zespole, aby ocenić produkty JSF
  opracowane przez programistów?

Jeśli twoja odpowiedź brzmi „nie” na pytania, możesz skończyć w niemożliwej do utrzymania bazie kodu.

JSF ma tylko jedną wadę: przed rozpoczęciem tworzenia „JSF” należy dokładnie zrozumieć tworzenie stron internetowych, rdzeń Java i architekturę front-end.

Obecnie „nowe” struktury JavaScript po prostu próbują skopiować / wkleić model oparty na komponentach „JSF”.

Spośród wszystkich frameworków „głównego nurtu”, takich jak Spring MVC, Wicket, Tapestry itp., JSF Java EE z jego komponentami złożonymi jest najbardziej rozbudowaną dostarczoną technologią warstwy prezentacji i komponentów. Jest to nieco kłopotliwe i niekompletne w porównaniu do rozwiązań dostarczonych przez HybridJava.