Różnice między akcją a actionListener

ActionListener

Użyj actionListener Jeśli chcesz mieć hook zanim zostanie wykonana prawdziwa akcja biznesowa, np. aby ją zalogować i / lub ustawić dodatkową właściwość (przez <f:setPropertyActionListener>), i / lub mieć dostęp do komponentu, który wywołał akcję (który jest dostępny przez ActionEvent argument). Tak więc, wyłącznie w celu przygotowania, zanim zostanie wywołana prawdziwa akcja biznesowa.

Metoda actionListener ma domyślnie następujący podpis:

import javax.faces.event.ActionEvent;
// ...

public void actionListener(ActionEvent event) {
    // ...
}

I należy ją zadeklarować w następujący sposób, bez nawiasów metody:

<h:commandXxx ... actionListener="#{bean.actionListener}" />

Zauważ, że nie możesz przekazać dodatkowych argumentów przez EL 2.2. Można jednak całkowicie nadpisać argument ActionEvent, przekazując i podając argumenty niestandardowe. Ważne są następujące przykłady:

<h:commandXxx ... actionListener="#{bean.methodWithoutArguments()}" />
<h:commandXxx ... actionListener="#{bean.methodWithOneArgument(arg1)}" />
<h:commandXxx ... actionListener="#{bean.methodWithTwoArguments(arg1, arg2)}" />

public void methodWithoutArguments() {}
public void methodWithOneArgument(Object arg1) {}
public void methodWithTwoArguments(Object arg1, Object arg2) {}

Zwróć uwagę na znaczenie nawiasów w wyrażeniu metody argumentless. Gdyby ich nie było, JSF nadal oczekiwałby metody z argumentem ActionEvent.

Jeśli jesteś na EL 2.2+, wtedy możesz zadeklarować wiele metod słuchacza akcji za pomocą <f:actionListener binding>.

<h:commandXxx ... actionListener="#{bean.actionListener1}">
    <f:actionListener binding="#{bean.actionListener2()}" />
    <f:actionListener binding="#{bean.actionListener3()}" />
</h:commandXxx>

public void actionListener1(ActionEvent event) {}
public void actionListener2() {}
public void actionListener3() {}

Zwróć uwagę na znaczenie nawiasów w atrybucie binding. Gdyby ich nie było, EL błędnie rzuciłby javax.el.PropertyNotFoundException: Property 'actionListener1' not found on type com.example.Bean, ponieważ atrybut binding jest domyślnie interpretowany jako wyrażenie wartości, a nie jako wyrażenie metody. Dodanie nawiasów stylów EL 2.2+ w przejrzysty sposób zamienia wyrażenie wartości w wyrażenie metody. Zobacz także a. o. Dlaczego jestem w stanie związać do dowolnej metody, jeśli nie jest obsługiwana przez JSF?

Akcja

Użyj action jeśli chcesz wykonać akcję biznesową i w razie potrzeby obsłuż nawigację. Metoda action Może (a więc nie musi) zwracać String, która będzie używana jako wynik przypadku nawigacyjnego (widok docelowy). Zwracana wartość null lub void pozwoli powrócić do tej samej strony i utrzymać bieżący zakres widoku. Zwracana wartość pustego łańcucha lub tego samego identyfikatora widoku będzie również powrócić do tej samej strony, ale odtworzyć zakres widoku, a tym samym zniszczyć wszystkie aktualnie aktywne fasole zakresu widoku i, jeśli dotyczy, odtworzyć je.

Metoda action Może być dowolna MethodExpression, również te, które używają argumentów EL 2.2, takich jak poniżej:

<h:commandXxx value="submit" action="#{bean.edit(item)}" />

Tą metodą:

public void edit(Item item) {
    // ...
}

Zauważ, że gdy twoja metoda akcji zwraca wyłącznie łańcuch znaków, możesz również dokładnie określić ten łańcuch w atrybucie action. Tak więc jest to całkowicie

<h:commandLink value="Go to next page" action="#{bean.goToNextpage}" />

Z tą bezsensowną metodą zwracającą zakodowany ciąg znaków:

public String goToNextpage() {
    return "nextpage";
}

Zamiast tego, po prostu umieść ten zakodowany łańcuch bezpośrednio w atrybucie:

<h:commandLink value="Go to next page" action="nextpage" />

Proszę zauważyć, że to z kolei wskazuje na zły projekt: nawigowanie pocztą. To nie jest przyjazne dla użytkownika ani SEO. To wszystko jest wyjaśnione w Kiedy powinienem używać h: outputLink zamiast h:commandLink? i ma być rozwiązane jako

<h:link value="Go to next page" outcome="nextpage" />

Zobacz także jak poruszać się w JSF? Jak spraw, aby adres URL odzwierciedlał bieżącą stronę (a nie poprzednią) .

F: Ajax listener

Od JSF 2.x jest trzecia droga, <f:ajax listener>.

<h:commandXxx ...>
    <f:ajax listener="#{bean.ajaxListener}" />
</h:commandXxx>

Metoda ajaxListener ma domyślnie następujący podpis:

import javax.faces.event.AjaxBehaviorEvent;
// ...

public void ajaxListener(AjaxBehaviorEvent event) {
    // ...
}

W Mojarrze argument AjaxBehaviorEvent jest opcjonalny, poniżej działa jako dobry.

public void ajaxListener() {
    // ...
}

<h:commandXxx ...>
    <f:ajax execute="@form" listener="#{bean.ajaxListener()}" render="@form" />
</h:commandXxx>

Ajax nie są tak naprawdę przydatne w komponentach poleceń. Są bardziej przydatne przy wprowadzaniu i wyborze komponentów <h:inputXxx>/<h:selectXxx>. W komponentach polecenia, po prostu trzymaj się action i/lub actionListener dla jasności i lepszego samodokumentowania kodu. Ponadto, podobnie jak actionListener, f:ajax listener nie obsługuje zwracania wyniku nawigacji.

<h:commandXxx ... action="#{bean.action}">
    <f:ajax execute="@form" render="@form" />
</h:commandXxx>

Rozkaz wywołania

actionListener S są zawsze wywoływane przed action w tej samej kolejności, w jakiej zostały zadeklarowane w widoku i dołączone do komponentu. {[45] } jest zawsze wywoływany przed {[85] } jakąkolwiek akcją. Tak więc, następujący przykład:

<h:commandButton value="submit" actionListener="#{bean.actionListener}" action="#{bean.action}">
    <f:actionListener type="com.example.ActionListenerType" />
    <f:actionListener binding="#{bean.actionListenerBinding()}" />
    <f:setPropertyActionListener target="#{bean.property}" value="some" />
    <f:ajax listener="#{bean.ajaxListener}" />
</h:commandButton>

Wywoła metody w następujący sposób zamówienie:

1. Bean#ajaxListener()
2. Bean#actionListener()
3. ActionListenerType#processAction()
4. Bean#actionListenerBinding()
5. Bean#setProperty()
6. Bean#action()

Obsługa wyjątków

actionListener obsługuje specjalny wyjątek: AbortProcessingException. Jeśli ten wyjątek zostanie wyrzucony z metody actionListener, to JSF pominie Pozostałe detektory akcji i metodę akcji i rozpocznie renderowanie odpowiedzi bezpośrednio. Nie zobaczysz strony błędu/wyjątku, jednak JSF ją zarejestruje. To będzie również domyślnie wykonywane, gdy jakikolwiek inny wyjątek jest wyrzucany z actionListener. Tak więc, jeśli zamierzasz zablokować stronę przez stronę błędu w wyniku wyjątku biznesowego, zdecydowanie powinieneś wykonywać zadanie w metodzie action.

Jeśli jedynym powodem użycia metody actionListener jest powrót metody void do tej samej strony, to jest to złe. Metody action mogą również doskonale zwracać void, W przeciwieństwie do tego, w co niektóre IDE pozwalają ci wierzyć poprzez walidację EL. Zauważ, że przykłady primefaces showcase są zaśmiecone takimi przykładami actionListener wszędzie. To jest rzeczywiście złe. Nie używaj tego jako wymówki, żeby zrobić to sam.

W żądaniach ajax potrzebna jest jednak Specjalna obsługa wyjątków. Jest to niezależnie od tego, czy używasz listener atrybutu <f:ajax>, czy nie. Aby uzyskać wyjaśnienie i przykład, przejdź do obsługi wyjątków w żądaniach JSF ajax.