Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.1
    • Component/s: ACE-Components, QA
    • Labels:
      None
    • Environment:
      Icefaces2 revision# 23758
      server: tomcat6
      browser: FF3.6

      Description

      *Server side tabset in data table has problem
         1. load the page "http://localhost:8080/tab/tabSetServer/inDataTable.jsf"
         2. tab1 is selected for all by default
         3. select tab2 in any row
         4. now select tab2 for some other row
         5. Notice tab selected in step 3 is reset
      Test case available at '\svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\tabset'.

      Above problems is reproducible in all data-table and repeat component test pages.


      *Need some clarification on expected behavior and how to best test tabset with singleSubmit=false.

      *Styling of tabset has issues when used with datatable in repeat component. Also cannot change tabs.
      test url: http://localhost:8080/tab/dataStructures/tabRepeatDt.jsf

        Issue Links

          Activity

          Mandeep Hayher created issue -
          Mandeep Hayher made changes -
          Field Original Value New Value
          Assignee Ken Fyten [ ken.fyten ]
          Hide
          Mandeep Hayher added a comment -

          The test for tabset in update table from top is not working as expected.

          • load application three rows in datatable are displayed all with tab1 selected
          • change tab selection for row with John1, so Taylor1 is selected
          • Add new row to data table, John3 is added to the top of the table
          • Notice Taylor1 is not displayed as selected any more, Taylor0 is displayed as selected now ( it is not the second row i the data table)

          Page URL: http://localhost:8080/tab/dataStructures/updateTable2.jsf
          testcase at: \svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\tabset

          Show
          Mandeep Hayher added a comment - The test for tabset in update table from top is not working as expected. load application three rows in datatable are displayed all with tab1 selected change tab selection for row with John1, so Taylor1 is selected Add new row to data table, John3 is added to the top of the table Notice Taylor1 is not displayed as selected any more, Taylor0 is displayed as selected now ( it is not the second row i the data table) Page URL: http://localhost:8080/tab/dataStructures/updateTable2.jsf testcase at: \svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\tabset
          Ken Fyten made changes -
          Salesforce Case []
          Component/s ACE-Components [ 10050 ]
          Component/s QA [ 10016 ]
          Fix Version/s 2.0.1 [ 10255 ]
          Assignee Priority P1
          Affects Version/s 2.0.0 [ 10230 ]
          Affects Version/s 2.0.1 [ 10255 ]
          Assignee Ken Fyten [ ken.fyten ] Mark Collette [ mark.collette ]
          Mandeep Hayher made changes -
          Salesforce Case []
          Description *Server side tabset in data table has problem
             1. load the page "http://localhost:8080/tab/tabSetServer/inDataTable.jsf"
             2. tab1 is selected for all by default
             3. select tab2 in any row
             4. now select tab2 for some other row
             5. Notice tab selected in step 3 is reset
          Test case available at '\svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\tabset'.

          Above problems is reproducible in all data-table and repeat component test pages.


          *Need some clarification on expected behavior and how to best test tabset with singleSubmit=false.

          *Styling of tabset has issues when used with datatable in repeat component.
          *Server side tabset in data table has problem
             1. load the page "http://localhost:8080/tab/tabSetServer/inDataTable.jsf"
             2. tab1 is selected for all by default
             3. select tab2 in any row
             4. now select tab2 for some other row
             5. Notice tab selected in step 3 is reset
          Test case available at '\svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\tabset'.

          Above problems is reproducible in all data-table and repeat component test pages.


          *Need some clarification on expected behavior and how to best test tabset with singleSubmit=false.

          *Styling of tabset has issues when used with datatable in repeat component. Also cannot change tabs.
          test url: http://localhost:8080/tab/dataStructures/tabRepeatDt.jsf

          Hide
          Mark Collette added a comment -

          Please modify the test application so that the tabSet component's selectedIndex property has a ValueExpression to a property on the dataTable component's row object.

          When there is no ValueExpression, the tabSet must maintain the selectedIndex property itself, which internally relied on the clientId. When inserting or removing rows from the dataTable, the clientId's for each row are altered, causing properties to be shifted to the incorrect rows.

          Show
          Mark Collette added a comment - Please modify the test application so that the tabSet component's selectedIndex property has a ValueExpression to a property on the dataTable component's row object. When there is no ValueExpression, the tabSet must maintain the selectedIndex property itself, which internally relied on the clientId. When inserting or removing rows from the dataTable, the clientId's for each row are altered, causing properties to be shifted to the incorrect rows.
          Hide
          Mandeep Hayher added a comment -

          sing;eSubmit & immediate components not working. no errors message is displayed for input component with required=true in side the tabset.
          Page URl: http://localhost:8080/tab/tabsetAttribute.jsf
          testcase at: \svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\tabset

          Show
          Mandeep Hayher added a comment - sing;eSubmit & immediate components not working. no errors message is displayed for input component with required=true in side the tabset. Page URl: http://localhost:8080/tab/tabsetAttribute.jsf testcase at: \svn\repo\qa\trunk\Regression-Icefaces2\Sparkle\tabset
          Ken Fyten made changes -
          Salesforce Case []
          Assignee Mark Collette [ mark.collette ] Judy Guglielmin [ judy.guglielmin ]
          Ken Fyten made changes -
          Salesforce Case []
          Assignee Priority P1 P3
          Hide
          Ken Fyten added a comment -

          Once ICE-6490 is complete, this will need retesting.

          Show
          Ken Fyten added a comment - Once ICE-6490 is complete, this will need retesting.
          Ken Fyten made changes -
          Link This issue depends on ICE-6490 [ ICE-6490 ]
          Hide
          Judy Guglielmin added a comment - - edited

          The only concern left is we don't really have anything in place to error catch a dynamic style when validation exceptions occur. Currently, we lose all style with a dynamic change of style/styleclass, singleSubmit and the cancelOnInvalid set to false (not checked).

          Other than that, I think the test should list the behavior looking for which each combination.
          For example, we have cancelOnInvalid, which really has identical behaviour to singleSubmit="true", and immediate="true". However, this needs to be further defined.

          There is a serious lag before the styles are loaded on this test page. Might be another event we listen for so that the styles are loaded before the page is rendered (pretty sure I saw that in the yui event api)

          Found that if I put an inputText on one of the panes and an inputText bound to the same el #

          {AttrBean.tabContents}

          " while in the same form, and an outputText bound to the same el like this:_

          <h:form styleClass="ice-skin-sam" prependId="false">
          <h2> Demo has a TabchangeListener </h2>
          <ice:tabSet id="myTabSet" tabChangeListener="#

          {AttBean.tabChangeListener}

          " styleClass="#

          {AttBean.styleClass}

          "
          singleSubmit="#

          {AttBean.singleSubmit}

          "
          immediate="#

          {AttBean.immediate}

          "
          rendered="#

          {AttBean.rendered}

          "
          selectedIndex="#

          {AttBean.selectedTabIndex}

          "
          orientation="#

          {AttBean.orientation}

          "
          cancelOnInvalid="#

          {AttBean.cancelOnInvalid}

          "
          clientSide="#

          {AttBean.clientSide}

          "
          style="#

          {AttBean.style}

          ">
          <ice:tabPane id="tp1" label="Tab contents from JSP" >
          <h:outputText value="YUI generally works well with mobile browsers that are based on A-Grade browser foundations."/>
          <h:inputText id ="in" required="true"/>
          </ice:tabPane>
          <ice:tabPane id="tp2" label="tab Contents to check singleSubmit">
          <h:outputText value="#

          {AttBean.tabContents}"/>
          </ice:tabPane>
          <ice:tabPane id="tp3" disabled="true" label="Disabled" >
          <h:outputText value="Test ...."/>
          </ice:tabPane>
          </ice:tabSet>
          <h:inputText id="inputText" value="#{AttBean.tabContents}

          " required="true"/>

          </h:form>
          <h:outputText id="singleSubmitTest" value="#

          {AttBean.tabContents}

          "/>
          <h:messages/>

          Show
          Judy Guglielmin added a comment - - edited The only concern left is we don't really have anything in place to error catch a dynamic style when validation exceptions occur. Currently, we lose all style with a dynamic change of style/styleclass, singleSubmit and the cancelOnInvalid set to false (not checked). Other than that, I think the test should list the behavior looking for which each combination. For example, we have cancelOnInvalid, which really has identical behaviour to singleSubmit="true", and immediate="true". However, this needs to be further defined. There is a serious lag before the styles are loaded on this test page. Might be another event we listen for so that the styles are loaded before the page is rendered (pretty sure I saw that in the yui event api) Found that if I put an inputText on one of the panes and an inputText bound to the same el # {AttrBean.tabContents} " while in the same form, and an outputText bound to the same el like this:_ <h:form styleClass="ice-skin-sam" prependId="false"> <h2> Demo has a TabchangeListener </h2> <ice:tabSet id="myTabSet" tabChangeListener="# {AttBean.tabChangeListener} " styleClass="# {AttBean.styleClass} " singleSubmit="# {AttBean.singleSubmit} " immediate="# {AttBean.immediate} " rendered="# {AttBean.rendered} " selectedIndex="# {AttBean.selectedTabIndex} " orientation="# {AttBean.orientation} " cancelOnInvalid="# {AttBean.cancelOnInvalid} " clientSide="# {AttBean.clientSide} " style="# {AttBean.style} "> <ice:tabPane id="tp1" label="Tab contents from JSP" > <h:outputText value="YUI generally works well with mobile browsers that are based on A-Grade browser foundations."/> <h:inputText id ="in" required="true"/> </ice:tabPane> <ice:tabPane id="tp2" label="tab Contents to check singleSubmit"> <h:outputText value="# {AttBean.tabContents}"/> </ice:tabPane> <ice:tabPane id="tp3" disabled="true" label="Disabled" > <h:outputText value="Test ...."/> </ice:tabPane> </ice:tabSet> <h:inputText id="inputText" value="#{AttBean.tabContents} " required="true"/> </h:form> <h:outputText id="singleSubmitTest" value="# {AttBean.tabContents} "/> <h:messages/>
          Hide
          Judy Guglielmin added a comment -

          modified the tests as in two of the three instances here, the test pages were not quite right. CancelOnInvalid property confuses tests especially for singleSubmit and immediate. The cancelOnSubmit option only has to do with validation of the components within the tabset component itself. If there are components outside of tabSet and on the form, then input outside the form will do standard jsf behaviour and not be submitted.

          Show
          Judy Guglielmin added a comment - modified the tests as in two of the three instances here, the test pages were not quite right. CancelOnInvalid property confuses tests especially for singleSubmit and immediate. The cancelOnSubmit option only has to do with validation of the components within the tabset component itself. If there are components outside of tabSet and on the form, then input outside the form will do standard jsf behaviour and not be submitted.
          Judy Guglielmin made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Ken Fyten made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Assignee Priority P3

            People

            • Assignee:
              Judy Guglielmin
              Reporter:
              Mandeep Hayher
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: