Czy ktoś mógłby sie podzielić jakimiś materiałami albo własnymi
doświadczenia w tworzeniu profesjonalnych biznesowych aplikacji w JSF?

Chodzi mi o pewne niuanse.
Podczas tworzenia mojej aplikacji napotykam kilka znaków zapytania:
1. Jaki jest najlepszy sposób na przekazywanie parametrów między stronami?
2. Zasięgi beanów, czy należy za wszelką cenę starać się tworzyć beny
requestowe zamiast session - zarządzanie ich stanem.
3. Serializacja sesji.

Jak mi się coś jeszcze przypomni to dopiszę...


Ad. 1, 2
O ile strony są niezależne jest w miarę ok. Jest link, otwiera się strona i
możemy za pomocą valueChangeListenerów, actionListenerów, ... spokojnie
taką stroną zarządzać, zwłaszcza jeśli wykorzystujemy do tego jakąś ajaxowa
bibliotekę. Po każdej takiej operacji stan strony jest jednak
heremetyzowany w podpiętych pod nią backing bean'ach i dla przeglądarki
klienta nie wiele się zmienia.
URL w przeglądarce jest prosty (żadnych parametrów) gdyż formularze
wysyłane są metodą POST.

Systuacja jeszcze bardziej się komplikuje gdy mamy zaprogramować wizard
czyli ciąg kilku stron gdzie każda z nich zbiera jakieś informacje, które
ostatecznie są wykorzystane na ostatniej stronie takiego wizardu.

Tworząc taki wizard, tworzę dla każdej strony backing beana o zasięgu
request, czasem przedłuzając jego żywotność na 2-3 strony za pomocą
tomahawkowego t:saveState, gdyż nie chcę tworzyć beanu(ów) sesyjnych.

Wiem że np. w jboss seami jest zasięg conversation idealny do takich
zastosowań ale niestety używam zwykłego jsf'a z dodatkami.

Zasięg conversation nie rozwiązuje chyba jednak problemu kiedy ktoś wpisuje
nagle w przeglądarce bezpośredni link do np. 4 strony wizardu.
Jak wtedy ma sięzachować aplikacja?

Bez zabezpieczeń jest oczywiście błąd, gdyż strona nie ma jeszcze
wystarczająco informacji do jej poprawnego wyświetlenia.

W moim przypadku jest jeszcze gorzej gdyż taki GET zabija mi stan beanów
requestowych podtrzymywanych za pomocą t:saveState.

I ostatnie pytanie: Jak przeakzywać parametry przechodząćze straony na
stronę. Ja robię to tak że po kliknięciu na przycisk next ze strony A
wywoływana jest akcja aBean.go2B(), która ustawia potrzebne właściwośći w
bBean np. bBean.setRequiredParam(param), po czym nawigation handler
przekeirowuje do strony B która ma pod spodem bBean'a.



Pewnie trochę naplątałem...
Chciałbym się do dowiedzieć jak wy zarządzacie wizardami w plikacjach jsf


Ad. 3
I trochę z innej beczki pytanie:

Od kiedy dodałem logowanie do managed beanow, dostaje w tomcacie taki
komunikat:

SEVERE: IOException while loading persisted sessions:
java.io.WriteAbortedException: writing aborted;
java.io.NotSerializableException: org.slf4j.impl.Log4jLoggerAdapter
java.io.WriteAbortedException: writing aborted;
java.io.NotSerializableException: org.slf4j.impl.Log4jLoggerAdapter
at java.io.ObjectInputStream.readObject0(Unknown Source)


Co z tym można zrobić?

Rafal wrote:

> Ad. 1, 2

Używaj beanów o zasięgu session - po to właśnie są - obiekty używane w
ramach obsługi jednego użytkownika aplikacji.

Ale wiąże się z tym taki problem, że zasięg session jest zazwyczaj za
szeroki - dla jakiegoś "wizarda" lepiej byłoby użyć zasięgu "conversation"
(o ile jest dostępny).

Niestety, nie ma póki co lepszego rozwiązania: trzeba używać beanów
sesyjnych i uważać, żeby nie były używane jako beany "globalne" (w tym
sensie, że panuje do nich swobodny dostęp z różnych miejsc aplikacji).

Rafal pisze:

> Systuacja jeszcze bardziej się komplikuje gdy mamy zaprogramować wizard
> czyli ciąg kilku stron gdzie każda z nich zbiera jakieś informacje,
które
> ostatecznie są wykorzystane na ostatniej stronie takiego wizardu.
>
> Tworząc taki wizard, tworzę dla każdej strony backing beana o zasięgu
> request, czasem przedłuzając jego żywotność na 2-3 strony za pomocą
> tomahawkowego t:saveState, gdyż nie chcę tworzyć beanu(ów) sesyjnych.
>
> Wiem że np. w jboss seami jest zasięg conversation idealny do takich
> zastosowań ale niestety używam zwykłego jsf'a z dodatkami

Zasieg sesji powoduje to, ze nie mozna otworzyc np. 2 wizardow w 2
roznych oknach bo beda sobie nadpisywaly dane. A przynajmniej trzeba sie
troche z tym nagimnastykowac.

Dlatego idealnie pasuja tu Seam-owe konwersacje.


> Zasięg conversation nie rozwiązuje chyba jednak problemu kiedy ktoś
wpisuje
> nagle w przeglądarce bezpośredni link do np. 4 strony wizardu.
> Jak wtedy ma sięzachować aplikacja?


Oczywiscie, ze rozwiazuje, mozna tworzyc nowa konwersacje zadaniami GET,
przekazywac parametry i je pobierac (@RequestParameter), tworzyc
przyjazne linki itp.
Wiecej w dokumentacji Seam'a :)

Pozdrawiam
Michał Flasiński