ICEfaces
  1. ICEfaces
  2. ICE-7675

ace:TabSet first tab selected at load when using disabled tabs.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 3.2
    • Fix Version/s: 3.3
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      IF 3.0
    • Assignee Priority:
      P2

      Description

      Caused as a result of ICE-7627.

        Activity

        Hide
        Nils Lundquist added a comment -

        This issue was due to a change in how the tabset sets the disabled state for a tab:

        Originally, the tab rendered a style class on a particular node to indicate it is disabled, and during the YUI tabset component initialization, the appropriate tab was disabled in the JS model of the tabset. However enabling the tab rendered the tab, but not the tabset, which is responsible (in the YUI JS) for managing 'selectability', so the tab remained unselectable.

        To fix this, tabs were no longer initialized as disabled, they are rendered alike, and the ACE tabset JS has an array indicating the disabled tabs, and at ACE tabset init, we disable the tabs via the available YUI tabset API. However, because the ACE tabset init follows that of the YUI tabset, the YUI tabset has already initialized itself, which includes selecting the first non-disabled tab. If possible the code to process the disabled state included with the ACE tabset config should run before the YUI tabset init- adding the disabled style class to appropriate tabs, allowing the YUI component to init correctly.

        Show
        Nils Lundquist added a comment - This issue was due to a change in how the tabset sets the disabled state for a tab: Originally, the tab rendered a style class on a particular node to indicate it is disabled, and during the YUI tabset component initialization, the appropriate tab was disabled in the JS model of the tabset. However enabling the tab rendered the tab, but not the tabset, which is responsible (in the YUI JS) for managing 'selectability', so the tab remained unselectable. To fix this, tabs were no longer initialized as disabled, they are rendered alike, and the ACE tabset JS has an array indicating the disabled tabs, and at ACE tabset init, we disable the tabs via the available YUI tabset API. However, because the ACE tabset init follows that of the YUI tabset, the YUI tabset has already initialized itself, which includes selecting the first non-disabled tab. If possible the code to process the disabled state included with the ACE tabset config should run before the YUI tabset init- adding the disabled style class to appropriate tabs, allowing the YUI component to init correctly.
        Hide
        Nils Lundquist added a comment -

        Assigning back to Ken for delegation now that my analysis has been added to this JIRA.

        Show
        Nils Lundquist added a comment - Assigning back to Ken for delegation now that my analysis has been added to this JIRA.
        Hide
        Mark Collette added a comment -

        Nils, is the problem that if the application wants tab 3 to be selected, but all tabs are disabled, or simply just tab 3, then it won't get to be selected, but instead some other enabled tab will be or failing that if all are disabled then tab 0 will be? And we want the specified tab to be selected regardless of whether it is disabled? On initial page GET and on any POST.

        Show
        Mark Collette added a comment - Nils, is the problem that if the application wants tab 3 to be selected, but all tabs are disabled, or simply just tab 3, then it won't get to be selected, but instead some other enabled tab will be or failing that if all are disabled then tab 0 will be? And we want the specified tab to be selected regardless of whether it is disabled? On initial page GET and on any POST.
        Hide
        Mark Collette added a comment -

        Ok, the issue is that a customer expressed interest in the tabSet defaulting the initial selectedIndex to the first enabled tabPane's index, as opposed to the default value of zero. It would be possible to interpret a negative selectedIndex in this way, and set it to the initial enabled index. There is the question of, if the enabled values change, whether the selectedIndex should be recalculated. It would be less feasible to know to do this, unless the selectedIndex was again reverted to a negative value.

        It seems, considering the additional complexity and regression risk, that an application could instead simply specify the desired selectedIndex themselves quite easily.

        Show
        Mark Collette added a comment - Ok, the issue is that a customer expressed interest in the tabSet defaulting the initial selectedIndex to the first enabled tabPane's index, as opposed to the default value of zero. It would be possible to interpret a negative selectedIndex in this way, and set it to the initial enabled index. There is the question of, if the enabled values change, whether the selectedIndex should be recalculated. It would be less feasible to know to do this, unless the selectedIndex was again reverted to a negative value. It seems, considering the additional complexity and regression risk, that an application could instead simply specify the desired selectedIndex themselves quite easily.

          People

          • Assignee:
            Mark Collette
            Reporter:
            Nils Lundquist
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: