Pomóż mi lepiej zrozumieć Struts2, sprawdzanie poprawności i działania stanowe

Question

Jak rozumiem, wystąpienia klasy działania Struts2 mogą (w przeciwieństwie do Struts1) być stanowe, ponieważ każdy GET lub POST dla akcji tworzy nową instancję klasy działania.

Widzę również, że istnieje norma idiom (wzorzec?) W celu zapewnienia form wejściowych (?): Ten sam .jsp służy jako widoku komponentu dwóch różnych działań, takich jak to:

<action name="showForm" class="defaultActionThatDoesNothingExceptReturnSuccess"> 
    <result name="success">inputForm.jsp</result> 
</action> 

<action name="validateAndProcessForm" class="realAction"> 
    <result name="input">inputForm.jsp</result> 
    <result name="success">formProcessed.jsp</result> 
</action> 

pierwsza akcja wyświetla tylko formularz, bez sprawdzania poprawności danych wejściowych lub przetwarzania. Postać w słupkach .jsp na działanie sekund:

<s:form action="validateAndProcessForm" method="post"> 

i tej drugiej akcji sprawdza poprawność zamieszczonych Pola/parametry, wracając „wejście”, jeśli wejścia formie są niepełne lub nieprawidłowe, a właściwie nazywając akcję klasa execute jeśli dane wejściowe są kompletne i poprawne, przetwarzając formularz i zwracając (np.) formProcessed.jsp, który wyświetla coś w rodzaju "dziękuję za wejście!".

Więc mamy tego rodzaju „płotu” idiom:

defaultAction-   -> realAction- 
      |   |  |  | 
      -> input.jsp- <---  -> success.jsp 

Odbywa się to tak, że wyświetlany jest pierwszy raz input.jsp, walidacje nie są nazywane (a więc błędy walidacji nie są widoczne), ale po kliknięciu przycisku przesyłania na tym jsp, "prawdziwa" czynność sprawdzi poprawność danych wejściowych, prawdopodobnie przekazując błędne dane zwrotne wywołujące błędne dane wejściowe, które będą wyświetlane przez input.jsp.

Co prowadzi nas z powrotem do działań stanowych, nie pojedynczych; ponieważ akcja ma charakter stanowy, a zatem nie jest udostępniana w GET lub POST, a każda instancja jest tworzona tylko dla tego GET lub POST, akcja nie ma możliwości sprawdzenia, czy dana sesja wielokrotnie "zdobyła" tę samą stronę. Więc poruszanie showForm.action będzie nigdy validate i czuło będzie zawsze sprawdzania poprawności (i pokazują błędy, jeśli parametry są nieważne), nawet jeśli które się po raz pierwszy dana sesja ma „GETted” tego adresu URL.

Z tego powodu potrzebujemy "słupka ogrodzeniowego": pierwsza operacja tylko po to, aby wyświetlić formularz, a druga do przechwycenia danych wejściowych.

Czy moje zrozumienie jest prawidłowe? Czy istnieje mniej rozwlekły sposób, aby to zrobić, aby nie sprawdzać poprawności danych wejściowych w początkowym GET, ale aby zweryfikować na POST, bez konieczności wykonywania dwóch działań dla każdego formularza?

Answer 1

Jest inny sposób wykonywania tego, co chcesz, bez płotu. Obiekt przechwytywania poprawności domyślnie nie uruchamia metody wprowadzania danych. Możesz więc zaktualizować plik struts.xml do następujących:

<action name="*MyForm" method="{1}" class="realAction"> 
    <result name="input">inputForm.jsp</result> 
    <result name="success">formProcessed.jsp</result> 
</action> 

Przy tej konfiguracji nie potrzebujesz w ogóle pustej akcji. Kiedy po raz pierwszy przejdziesz do formularza, poszedłeś do adresu URL "inputMyForm", a twoja akcja formularza wskazuje tylko "MyForm". {1} w bloku metod oznacza po prostu, że framework wywoła dowolną metodę pasującą do * z nazwy akcji. Jeśli * jest puste, domyślnie jest to metoda execute.Więc masz następujące rodzaje działań:

• inputMyForm pójdzie do sposobu wejścia() z klasy działania
• MyForm pójdzie do metody execute() z klasy działania
• executeMyForm pójdzie metody execute() z klasy działania
• customMethodNameMyForm pójdzie do sposobu customMethodName() z klasy działania

