8 Replies Latest reply on Sep 13, 2013 9:35 AM by Brian Leathem

    rich:tabPanel execute/immediate-attribute on rich:tab

    dageisz Newbie

      Hello,

       

      i have a question regarding the rich:tabPanel.

      http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=tabPanel&sample=simple&skin=blueSky

       

      On a project i have the situation that i am using switchType="ajax" on one hand to speed up the render time on the other hand to validate the input per tab (on switch).

       

      Now there are different standards per tab.

      On one tab the input fields shall be validated ontabswitch on another they should not.

       

      1. So i thought i could use the execute attribute from the rich:tab component, but did not effect anything.
      2. My second attempt was to use the immediate attribute of the rich:tab, that did not work either.
      3. At last i tried the immediate attribute of the rich:tabPanel, wich was working as expected.

       

      Now i digged into the code a bit deeper and found a strange behavior.

       

      When i set immediate="true" to the rich:tab i switch to, i can do this without validation of the rich:tab i came from, but changing immediate="true" on the tab i dont want to get validated, does not work.

       

      Is this a bug or do i understand the mechanics the wrong way?

       

       

      <rich:tabPanel id="tabPanelSpezialtransporte" switchType="ajax">
          <!-- execute has no effect, even @none, input will be validated -->
          <rich:tab header="tab1 (execute)" execute="@this">
              <h:inputText value="#{myBean.value}" required="true" />
          </rich:tab>
      
      
          <!-- this tabs content should always be validated on tabswitch,
              but it is NOT when i switch to tab3, cause tab3 hast immediate true. -->
          <rich:tab header="tab2 (default validation,execution)">
              <h:inputText value="#{myBean.value}" required="true" />
          </rich:tab>
      
      
          <!-- this tab should never be validated on tabswitch, but in this example it is always, 
              cause there are no ther immediate tabs.-->
          <rich:tab header="tab3 (immediate)" immediate="true">
              <h:inputText value="#{myBean.value}" required="true" />
          </rich:tab>
      
      
      </rich:tabPanel>
      
      

       

      I hope i could make myself clear, cause i havent found any example on this.

       

      While debugging i found the following code that seems to be responsible for the situation:

      AbstractTogglePanel#setEventPhase

       

          protected void setEventPhase(ItemChangeEvent event) {
              if (isImmediate()
                      || (event.getNewItem() != null && RendererUtils.getInstance().isBooleanAttribute(event.getNewItem(),
                              "immediate"))) {
                  event.setPhaseId(PhaseId.APPLY_REQUEST_VALUES);
              } else {
                  event.setPhaseId(PhaseId.UPDATE_MODEL_VALUES);
              }
          }
      
      

       

      To decide what to do next the newItem is taken, while it seems to me that the oldItem should be the one asked for the immediate-attribute, cause this is the one beeing processed.

       

       

      Just in case it helps here is the stack trace when the method is called:

       

      Daemon Thread [[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'] (Suspended (breakpoint at line 526 in AbstractTogglePanel))     
           UITabPanel(AbstractTogglePanel).setEventPhase(ItemChangeEvent) line: 526     
           UITabPanel(AbstractTogglePanel).queueEvent(FacesEvent) line: 520     
           ItemChangeEvent(FacesEvent).queue() line: 130     
           UITabPanel(AbstractTogglePanel).processDecodes(FacesContext) line: 310     
           PartialViewExecuteVisitCallback.visit(VisitContext, UIComponent) line: 53     
           ExecuteExtendedVisitContext(BaseExtendedVisitContext).invokeVisitCallback(UIComponent, VisitCallback) line: 321     
           UITabPanel(AbstractTogglePanel).visitTree(VisitContext, VisitCallback) line: 900     
           HtmlForm(UIComponent).visitTree(VisitContext, VisitCallback) line: 1623     
           HtmlForm(UIForm).visitTree(VisitContext, VisitCallback) line: 371     
           UIOutput(UIComponent).visitTree(VisitContext, VisitCallback) line: 1623     
           UIViewRoot(UIComponent).visitTree(VisitContext, VisitCallback) line: 1623     
           ExtendedPartialViewContextImpl.executeComponents(PhaseId, Collection) line: 278     
           ExtendedPartialViewContextImpl.processPartialExecutePhase(PhaseId) line: 258     
           ExtendedPartialViewContextImpl.processPartial(PhaseId) line: 215     
           UIViewRoot.processDecodes(FacesContext) line: 923     
           ApplyRequestValuesPhase.execute(FacesContext) line: 78     
           ApplyRequestValuesPhase(Phase).doPhase(FacesContext, Lifecycle, ListIterator) line: 101     
           LifecycleImpl.execute(FacesContext) line: 118     
           FacesServlet.service(ServletRequest, ServletResponse) line: 593     
           ...
      

       

       

      Thanks in advance

        • 1. Re: rich:tabPanel immediate-attribute on rich:tab
          Brian Leathem Master

          What versino of RichFaces are you using?

          • 2. Re: rich:tabPanel immediate-attribute on rich:tab
            dageisz Newbie

            Richfaces 4.3.2.Final with mojarra 2.1.19

            • 3. Re: rich:tabPanel immediate-attribute on rich:tab
              Brian Leathem Master

              We have a test verifying the @execute attribute works:

              https://github.com/richfaces4/components/blob/master/output/ui/src/test/integration/org/richfaces/integration/tabPanel/StaticTabTest.java#L94

               

              Would you be up to modifying that test to demonstrate the failing behaviour you describe?  You can share it back in the from of a github pull request [1].

               

              [1] https://community.jboss.org/wiki/GuideToUsePullRequestsWithGitHubAndJIRA

              • 4. Re: rich:tabPanel immediate-attribute on rich:tab
                dageisz Newbie

                Hi Brian, 

                 

                i m not sure how you expect the execute attribute should work, this is why i am asking. 

                I was thinking that using execute="@this" or at least execute="@none" should affect the processed components inside the tab on switching. 

                So in my above example on tab1 will not be verified and not be written to the backing bean. 

                 

                Your test shows that one may add other components from outside the tabPanel to the submited values.

                If this is intended, then my guess was wrong and the execute attribute is the wrong way to go for me. I was just thinking that it works like the a4j:commandButton where the default execute submits the form and one may narrow the submited values down to a subset.

                 

                Thinking of a tab that has houndereds of inputComponents and only some should be submited on tabswitch. As it is now there seems no way to do this, right?

                 

                Before i start to learn about that test and pull thing the intended behavior should be clear, can you help me with that? 

                 

                What about the other point with the immediate attribute?

                 

                 

                Edit: I ve done some further testing.

                Both attributes (immediate and execute) seem to be related to the new tab. The execute (as used in the test case) will be taken into account if one clicks on the tab that has it, not the one that is left.

                 

                Now this leaves me with the question, how can i control the submited values of the tab i leave?

                • 5. Re: rich:tabPanel immediate-attribute on rich:tab
                  dageisz Newbie

                  Any news on the intended behavior?

                  The way it works now the attributes are taken into account on entering a tab, but i have no control over the left tab.

                  • 6. Re: rich:tabPanel immediate-attribute on rich:tab
                    Brian Leathem Master

                    I would expect the execute attribute of the tab to default to @this.  If you then set the execute attribute to some other value, that value should be used instead of the default.

                     

                    If the above behaviour is not what you observe, please file a jira issue indicating what you instead observe. (With accompnaying tests or sample code for verification).

                    • 7. Re: Re: rich:tabPanel immediate-attribute on rich:tab
                      dageisz Newbie

                      Hi Brian,

                       

                      seems we are not talking about the same thing.

                      I don't have a problem with the default of the execute attribute. That's ok and as expected. What drove me nuts was that i could not limit the submited/processed/executed Controls of a Tab that i leave when using switchType="ajax".

                       

                      Lets say i a have a Tab with about 20 input Controls and in some cases (using buttons inside the tab) many of them are mandatory.

                      Now when using switchType="ajax" every time i switch it the resulting ajax call submits ALL input fields and validates them!

                      So many of them (which are pointless in this moment) will be mandatory-checked and fail, preventing the user from leaving the tab.

                       

                      The behavior i expected from the execute attribute was to give me control over the values that are processed during tab switching, so that changing it from the default @this to a specific id (of set of ids) prevents the other controls from being processed. What happened was that the execute attribute has no effect on the number of the processed inputs within the tab and the immediate attribute behaved otherwise.

                       

                      When setting immediate of one tab to true, the processed values of the left tab, where not processed if the target tab had immediate="true", but not the original on that is left.

                       

                      Now the question is: Is the behavior i d like to have a feature request or is the current behavior a bug?

                       

                      I managed get my code working by validating the fields manually and now i moved on to a completely other topic, so i sorry i don't have the time to modify the tests and push this topic any longer.

                      • 8. Re: rich:tabPanel execute/immediate-attribute on rich:tab
                        Brian Leathem Master

                        bleathem wrote:

                         

                        If you then set the execute attribute to some other value, that value should be used instead of the default.

                         

                        dageisz wrote:

                         

                        The behavior i expected from the execute attribute was to give me control over the values that are processed during tab switching, so that changing it from the default @this to a specific id (of set of ids) prevents the other controls from being processed. What happened was that the execute attribute has no effect on the number of the processed inputs within the tab

                         

                        Seems to me like we are saying the same thing. Let me know if not!

                         

                        Please file a jira issue requesting this feature.