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 id
w 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.xml
plik 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-param
w web.xml
nazwie javax.faces.SEPARATOR_CHAR
i 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, @ViewScoped
aby włączyć zakres konwersacji, bez kłopotania się wszystkimi sposobami przechowywania danych w kolejnych (konwersacyjnych) żądaniach. @ViewScoped
Fasola 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. @ViewScoped
Nie 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ż: