ICEfaces
  1. ICEfaces
  2. ICE-3907

Views are not re-used in multi-view setups

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 1.8DR#1
    • Fix Version/s: 1.8RC1, 1.8
    • Component/s: Bridge, Framework
    • Labels:
      None
    • Environment:
      server+browser

      Description

      On page reload or redirect the current view is discarded being replaced by a freshly created view. Any state changes that were accumulated in the request bound beans or component tree is lost.

        Activity

        Hide
        Mircea Toma added a comment -

        This issue created due to a regression failure, failure that proved to be caused by a misplaced test script.
        The current behavior, even if not ideal, is the one expected in a multi-view setup and it hasn't changed since 1.6 release.

        Show
        Mircea Toma added a comment - This issue created due to a regression failure, failure that proved to be caused by a misplaced test script. The current behavior, even if not ideal, is the one expected in a multi-view setup and it hasn't changed since 1.6 release.
        Hide
        Ed Hillmann added a comment -

        So, there's no way to use existing views for multi-view applications when F5 is pressed in the browser? For my application, this is more than "not ideal", it would be a show-stopper. It just seems like this has been added to support portlets at the expense of standard web applications.

        Show
        Ed Hillmann added a comment - So, there's no way to use existing views for multi-view applications when F5 is pressed in the browser? For my application, this is more than "not ideal", it would be a show-stopper. It just seems like this has been added to support portlets at the expense of standard web applications.
        Hide
        Micha Kiener added a comment -

        I also noticed this behavior, even if it is not ideal, the more important thing is, that it is not consistent, so reusing existing views, even if F5 is pressed in the browser works in single-view environments, but not if concurrentDOMViews is turned on.

        Depending on the requirements, both behaviors could make sense, some users are expecting to freshly start over, if they hit F5, others just want to make sure the page is re-rendered, but with the existing data.

        Anyway, I have a solution for that to support both behaviors on top of the ICEfaces extended request scope. So if anyone is interested in additional scopes than just the JSF basic scopes like application, session and request, let me know, I could post them here as a preview since it is a component of the edoras framework which will be republished under the Modzilla Public License by March first.
        It supports additional scopes like "view" and "window", a conversation and even persistent scope are in development.

        Show
        Micha Kiener added a comment - I also noticed this behavior, even if it is not ideal, the more important thing is, that it is not consistent, so reusing existing views, even if F5 is pressed in the browser works in single-view environments, but not if concurrentDOMViews is turned on. Depending on the requirements, both behaviors could make sense, some users are expecting to freshly start over, if they hit F5, others just want to make sure the page is re-rendered, but with the existing data. Anyway, I have a solution for that to support both behaviors on top of the ICEfaces extended request scope. So if anyone is interested in additional scopes than just the JSF basic scopes like application, session and request, let me know, I could post them here as a preview since it is a component of the edoras framework which will be republished under the Modzilla Public License by March first. It supports additional scopes like "view" and "window", a conversation and even persistent scope are in development.
        Hide
        Thomas Schilk added a comment -

        I think I do have the same issue... So I also need another scope-definition, if I'm not wrong.
        After pressing F5 on a page that shows a chart that is actualized every 10 seconds the chart is no longer actualized and the server throws exception like

        2009-04-20 16:38:33,984:DEBUG:com.icesoft.faces.webapp.xmlhttp.PersistentFacesState: fatal render failure for View[f80J5RtNKlC4NQY6p5u_zg:2]
         2009-04-20 16:38:33,984:ERROR:de.konsens.gda.admin.ui.ShowMemoryChartBean: a rendering exception has occurred: Message: fatal render failure for View[f80J5RtNKlC4NQY6p5u_zg:2]
         2009-04-20 16:38:33,984:DEBUG:de.konsens.gda.admin.ui.ShowMemoryChartBean: ShowMemory Fatal rendering exception: 
         com.icesoft.faces.webapp.xmlhttp.FatalRenderingException: fatal render failure for View[f80J5RtNKlC4NQY6p5u_zg:2]
         	at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.fatalRenderingException(PersistentFacesState.java:491)
         	at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.failIfDisposed(PersistentFacesState.java:523)
         	at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.execute(PersistentFacesState.java:227)
         	at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:298)
         	at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:143)
         	at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
         	at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
         	at java.lang.Thread.run(Thread.java:619)
        
        Show
        Thomas Schilk added a comment - I think I do have the same issue... So I also need another scope-definition, if I'm not wrong. After pressing F5 on a page that shows a chart that is actualized every 10 seconds the chart is no longer actualized and the server throws exception like 2009-04-20 16:38:33,984:DEBUG:com.icesoft.faces.webapp.xmlhttp.PersistentFacesState: fatal render failure for View[f80J5RtNKlC4NQY6p5u_zg:2] 2009-04-20 16:38:33,984:ERROR:de.konsens.gda.admin.ui.ShowMemoryChartBean: a rendering exception has occurred: Message: fatal render failure for View[f80J5RtNKlC4NQY6p5u_zg:2] 2009-04-20 16:38:33,984:DEBUG:de.konsens.gda.admin.ui.ShowMemoryChartBean: ShowMemory Fatal rendering exception: com.icesoft.faces.webapp.xmlhttp.FatalRenderingException: fatal render failure for View[f80J5RtNKlC4NQY6p5u_zg:2] at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.fatalRenderingException(PersistentFacesState.java:491) at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.failIfDisposed(PersistentFacesState.java:523) at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.execute(PersistentFacesState.java:227) at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.executeAndRender(PersistentFacesState.java:298) at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:143) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) at java.lang. Thread .run( Thread .java:619)

          People

          • Assignee:
            Unassigned
            Reporter:
            Mircea Toma
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: