JSF - czyli jak ja to rozumiem...

JavaServer Faces - wstęp
Od jakiegoś czasu interesowałem się technologią JSF, nigdy jednak nie wystarczyło mi czasu i motywacji by zająć się ją na poważnie. Teraz się to zmieniło - mam już motywację (nowa praca :) ) - a czas chcę i muszę zorganizować, nic więc nie stoi na przeszkodzie by zacząć przekopywać internet, książki i dokumentacje w poszukiwaniu wartościowych informacji.

Postanowiłem, że będę zamieszczał tu rzeczy, które wydają mi się szczególnie ciekawe i godne zapamiętania. Wiem, że wielokrotnie mogę się mylić w rozumieniu nowych dla mnie zagadnień i mechanizmów.

Wobec tego zwracam się z prośbą do wszystkich odwiedzających tę stronę o uwagi krytyczne i wytykanie mi wszystkich zauważonych nieścisłości i pomyłek.

Java Server Faces - wariacje na temat... czyli pierwsze refleksje
Podczas kilkuletniego obcowania z J2EE wyrobiłem sobie zdanie, że tworzenie warstwy prezentacji jest słabym punktem całego procesu projektowania i implementacji tego typu aplikacji. Tworzenie interfejsów użytkownika zawsze kojarzyło mi się z czymś żmudnym i nie do końca zrozumiałym. Chociaż pojawiły się technologie wspomagające takie jak tagi JSTL, czy biblioteka Tiles to ciągle nie rozwiązywały one wszystkich problemów. Mam wrażenie że chociaż ewoluowały w kierunku ciągłych ulepszeń to jednak nie były rozwiązaniami kompleksowymi. Budowanie interfejsów ciągle wiązało się z uciążliwym iterowaniem list, wymagało mieszania logiki aplikacji z elementami prezentacyjnymi. Mam wrażenie że sytuację radykalnie zmieniło pojawienie się technologii JavaServer Faces.

Cechy JSF które wydają mi się godne zauważenia i wyróżniają ten framework spośród innych to:

• Przede wszystkim JSF jest standardem, który zapewne niedługo włączony zostanie do specyfikacji JEE.
  
• JSF jest frameworkiem komponentowym. Istnieje utrzymywany ścisły związek pomiędzy komponentami interfejsu użytkownika a komponentami zarządzanymi przez framework, których zadaniem jest dostarczanie danych i reagowaniem na zdarzenia generowane przez użytkownika.
  Wszystkie komponenty implementują ten sam interfejs, więc w wielu przypadkach obsługa ich zachowania odbywa się w sposób bardzo do siebie zbliżony. Skraca to czas potrzebny na opanowanie zasad posługiwania się technologią.
  
• Wszystkie elementy ułożone na stronie układają się w określoną hierarchię. Istnieje możliwość programowego wpływania na tą hierarchię.
  
• Tworzenie intefejsu użytkownika nie wymaga zrywania z obiektowym paradygmatem tworzenia aplikacji. Przy obsłudze zdarzeń ciągle operujemy na obiektach, framework zdejmuje z nas obowiązek przesyłania parametrów w postaci tekstowej.
  
• JSF wprowadza znany z aplikacji desktopowych model obsługi zdarzeń.
  
• Mechanizmy frameworka dbają o to, by zapamiętywać stan komponentu pomiędzy różnymi żądaniami nadsyłanymi przez klienta.
• Architektura JSF jest oparta o dobrze znane i wielokrotnie sprawdzone w praktyce wzorce projektowe takie jak: MVC, Observer, Composite.
  
• Konfiguracja jest jasna, zgromadzona w plikach xml.
• Osadzanie komponentów na stronie odbywa się w sposób deklaratywny, nie wymaga mieszania logiki z elementami odpowiedzialnymi za prezentację.
• Framework dostarcza pokaźną bibliotekę komponentów interfejsu użytkownika renderujące określone struktury danych.
  
• Wraz z frameworkiem dostarczane są obiekty pomocnicze takie jak renderery, walidatory poprawności danych.
• Framework dostarcza mechanizmów przetwarzania wielokrokowych formularzy, walidację danych, konwersję typów, obsługę zdarzeń,.
  

Różnica pomiędzy manage bean i backing bean
Technologia JSF wprowadza kilka nowych pojęć - te, których zrozumienie sprawiło mi trochę kłopotu to "managed bean" i "backing bean".

Na początek "backing bean". Jest to komponent, który w architekturze MVC, o którą oparty jest JSF ma pełnić rolę warstwy modelu i stanowić punkt styku pomiędzy warstwą prezentacji i biznesową. Ma on delegować żądania klienta do niższych warstw aplikacji. Jest on skojarzony z odpowiadającym mu komponentem UI (User Interface) używanym na stronie. Definiuje skojarzone z nim właściwości i metody stanowiące o logice jego zachowania. Dzięki nim występuje całkowita separacja logiki od definicji komponentu interfejsu użytkownika.

Czym wobec tego jest "managed bean" ?

Różnica pomiędzy nimi jest bardzo subtelna, podjąłem nawet próbę jej odkrycia. Niestety nie znalazłem nic co by całkowicie mnie przekonało, ale na jednym z forów trafiłem na ciekawą dyskusję, a niewątpliwie jej najciekawsze zdanie brzmi:

"managed beans are instances of backing beans which are made available to the JSF pages by defining them in the faces-config.xml"

Myślę że na chwilę obecną, należy przyjąć ją za całkiem rozsądną...

Etapy przetwarzania żądania przez framework JSF
W przetwarzaniu żądania można wyróżnić kilka faz:

• Restore View - etap tworzenia drzewa komponentów skojarzonych z żądanym zasobem (stroną). W przypadku gdy w obrębie danej sesji użytkownika drzewo było już tworzone, framework w tej fazie odtwarza pierwotny stan komponentów.
  
• Apply Request Value - w przypadku gdy drzewo zostało odtworzone, w tym etapie następuje uaktualnienie wartości komponentów. Następuje sprawdzenie czy w obiekcie żądania (request) nie znajdują się nowsze wartości elementów komponentu UI, jeśli istnieją, zostają one uaktualnione.
  
• Process Validations - w tej fazie przetwarzania uruchomione zostają validatory poprawności skojarzone z elementami komponentu UI. Sprawdzana jest kompletność i poprawność wartości pól.
  
• Update Model Values - w tym etapie przetwarzania komponent interfejsu użytkownika sprawdza i uwspólnia model danych ze skojarzonym z nim beanem.
  
• Invoke Application - w tej fazie obsługiwane są wszystkie skolejkowane zdarzenia.
  
• Render Response - po uwzględnieniu wszystkich zmian jakie zaszły przy przetwarzaniu żądania tworzone jest nowe drzewo komponentów i trwale jest ono kojarzone z określoną stroną jsp.