adfemg
  1. adfemg
  2. ADFEMG-81

EnhReq: reset JSF component state when refreshing region

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:
      None
    • Environment:

      Observed in JDev 11.1.1.6.0 (not tested in other versions)

      Description

      We have a custom human worklist application that show the list of tasks at the top and a dynamic region at the bottom showing the taskflow for the selected task. This region is a dynamic region.
      When switching between two tasks of the same type, the dynamic region will refresh as the input parameters change (and refresh=ifNeeded). However all JSF components in that region seem to retain their state, probably since all the component IDs remain the same. So things like af:showDetailHeader retain their collapsed/expanded state. This is confusing to the user as he expects to browse to a new task with a clean state. The user does get a clean state when switching between two tasks that require a different taskflow as all the component IDs change. It's just when switching between two tasks of the same type that the JSF component state is retained.

      Wouldn't it be nice if we have a property on the af:region to control whether the JSF components within that region should reset their state when the region refreshes. The default could be to keep the current behavior (not reset state) so existing applications don't break. But in cases like ours we would set the property to reset state when refreshing the region.

      If needed I could create a small sample app. It would contain a region with refresh=ifNeeded. Then have a taskflow in that region with an af:showDetailHeader where the user can change the collapsed/expanded state.Then have a button in the wrapper page that changes an input parameter of the taskflow so it refreshes. You notice that the af:showDetailHeader retains its state.

        Activity

        Hide
        Wilfred van der Deijl added a comment -

        We actually had one case where the state of a declarative component was actually more than simple UI. We had to resort to storing the state not in normal declarative component properties but in keys in the viewScope map as the viewScope does clear when refreshing a region.
        Even though this worked, it feels strange to store JSF component state in the viewScope just to workaround this issue.

        Show
        Wilfred van der Deijl added a comment - We actually had one case where the state of a declarative component was actually more than simple UI. We had to resort to storing the state not in normal declarative component properties but in keys in the viewScope map as the viewScope does clear when refreshing a region. Even though this worked, it feels strange to store JSF component state in the viewScope just to workaround this issue.
        Hide
        Jan Vervecken added a comment -

        hi Wilfred van der Deijl

        • about "If needed I could create a small sample app."
          • An example application that illustrates the exact behaviour you describe could help others to suggest a solution/workaround or to help notice related "unintended behaviour" in the current implementation, or confirm/support the use-case you describe for an enhancement request.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - hi Wilfred van der Deijl about "If needed I could create a small sample app." An example application that illustrates the exact behaviour you describe could help others to suggest a solution/workaround or to help notice related "unintended behaviour" in the current implementation, or confirm/support the use-case you describe for an enhancement request. regards Jan Vervecken
        Hide
        Wilfred van der Deijl added a comment -

        I created a small sample app in JDev 11.1.2.3 showing the issue also exists in 11gR2
        Unfortunately I cannot add an attachment to an issue once it is created, so here is a public dropbox link: https://dl.dropbox.com/u/4080191/RegionJsfState.zip
        Perhaps someone with more privileges can attach it to this issue.

        To show the issue:

        • run home.jsf
        • the page shows a (dynamic) region with a showDetailHeader
        • collapse the showDetailHeader to change its state
        • press the first button to change the region param. Because the region has refresh=ifNeeded it refreshes. You can also see this since the region renders the value of the param itself and the letter 'x' is added to the param each time you press the button. Note that the showDetailHeader remains collapsed and thus retains its state on region refresh
        • now press the second button which changes the taskflow for the dynamic region
        • pres the second button again to switch back to the initial taskflow. Now note that the showDetailHeader has reset its state to expanded
        Show
        Wilfred van der Deijl added a comment - I created a small sample app in JDev 11.1.2.3 showing the issue also exists in 11gR2 Unfortunately I cannot add an attachment to an issue once it is created, so here is a public dropbox link: https://dl.dropbox.com/u/4080191/RegionJsfState.zip Perhaps someone with more privileges can attach it to this issue. To show the issue: run home.jsf the page shows a (dynamic) region with a showDetailHeader collapse the showDetailHeader to change its state press the first button to change the region param. Because the region has refresh=ifNeeded it refreshes. You can also see this since the region renders the value of the param itself and the letter 'x' is added to the param each time you press the button. Note that the showDetailHeader remains collapsed and thus retains its state on region refresh now press the second button which changes the taskflow for the dynamic region pres the second button again to switch back to the initial taskflow. Now note that the showDetailHeader has reset its state to expanded
        Hide
        Wilfred van der Deijl added a comment -

        Did some more testing and having a showDetailHeader with the same id in both taskflows do not "leak" state from taskflow1 to taskflow2. This is because the fully qualified IDs for the showDetailHeader are different. The first taskflow uses r2:0:sdh1 while the second one uses r2:1:sdh1.
        It seems like the region component adds a :0 or :1 to the ID based on the taskflow ID. Each unique taskflow ID gets its unique number in the component ID. Wouldn't it be possible to do something similar when refreshing a region. So not keep the sub-ID based on the taskflow ID but simply increment it each time the region is refreshed? This would change the JSF ID of all components in the region thereby loosing there state as we want.

        Show
        Wilfred van der Deijl added a comment - Did some more testing and having a showDetailHeader with the same id in both taskflows do not "leak" state from taskflow1 to taskflow2. This is because the fully qualified IDs for the showDetailHeader are different. The first taskflow uses r2:0:sdh1 while the second one uses r2:1:sdh1. It seems like the region component adds a :0 or :1 to the ID based on the taskflow ID. Each unique taskflow ID gets its unique number in the component ID. Wouldn't it be possible to do something similar when refreshing a region. So not keep the sub-ID based on the taskflow ID but simply increment it each time the region is refreshed? This would change the JSF ID of all components in the region thereby loosing there state as we want.
        Hide
        Jan Vervecken added a comment -

        hi Wilfred van der Deijl

        Currently I don't seem to be able to attach a file to this JIRA issue ADFEMG-81 (like your file "RegionJsfState.zip").

        Also wanted to confirm that I have been able to reproduce the behaviour you describe for the af:showDetailHeader in the task-flow.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - hi Wilfred van der Deijl Currently I don't seem to be able to attach a file to this JIRA issue ADFEMG-81 (like your file "RegionJsfState.zip"). Also wanted to confirm that I have been able to reproduce the behaviour you describe for the af:showDetailHeader in the task-flow. regards Jan Vervecken
        Hide
        chriscmuir added a comment -

        Discussing this internally, get back to you soon.

        On a separate note I'm pursuing the file upload issue separate to this issue. Jan, see my reply to your other email on this.

        CM.

        Show
        chriscmuir added a comment - Discussing this internally, get back to you soon. On a separate note I'm pursuing the file upload issue separate to this issue. Jan, see my reply to your other email on this. CM.
        Hide
        Jan Vervecken added a comment -

        Thanks for your reply Chris.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thanks for your reply Chris. about "On a separate note I'm pursuing the file upload issue separate to this issue." see http://www.java.net/forum/topic/site-help/issue-tracker-file-uploads-gonedisabled (and the currently no longer available ADFEMG-82 ) regards Jan Vervecken
        Hide
        chriscmuir added a comment - - edited

        Wilfred, ER 16082532 lodged. Thanks for raising this. If you can hold onto the zip file until Java.net restores the file upload process please.

        Jan, before you ask, yes I've made the ER public, but unlike bugs with ERs I can only do this after they are submitted so you miss the ER text. The text submitted is pretty much as per this ADF EMG issue.

        CM.

        Show
        chriscmuir added a comment - - edited Wilfred, ER 16082532 lodged. Thanks for raising this. If you can hold onto the zip file until Java.net restores the file upload process please. Jan, before you ask, yes I've made the ER public, but unlike bugs with ERs I can only do this after they are submitted so you miss the ER text. The text submitted is pretty much as per this ADF EMG issue. CM.
        Hide
        Wilfred van der Deijl added a comment -

        Thanks Chris for filing the ER. Now let's hope it makes into the product in a reasonable timeframe
        I'll keep the zip public

        Show
        Wilfred van der Deijl added a comment - Thanks Chris for filing the ER. Now let's hope it makes into the product in a reasonable timeframe I'll keep the zip public
        Hide
        Jan Vervecken added a comment -

        Thank you for the update Chris.

        • about "... ER 16082532 lodged ... Jan, before you ask, yes I've made the ER public ... so you miss the ER text ..."
          • On My Oracle Support I have been able to find enhancement request 16082532, "ABILITY TO RESET JSF COMPONENT STATE WHEN REFRESHING REGION", indeed without any details.

        regards
        Jan Vervecken

        Show
        Jan Vervecken added a comment - Thank you for the update Chris. about "... ER 16082532 lodged ... Jan, before you ask, yes I've made the ER public ... so you miss the ER text ..." On My Oracle Support I have been able to find enhancement request 16082532, "ABILITY TO RESET JSF COMPONENT STATE WHEN REFRESHING REGION", indeed without any details. @Wilfred about "Now let's hope it makes into the product in a reasonable timeframe" "hoop doet leven" ( http://translate.google.com/#nl/en/hoop%20doet%20leven ) regards Jan Vervecken
        Hide
        Wilfred van der Deijl added a comment -

        In case somebody wants to check on the ER state at Oracle support, here's a link: https://support.oracle.com/epmos/faces/ui/km/BugDisplay.jspx?id=16082532

        Show
        Wilfred van der Deijl added a comment - In case somebody wants to check on the ER state at Oracle support, here's a link: https://support.oracle.com/epmos/faces/ui/km/BugDisplay.jspx?id=16082532
        Hide
        chriscmuir added a comment -

        No progress. Dropped email internally to give the ER a poke.

        CM.

        Show
        chriscmuir added a comment - No progress. Dropped email internally to give the ER a poke. CM.
        Hide
        chriscmuir added a comment -

        On response from dev, the ER is being looked at in conjunction with another internal ER 14782453. I'm not in a position to reveal details on the other ER as it's marked private (Publish: No). However I'll continue to track the original ER and this ER to see if we can get a result.

        CM.

        Show
        chriscmuir added a comment - On response from dev, the ER is being looked at in conjunction with another internal ER 14782453. I'm not in a position to reveal details on the other ER as it's marked private (Publish: No). However I'll continue to track the original ER and this ER to see if we can get a result. CM.
        Hide
        chriscmuir added a comment -

        Since last looking at this, there has been substantial work on the relating ER 14782453. The ER addresses the following limitation which dev believes will also address the issue posted here lodged as ER 16082532:

        @ There is an issue with how the region component decides whether or
        @ not it can re-use the existing component tree for the region. Currently if
        @ the string value of the viewId remains the same the component continues to
        @ use the existing component tree. This doesn't properly account for the
        @ possibility of the region model having navigated to a new view instance with
        @ the same viewId.

        At this stage the fix/change for ER 14782453 will eventuate in 11.1.1.9.0 and/or 12.1.3.0.0. However from our internal systems it's unclear to me at the moment has the work commenced or even finished as there's substantial notes against the ER and it's active right now. I will again check this in the near future and report what I can when I can.

        CM.

        Show
        chriscmuir added a comment - Since last looking at this, there has been substantial work on the relating ER 14782453. The ER addresses the following limitation which dev believes will also address the issue posted here lodged as ER 16082532: @ There is an issue with how the region component decides whether or @ not it can re-use the existing component tree for the region. Currently if @ the string value of the viewId remains the same the component continues to @ use the existing component tree. This doesn't properly account for the @ possibility of the region model having navigated to a new view instance with @ the same viewId. At this stage the fix/change for ER 14782453 will eventuate in 11.1.1.9.0 and/or 12.1.3.0.0. However from our internal systems it's unclear to me at the moment has the work commenced or even finished as there's substantial notes against the ER and it's active right now. I will again check this in the near future and report what I can when I can. CM.
        Hide
        chriscmuir added a comment -

        As per the update to ADFEMG-34:

        "Dev has subsequently indicated that they don't think ER 15841961 is a simple fix, and as such have not prioritized it as a high priority at this time.
        So I don't keep on tracking this issue I'm going to close it, and leave development to prioritize according to their own work."

        CM.

        Show
        chriscmuir added a comment - As per the update to ADFEMG-34 : "Dev has subsequently indicated that they don't think ER 15841961 is a simple fix, and as such have not prioritized it as a high priority at this time. So I don't keep on tracking this issue I'm going to close it, and leave development to prioritize according to their own work." CM.
        Hide
        chriscmuir added a comment -

        Ignore last update, reopening issue, comment was applied to wrong issue.

        CM.

        Show
        chriscmuir added a comment - Ignore last update, reopening issue, comment was applied to wrong issue. CM.
        Hide
        chriscmuir added a comment -

        Work continues on ER 14782453, it is now subsequently blocked by another piece of work.

        CM.

        Show
        chriscmuir added a comment - Work continues on ER 14782453, it is now subsequently blocked by another piece of work. CM.
        Hide
        chriscmuir added a comment -

        This fix should be available in 11.1.1.9.0 and as such I'm closing this EMG issue. If upon the public 11.1.1.9.0 release the ER is not available please reopen this issue and state how the implementation doesn't meet your requirements.

        Show
        chriscmuir added a comment - This fix should be available in 11.1.1.9.0 and as such I'm closing this EMG issue. If upon the public 11.1.1.9.0 release the ER is not available please reopen this issue and state how the implementation doesn't meet your requirements.

          People

          • Assignee:
            Unassigned
            Reporter:
            Wilfred van der Deijl
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: