MyFaces Tomahawk
  1. MyFaces Tomahawk
  2. TOMAHAWK-717

Tabbed Pane: dataModel inside tabs is not updated when switching between tabs and coming back

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.3, 1.1.6
    • Fix Version/s: 1.1.7
    • Component/s: Tabbed Pane
    • Labels:
      None

      Description

      I have worked several times with the tabbed pane component, but never got aware of this bug.

      There is a dataTable inside one tab and some new values were put in some input components. After switching to another tab and coming back, the values are gone and only the "old" ones are rendered out. This bug seems to be actual since 1.1.3 and before.

        Activity

        Hide
        Leonardo Uribe added a comment -

        added this property to AbstractHtmlPanelTabbedPane

        /**

        • Define if the process validation and update model phases
        • should be executed before change between tabs, when
        • serverSideTabSwitch = true (if is false, the switch
        • is done by other way so this property does not have any
        • effect).
        • Note that if this property is set as false, only a tab
        • change is done if all input fields inside the form are valid
        • (including input components outside this panel).
        • By default is true, so both phases are not executed.
        • @JSFProperty
        • defaultValue = "true"
          */
          public abstract boolean isImmediateTabChange();
        Show
        Leonardo Uribe added a comment - added this property to AbstractHtmlPanelTabbedPane /** Define if the process validation and update model phases should be executed before change between tabs, when serverSideTabSwitch = true (if is false, the switch is done by other way so this property does not have any effect). Note that if this property is set as false, only a tab change is done if all input fields inside the form are valid (including input components outside this panel). By default is true, so both phases are not executed. @JSFProperty defaultValue = "true" */ public abstract boolean isImmediateTabChange();
        Hide
        Leonardo Uribe added a comment -

        This issue is the same of TOMAHAWK-153, so that issue was closed as duplicated.

        The problem can be seen more cleary when you compare TabChangeListener and TabChangeEvent with ActionListener and ActionEvent. In the bottom the main difference is that TabChange trigger an action inside the current page (change tab), Action could trigger an action to the same page or others (handle navigation).

        For each Tab in the TabbedPane, a button is rendered on top that submit the form (like h:commandButton). Suppose a user click on that button wanting to change the tab. When decode method is called for TabbedPane, a TabChangeEvent if queued, indicating the relative data. Then on broadcast method if a TabChangeEvent is detected, it is delivered to the registered TabChangeListeners and go to render response phase.

        By default ALL TabChangeEvents are set activate on apply request values phase, in this way:

        public TabChangeEvent(UIComponent component, int oldTabIndex, int newTabIndex)

        { super(component); _oldTabIndex = oldTabIndex; _newTabIndex = newTabIndex; setPhaseId(PhaseId.APPLY_REQUEST_VALUES); }

        This is equivalent to a component like h:commandButton with immediate="true". The code is done on UICommand like this:

        public void queueEvent(FacesEvent event)
        {
        if (event != null && event instanceof ActionEvent)
        {
        if (isImmediate())

        { event.setPhaseId(PhaseId.APPLY_REQUEST_VALUES); }

        else

        { event.setPhaseId(PhaseId.INVOKE_APPLICATION); }

        }
        super.queueEvent(event);
        }

        Instead of write the phaseId inside the constructor, it should be better doing the same as UICommand, creating a property like immediateTabChange by default "true" to not break the old behavior.

        I think that the change presented here (option 2 of Zdenek proposal, but written in more precise words) is the correct approach for handle this issue. So I'll apply it and close this issue.

        Show
        Leonardo Uribe added a comment - This issue is the same of TOMAHAWK-153 , so that issue was closed as duplicated. The problem can be seen more cleary when you compare TabChangeListener and TabChangeEvent with ActionListener and ActionEvent. In the bottom the main difference is that TabChange trigger an action inside the current page (change tab), Action could trigger an action to the same page or others (handle navigation). For each Tab in the TabbedPane, a button is rendered on top that submit the form (like h:commandButton). Suppose a user click on that button wanting to change the tab. When decode method is called for TabbedPane, a TabChangeEvent if queued, indicating the relative data. Then on broadcast method if a TabChangeEvent is detected, it is delivered to the registered TabChangeListeners and go to render response phase. By default ALL TabChangeEvents are set activate on apply request values phase, in this way: public TabChangeEvent(UIComponent component, int oldTabIndex, int newTabIndex) { super(component); _oldTabIndex = oldTabIndex; _newTabIndex = newTabIndex; setPhaseId(PhaseId.APPLY_REQUEST_VALUES); } This is equivalent to a component like h:commandButton with immediate="true". The code is done on UICommand like this: public void queueEvent(FacesEvent event) { if (event != null && event instanceof ActionEvent) { if (isImmediate()) { event.setPhaseId(PhaseId.APPLY_REQUEST_VALUES); } else { event.setPhaseId(PhaseId.INVOKE_APPLICATION); } } super.queueEvent(event); } Instead of write the phaseId inside the constructor, it should be better doing the same as UICommand, creating a property like immediateTabChange by default "true" to not break the old behavior. I think that the change presented here (option 2 of Zdenek proposal, but written in more precise words) is the correct approach for handle this issue. So I'll apply it and close this issue.
        Hide
        Zdenek Sochor added a comment -

        Hi,
        when using serverSideSwitch changing tab IS handled like immediate action. Relevant code in org.apache.myfaces.custom.tabbedpane package:

        HtmlTabbedPaneRenderer:
        method: public void decode(FacesContext facesContext, UIComponent uiComponent)
        call: tabbedPane.queueEvent(new TabChangeEvent(tabbedPane, tabbedPane.getSelectedIndex(), tabIdx));

        HtmlPanelTabbedPane
        method: public void broadcast(FacesEvent event) throws AbortProcessingException
        call:
        if (event instanceof TabChangeEvent)
        {
        TabChangeEvent tabChangeEvent = (TabChangeEvent)event;
        if (tabChangeEvent.getComponent() == this)

        { setSelectedIndex(tabChangeEvent.getNewTabIndex()); getFacesContext().renderResponse(); }

        }

        This event if fired ONLY when using serverSideSwitch, clientSideSwitch is using other name in parameter sent in request's map.

        When the event is fired, a call to rederResponse() makse MyFaces skip "update model values" phase, so the model is NOT updated.

        I see two possible remedies (doing the same):
        1. adding new parameter, which would enable partial model update (note that you get only partial info from just 1 tab of whole panel), defaulting to FALSE to preserve current behaviour
        2. adding new parameter, which would flag switching tabs as immediate, defaulting to TRUE to preserve current behaviour

        As for updating bounded model properties from outside components, they are updated in apply request values phase when decoded.

        Regards,
        Zdenek

        Show
        Zdenek Sochor added a comment - Hi, when using serverSideSwitch changing tab IS handled like immediate action. Relevant code in org.apache.myfaces.custom.tabbedpane package: HtmlTabbedPaneRenderer: method: public void decode(FacesContext facesContext, UIComponent uiComponent) call: tabbedPane.queueEvent(new TabChangeEvent(tabbedPane, tabbedPane.getSelectedIndex(), tabIdx)); HtmlPanelTabbedPane method: public void broadcast(FacesEvent event) throws AbortProcessingException call: if (event instanceof TabChangeEvent) { TabChangeEvent tabChangeEvent = (TabChangeEvent)event; if (tabChangeEvent.getComponent() == this) { setSelectedIndex(tabChangeEvent.getNewTabIndex()); getFacesContext().renderResponse(); } } This event if fired ONLY when using serverSideSwitch, clientSideSwitch is using other name in parameter sent in request's map. When the event is fired, a call to rederResponse() makse MyFaces skip "update model values" phase, so the model is NOT updated. I see two possible remedies (doing the same): 1. adding new parameter, which would enable partial model update (note that you get only partial info from just 1 tab of whole panel), defaulting to FALSE to preserve current behaviour 2. adding new parameter, which would flag switching tabs as immediate, defaulting to TRUE to preserve current behaviour As for updating bounded model properties from outside components, they are updated in apply request values phase when decoded. Regards, Zdenek
        Hide
        Paul Spencer added a comment -

        Update version list per Christian's comment

        Show
        Paul Spencer added a comment - Update version list per Christian's comment
        Hide
        Christian Koelle added a comment -

        I can confirm that this bug exists.

        It can be reproduced with the MyFaces-Simple-Demo-Application V. 1.1.6 on Tomcat 5.5.20 by doing the following:

        a.) Amend the content of the server-side-switched tab1 in the demo's TabbedPane.jsp to the the following, i.e. a a dataTable:

        <t:panelTab id="tab1" label="#

        {example_messages['tabbed_tab1']}

        " rendered="#

        {tabbedPaneBean.tab1Visible}

        ">
        <t:dataTable
        headerClass="myTableHeader"
        rowClasses="myTableRow1,myTableRow2"
        var="r"
        preserveDataModel="false"
        preserveRowStates="false"
        preserveSort="false"
        value="#

        {tabbedPaneBean.testBeans}

        ">

        <h:column>
        <f:facet name="header">
        <h:outputText
        value="--Header 1 --" />
        </f:facet>
        <t:inputText
        id="inputField002"
        value="#

        {r.s1}

        " />
        </h:column>

        <h:column>
        <f:facet name="header">
        <h:outputText
        value="--Header 2 --" />
        </f:facet>
        <t:inputText
        id="inputField001"
        value="#

        {r.s2}

        " />
        </h:column>
        </t:dataTable>

        b.) Add a TestBean to the application:

        pulbic class TestBean implements Serializable

        { private String _s1; private String _s2; // + getter and setter }

        c.) Extend the TabbedPaneBean with one property holding a list of TestBeans:

        private List<TestBean> testBeans;
        // + getter and setter

        d.) Initialise the property testBeans, with a few objects, e. g. by adding a default contructor containing the following lines:

        this.testBeans = new ArrayList<TestBean>();
        this.testBeans.add(new TestBean());
        this.testBeans.add(new TestBean());

        There will be two table rows @ 2 input fields on the the tabbedPane-demopage after this amendment. Data entered into it, will be lost on Tab-change, contrary to the input fields outside of the <t:dataTable>.

        ####################

        As far as I could spent time to debug this, I can say that after the Apply-Request-Values-Phase (i. e. processDecodes) the UIcomponent (UIInput), which loses the entered values holds the submitted value in the attribue "_submittedValue" but somehow afterwards, the value will not be written into the bound bean model property.

        Somehow it appears that the tabswitching has some kind of immediate-alike behaviour, i. e. if you switch tabs, all fields of TabbedPane.jsp which are to be validated, will not be validated, contrary to what's happening when you use the already provided "Common submit button".

        It is interesting, that entered data will be correctly written to the bound model properties, if you use UIInput-components outside of a <t:dataTable> as already provided within the demo application.

        Please let me know, if you need more information on this or if you cannot reproduce it with the given information.

        Regards and thanks in advance.
        Christian

        Show
        Christian Koelle added a comment - I can confirm that this bug exists. It can be reproduced with the MyFaces-Simple-Demo-Application V. 1.1.6 on Tomcat 5.5.20 by doing the following: a.) Amend the content of the server-side-switched tab1 in the demo's TabbedPane.jsp to the the following, i.e. a a dataTable: <t:panelTab id="tab1" label="# {example_messages['tabbed_tab1']} " rendered="# {tabbedPaneBean.tab1Visible} "> <t:dataTable headerClass="myTableHeader" rowClasses="myTableRow1,myTableRow2" var="r" preserveDataModel="false" preserveRowStates="false" preserveSort="false" value="# {tabbedPaneBean.testBeans} "> <h:column> <f:facet name="header"> <h:outputText value="--Header 1 --" /> </f:facet> <t:inputText id="inputField002" value="# {r.s1} " /> </h:column> <h:column> <f:facet name="header"> <h:outputText value="--Header 2 --" /> </f:facet> <t:inputText id="inputField001" value="# {r.s2} " /> </h:column> </t:dataTable> b.) Add a TestBean to the application: pulbic class TestBean implements Serializable { private String _s1; private String _s2; // + getter and setter } c.) Extend the TabbedPaneBean with one property holding a list of TestBeans: private List<TestBean> testBeans; // + getter and setter d.) Initialise the property testBeans, with a few objects, e. g. by adding a default contructor containing the following lines: this.testBeans = new ArrayList<TestBean>(); this.testBeans.add(new TestBean()); this.testBeans.add(new TestBean()); There will be two table rows @ 2 input fields on the the tabbedPane-demopage after this amendment. Data entered into it, will be lost on Tab-change, contrary to the input fields outside of the <t:dataTable>. #################### As far as I could spent time to debug this, I can say that after the Apply-Request-Values-Phase (i. e. processDecodes) the UIcomponent (UIInput), which loses the entered values holds the submitted value in the attribue "_submittedValue" but somehow afterwards, the value will not be written into the bound bean model property. Somehow it appears that the tabswitching has some kind of immediate-alike behaviour, i. e. if you switch tabs, all fields of TabbedPane.jsp which are to be validated, will not be validated, contrary to what's happening when you use the already provided "Common submit button". It is interesting, that entered data will be correctly written to the bound model properties, if you use UIInput-components outside of a <t:dataTable> as already provided within the demo application. Please let me know, if you need more information on this or if you cannot reproduce it with the given information. Regards and thanks in advance. Christian

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Gerald Müllan
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development