Kolejka zdarzeń JSF ajax nie działa w przypadku zdarzenia akcji po zmianie zdarzenia

Question

Obsługiwana funkcja JSF 2.x sekwencyjnego przetwarzania wielu zdarzeń ajaxowych nie działa dla mnie. Mam następujący scenariusz:

1. h: inputText (zmiana)

   <h:inputText id="consumption_input" 
       value="#{cc.attrs.consumptionInfo.consumption}"> 
       <f:ajax 
       render="#{cc.attrs.outerRenderString}" 
       event="change" listener="#{cc.handleAjaxRequest}" /> 
   </h:inputText> 
   

2. h: CommandButton (DZIAŁANIE)

   <h:commandButton 
       id="startComparisonButton" 
       action="#{rateComparisonBean.startRateComparison()}" 
       value="#{bundle.rateResultOverview_startComparison}"> 
       <!-- This is to avoid mixed requests, ajax and full requests --> 
        <f:ajax render="@form"/> 
       </h:commandButton> 
   

Wydarzenia z obu pierwiastków są obsługiwane poprawnie, jeśli zostanie uruchomione we własnym zakresie.

Problem występuje, gdy oba zdarzenia są wywoływane w ciągu jednego kliknięcia (Wprowadź wartość w polu tekstowym, a następnie kliknij przycisk). Spodziewałem się, że doprowadzi to do synchronizacji dwóch żądań ajaxowych (CHANGE-TextField i ACTION-commandButton).

Niestety, istnieje tylko jedno żądanie Ajax (Change-TextField), drugie wydarzenie wydaje się być całkowicie utracone.

już zapewnione, że wszystkie warunki wstępne dla H: CommandButton pełne są wypełnione, jak wskazano tutaj: commandButton/commandLink/ajax action/listener method not invoked or input value not updated

Byłbym wdzięczny dostać żadnych wskazówek, jak rozwiązać ten problem.

Środowisko: GlassFish 3, Mojarra 2.1.3-FCS

Answer 1

Połączenia JSF AJAX są asynchroniczne. Wysłanie jednego żądania AJAX, w tym przypadku wygenerowanego przez zdarzenie <h:inputText>onchange, nie zatrzymuje JavaScipt, aby kontynuować jego wykonywanie iw takim przypadku wywołać kliknięcie przycisku przesyłania, które z kolei wywołuje kolejne żądanie AJAX. Mimo to, żądania AJAX są naprawdę w kolejce do klienta, aby były przetwarzane w kolejności, w jakiej zostały wysłane, co jest gwarantowane przez JSF 2.0 specification, rozdział 13.3.2.

Poniżej jest mój przypadek testowy:

Widok:

<h:form id="form"> 
    <h:inputText id="text" value="#{q16363737Bean.text1}"> 
     <f:ajax render="text2" event="change" listener="#{q16363737Bean.ajaxListenerText}"/> 
    </h:inputText> 
    <h:commandButton id="button" action="#{q16363737Bean.actionButton}" value="Submit"> 
     <f:ajax render="text1 text3" listener="#{q16363737Bean.ajaxListenerButton}"/> 
    </h:commandButton> 
    <br/> 
    <h:outputText id="text1" value="Text 1: #{q16363737Bean.text1}."/> 
    <h:outputText id="text2" value="Text 2: #{q16363737Bean.text2}."/> 
    <h:outputText id="text3" value="Text 3: #{q16363737Bean.text3}."/> 
</h:form> 

Fasola:

@ManagedBean 
@ViewScoped 
public class Q16363737Bean implements Serializable { 

    private String text1 = "I'm text 1";//getter + setter 
    private String text2 = "I'm text 2";//getter + setter 
    private String text3 = "I'm text 3";//getter + setter 

    public void ajaxListenerText(AjaxBehaviorEvent abe) { 
     text2 = "I was modified after inputText AJAX call"; 
    } 

    public void ajaxListenerButton(AjaxBehaviorEvent abe) { 
     text1 = "I was modified after AJAX listener call of commandButton"; 
    } 

    public void actionButton() { 
     text3 = "I was modified after commandButton AJAX call"; 
    } 

} 

---

Po zbadaniu pytanie na jakiś czas I rzeczywiście zorientowali się, że bardzo rzadko wywołanie AJAX przycisku polecenia zostało połknięte d nie wykonano aktualizacji interfejsu użytkownika. Wygląda na to, że gdzieś powinny być jakieś warunki wyścigowe. Jest to świetne pytanie i należy je dalej zbadać.

To prawdopodobnie nie jest odpowiedź (choć początkowo sądziłem, że tak jest), ale propozycja dla przypadku testowego. I pomimo tego, że miałem do czynienia z tym zachowaniem bardzo rzadko, jest to rzeczywisty przypadek użyciai warto w pełni zrozumieć, co się dzieje.

Answer 2

Najpierw dziękuję za szybką i wyrafinowaną odpowiedź.

Drugi test od zera wskazał, że zdarzenia ajax są poprawnie ustawione w kolejce.

Tak więc ponownie sprawdziłem bardziej złożony scenariusz opisany powyżej. Przyczyna pominiętych szwów zdarzeń jest związana z naszą "zajętą ​​nakładką". Pomyśl o tym jako o skrypcie JavaScript, który wyłącza elementy formularza i nakłada nakładkę podczas długotrwałych żądań ajaxów. Odbywa się to poprzez oddzwonienie z jsf.ajax.addOnEvent.

W każdym razie, nawet wyłączamy niektóre kontrolki, po "powodzeniu" formularz jest w prawidłowym stanie, a drugie zdarzenie może zostać obsłużone.

Obecnie zakładam, że przycisk "tymczasowo" wyłączony narusza powiązane zdarzenie akcji, które należy wykonać później.

Obecnie analizujemy problem, a wynik końcowy zostanie opublikowany najszybciej jak najszybciej.