Ponieważ przechwytujących walidator wyklucza jakiekolwiek działania, przechodząc do metoda wprowadzania danych, możesz ustawić dowolną walidację dla tej akcji i będzie ją szukać tylko po przesłaniu formularza. Ponieważ za każdym razem, gdy przesyłasz formularz, przechodzi on do metody wykonywania, sprawdzanie poprawności nastąpi za każdym razem, gdy prześlesz formularz.

Ponadto, jeśli rozszerzasz klasę ActionSupport, ta klasa już definiuje metodę input(), więc nie musisz nawet zmieniać klasy akcji, aby to osiągnąć.

Answer 2

Można robić różne rzeczy, ale powiedzmy, że pozwalasz struts2 obsługiwać wszystkie żądania. Wszystko, co przechwytuje2, jest "akcją".

Nie przejmuj się GET lub POST to tylko dwie różne metody wysyłania danych do akcji, jeśli istnieją parametry (niezależnie od tego, czy są pobierane, czy ustawione), wówczas struts2 spróbuje umieścić te dane w klasie działań (zakładając, że istnieje). Jeśli istnieje metoda sprawdzania poprawności (lub poprawnie nazwany plik sprawdzania poprawności xml), sprawdzanie poprawności zostanie uruchomione po ustawieniu właściwości klasy. Następnie wywoływana jest metoda execute() dla klasy (zakładając, że istnieje klasa). Następnie zwykle renderowany jest jsp, który ma do dyspozycji wszystkie publiczne dane w metodzie akcji.

Wykonaj akcję "showForm" ...możesz zredukować xml do:

<action name="showForm"> 
    <result>inputForm.jsp</result> 
</action> 

Możesz zobaczyć, że nie musisz definiować klasy. Ponadto domyślnym wynikiem jest sukces, więc nie musimy o tym wspominać.

Kiedy myślimy o hmtl, myślimy kategoriami stron. Myśląc w krokach, które myślimy kategoriami działań, muszą one być tak skomplikowane, jak to konieczne. Oznacza to, że jeśli chcesz pokazać formularz, potrzebujesz akcji formularza pokazu, jeśli chcesz wyświetlić stronę, która używa danych formularza, potrzebujesz akcji "displayPage", która robi coś z danymi formularza.

Tak więc pomyśl o każdej czynności zaczynającej się od adresu URL> -----------> kończącej się na dacie powracania (zwykle renderującej jsp). Kreski są opcjonalnymi częściami, które możesz zdefiniować, ale jeśli nie, będą domyślnie dla Ciebie domyślne. Aby zobaczyć, jakie funkcje są ci dostarczone, musisz zajrzeć do pliku struts2-core-x.x.x.x.jar i wyświetlić zawartość pliku struts-default.xml, gdzie zdefiniowano "defaultStack". Każdy przechwytujący z kolei jest nazywany, wiedząc, co oferuje (a inne przechwytujące oferują), abyś wiedział, co wyjdzie z pudełka (nie zaglądałbym do nich zbyt głęboko, po prostu wiedz, że tam są, abyś wiedział na przykład że jeśli chcesz przesłać plik, prosty fakt, że interpreter "fileUpload" znajduje się w domyślnym stosie, powinien być wystarczającym wskaźnikiem, że musi być wbudowany mechanizm przesyłania plików. do formularza wejściowego Jest to prawdziwa akcja, która jest prosta, po tym jak nauczysz się definiować pakiety, akcje, domyślne akcje dla pakietu i być może globalnie i nauczyć się definiować przechwytywacz, powinieneś spojrzeć na wtyczki konwencji. To ułatwia życie!

Answer 3

Twoje pytanie ma sens. nasz wzór jest poprawny, jednak:

• jak Quaternion zaznaczył, że jest mało lub nie ma "gadatliwości". Twój pierwszy "showForm" jest fikcyjnym "mapowaniem akcji", jego klasa "nie rób nic" nie potrzebuje konkretnej definicji klasy (wystarczy domyślny ActionSupport).

• Istnieją inne możliwe wzory; niektórzy mogą preferować idiom, który wskazujesz (i ma długą historię - pamiętam, jak robiłem kilka stron CGI w ten sposób, wieki temu): używaj pojedynczego adresu URL (a więc pojedynczego mapowania akcji) dla dwóch "kroków" "(pokaż początkową formę i przetwórz formularz), zgadując wewnątrz metody działania (lub w walidatorze) bieżący krok, być może sprawdzając, czy jakiś parametr jest obecny (być może ukryte pole) lub, może, dyskryminując POST/GET. W Struts2 ogólnie wolę inną drogę.

BTW, nazywając działania Struts2 „stanowe” jest prawidłowy tylko wtedy, gdy undestand (ty, podobno), że „państwo” nie przetrwać wśród żądań.