Inspiracja , wiedza , realizacja
Jsystems

W przebudowie

Login



Java

Oracle

Linux

Android

PostgreSQL

Microsoft SQL Server

Stany decyzyjne

Data dodania: Jun 27, 2016
Data aktualizacji: Jun 27, 2016

Kod źródłowy z przykładami do tego rozdziału możesz pobrać pod adresem:

http://jsystems.pl/storage/spring/springflow2.zip


W poprzedniej części stworzyliśmy banalnie prosty przepływ z przejściami. W niniejszym będziemy rozwijać kod z poprzedniej części wzbogacając go o kilka elementów które pomogą nam ulepszyć program. Co chcemy osiągnąć:



Stany decyzyjne


Zaczynamy od zadania: „Dodać element który będzie sprawdzał czy użytkownik o takim emailu już jest zapisany do newslettera. Jeśli okaże się że owszem, to przekierowanie widoku informującego o tym.”


Do naszego wcześniej stworzonego DAO dodaję nową metodę, która z założenia ma sprawdzać czy użytkownik o podanym adresie email już istnieje czy jeszcze nie. Nie bawimy się tutaj w kurs baz danych, zrobiłem po prostu sprawdzanie czy podano mój email czy jakiś inny. Jeśli ktoś poda adres email klusiewicz@Jsystems.pl, metoda zwróci „true” informując o istnieniu takiego użytkownika.




Przejdźmy teraz do pliku konfiguracji przepływu. Przyjrzyjmy się linii 13. Wcześniej w przypadku zatwierdzenia formularza było tutaj przekierowanie do stanu „zapiszUzytkownika”, teraz jest przekierowanie do nowego stanu – „czyUserIstnienie”. Jest to stan decyzyjny. W zależności od sprawdzanych warunków, przepływ może pójść w całkiem różnych kierunkach. Nasz stan decyzyjny (linie 17-22) sprawdza czy użytkownik o podanym adresie email już istnieje czy jeszcze nie. Robi to z użyciem metody userExists naszego DAO (dao to zostało zdeklarowane jako bean w poprzednim rozdziale). Do metody userExists przekazujemy zawartość pola email z uzupełnianego w trakcie tego przepływu obiektu uzyszkodnik. W zależności od tego czy metoda zwróci true czy false, zostaniemy przekierowani albo do stanu „userIstnieje”, albo do stanu „zapiszUzytkownika”.

W przypadku gdyby okazało się że takiego użytkownika jeszcze nie było, to sprawa jest o tyle prosta że wystarczy przejść do zapisu obiektu. Jeśli jednak okazałoby się że mamy już użytkownika o takim adresie email, należy wyświetlić jakąś stronę informacyjną. Przyjrzymy się więc teraz liniom 24-26. Mamy tutaj kolejny stan widoku.




Na ten moment jako widok podałem „userIstniejeForm”. Wcześniej go nie tworzyliśmy, tymczasowo dodałem sobie taki wpis by cokolwiek tutaj było. Zaraz stworzymy warstwę widoku. Zauważ że tutaj też przekazuję do modelu obiekt uzyszkodnik (ten który uzupełniamy podczas przeplywu). Po co? Ponieważ będę chciał sięgnąć do jego zawartości w tym widoku – konkretnie do adresu email. W linii 25 pojawia nam się nowe zdarzenie – powrot. Zostanie ono wywołane znaną już konstrukcją kiedy ktoś kliknie na nowej podstronie informacyjnej link „powrót”. W takim przypadku zostanie przekierowany do stanu „newsletter” czyli naszego formularza.


Przejdźmy teraz do warstwy widoku. Stworzyłem wspomniany wcześniej plik „userIstniejeForm.jsp” i umieściłem w nim taką oto treść:




W zasadzie interesujące są tylko linie 10 i 12, bo tylko tam coś się dzieje ;)


W linii 10 wyświetlam email uzupelnianego podczas przepływu użytkownika, czyli bezpośrednio ten email który wstukaliśmy w formularzu (wyjaśnia się podawanie parametru model w nowym view-state). Linia 12 to znana już konstrukcja linka wywołującego akcję. Tym razem jest to akcja o nazwie „powrot” która wg zapisów w naszym pliku konfiguracji przepływu spowoduje powrót do formularza. Sprawdźmy więc działanie. Uzupełniam formularz i zatwierdzam.




Wywoływana w naszym stanie decyzyjnym metoda weryfikuje że użytkownik o podanym emailu już istnieje i powoduje przejście do stanu widoku "userIstnieje”. Przy okazji zwróć uwagę na pasek adresu. Cały czas widnieje tam adres „newsletter.do”!




Kliknięcie linka „Powrót” powoduje wywolanie akcji „powrot” i co za tym idzie powrót do formularza wypelniania danych:




Teraz działa to tak, że po wypełnieniu formularza wracamy do strony startowej: