ICEfaces
  1. ICEfaces
  2. ICE-7374

f:ajax call to input component in panelTabSet doesn't work

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1-Beta
    • Fix Version/s: 2.1-Beta2, 3.0
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      ICEfaces 2, JSF 2
    • Assignee Priority:
      P1

      Description

      http://jira.icefaces.org/browse/ICE-7185?focusedCommentId=36424&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_36424

      It looks like, when fixing ICE-7185, there was a negative side-effect whereby f:ajax / visitTree calls into the panelTabSet / UISeries don't reach the children within.

      It's my theory that we adopted some UIColumn specific code from UIData that will inhibit non-UIColumn using UISeries sub-classes, such as panelTabSet, from having proper visitTree operation.

        Activity

        Hide
        Mark Collette added a comment -

        Investigated UISeries and PanelTabSet to see how the previous code change might have affected f:ajax calls to within the panelTabSet. The visitTree() code in UISeries governs how f:ajax calls work within it. Basically, the recursion into the children could happen with and without iteration, that is the state saving did not use iteration and the regular phases did. But the recursion would not happen because this configuration of the PanelTabSet is with static tabPane children, and so there is no provided DataModel / value, so the code in UISeries that verifies that the DataModel row is available would fail and curtail the recursion. So first I attempted to allow it to recurse by detecting this specific scenario, and having PanelTabSet report that the data was available. But then, since it was in iteration, that affected the clientIds as reporting an additional index value in them. So I tried fixing the clientId generation to not have redundant indexing when in iteration. But that opened up a can of worms and touched on the ongoing ICE-7244 efforts, which is not in scope for this release. So, I backed out that attempt, and re-examined the visitTree changes, and saw that there had previously been some code for recursion when out of iteration, that was seemingly redundant, but looks to precisely be for this scenario. Re-enabling that code fixes this issue.

        Subversion 26110
        compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

        Show
        Mark Collette added a comment - Investigated UISeries and PanelTabSet to see how the previous code change might have affected f:ajax calls to within the panelTabSet. The visitTree() code in UISeries governs how f:ajax calls work within it. Basically, the recursion into the children could happen with and without iteration, that is the state saving did not use iteration and the regular phases did. But the recursion would not happen because this configuration of the PanelTabSet is with static tabPane children, and so there is no provided DataModel / value, so the code in UISeries that verifies that the DataModel row is available would fail and curtail the recursion. So first I attempted to allow it to recurse by detecting this specific scenario, and having PanelTabSet report that the data was available. But then, since it was in iteration, that affected the clientIds as reporting an additional index value in them. So I tried fixing the clientId generation to not have redundant indexing when in iteration. But that opened up a can of worms and touched on the ongoing ICE-7244 efforts, which is not in scope for this release. So, I backed out that attempt, and re-examined the visitTree changes, and saw that there had previously been some code for recursion when out of iteration, that was seemingly redundant, but looks to precisely be for this scenario. Re-enabling that code fixes this issue. Subversion 26110 compat/components/src/main/java/com/icesoft/faces/component/panelseries/UISeries.java

          People

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

            Dates

            • Created:
              Updated:
              Resolved: