Sławomir Czerwiński

Konteksty stanowią fundament Seam Framework. Bez nich nie byłoby stanowych komponentów, wstrzykiwania zależności czy integracji z JSF.

Ale może najpierw wyjaśnię, czym jest kontekst – jest to przestrzeń (pojemnik), w której znajdują się komponenty. No dobrze… wszystkie komponenty znajdują się przecież w kontenerze (np. JBoss Application Server). Więc po co jeszcze jakiś kontekst?

Różnica polega na tym, że w jednym kontenerze znajduje się cała hierarchia kontekstów:

• aplikacji (ang. application context),
• procesu biznesowego (ang. business process context),
• sesji (ang. session context),
• konwersacji (ang. conversation context),
• strony (ang. page context),
• zdarzenia (ang. event context),
• pseudokontekst bezstanowy (ang. stateless context).

Każdy kontekst ma inny czas istnienia i przeznaczony jest do komponentów o różnych zastosowaniach.

Kontekst aplikacji

Istnieje jeden dla każdej aplikacji. Tworzony jest w momencie rozmieszczenia aplikacji w kontenerze, a usuwany podczas jej kasowania.

W kontekście aplikacji umieszczane są wszystkie komponenty potrzebne przez cały czas – między innymi komponenty wbudowane Seam.

Kontekst procesu biznesowego

Długotrwałe procesy biznesowe omówię przy innej okazji. Wspomnę jedynie, że mają one zasięg większy niż pojedyncza sesja.

Kontekst sesji

Po połączeniu się z serwerem, dla klienta tworzona jest nowa sesja, która trwa aż do wygaśnięcia. Z każdą sesją związany jest jeden kontekst.

Odpowiednim miejscem dla komponentów takich jak tożsamość użytkownika (identity) jest właśnie kontekst sesyjny. Wspominałem już na ten temat w jednym z wcześniejszych wpisów.

Kontekst konwersacji

Konwersacja została stworzona specjalnie na potrzeby komponentów, których czas życia jest dłuższy niż jedna strona, ale krótszy niż cała sesja. Bardzo dobrym przykładem może być kreator nowego konta użytkownika, w którym kolejne strony zawierają różne informacje dotyczące samego konta, jego właściciela, preferowanej formy płatności itp.

Kontekst konwersacji jest tworzony i usuwany razem z samą konwersacją – poprzez odpowiednie adnotacje (@Begin i @End) lub z poziomu widoku (atrybut propagation lub odpowiednie znaczniki w plikach *.pages.xml).

Należy zaznaczyć, że konwersacje można zagnieżdżać, więc dla dowolnej sesji może w danej chwili istnieć cały stos konwersacji.

Kontekst strony

Kontekst strony jest nierozerwalnie związany z jednorazowym wyświetleniem strony. Jego usunięcie powoduje zmiana lub odświeżenie strony (czyli dowolne kolejne żądanie wysłane przez klienta).

W kontekście strony można umieszczać komponenty związane z jej zawartością lub sposobem wyświetlania.

Kontekst zdarzenia

Najkrócej istniejący kontekst Seam Framework związany jest z pojedynczym zdarzeniem – zaraz po zakończeniu obsługi zdarzenia, kontekst jest usuwany.

Wszelkie obserwatory przechowywane są właśnie w tym kontekście. Jest to też jedyne miejsce, z którego można dostać się do innych komponentów z tym zakresem widoczności (np. messages).

Pseudokontekst bezstanowy

Kontekst bezstanowy istnieje zawsze (bądź też nie istnieje wcale). Właściwie ciężko mówić o umieszczaniu w kontekście bezstanowych komponentów, a do tego właśnie on służy.

Komponent bezstanowy można wstrzyknąć do dowolnego komponentu, znajdującego się w dowolnym kontekście – przy czym stan wstrzykiwanego obiektu jest w tym wypadku niewiadomą.

Wstrzykiwanie zależności

Podczas wstrzykiwania, kontener wyszukuje właściwego komponentu w kolejnych kontekstach stanowych, zaczynając od najwęższego (chyba że wstrzykiwany obiekt jest bezstanowy). Jednak nie można wstrzyknąć komponentu z węższego kontekstu do komponentu z szerszego – nie da się oprzeć funkcjonowania całej konwersacji o jedno zdarzenie.

Przy najbliższej okazji dokładniej zajmę się tematem wstrzykiwania zależności. Pokażę jak pobierać komponenty z kontekstu, a czego nigdy nie należy robić.