MyFaces CODI
  1. MyFaces CODI
  2. EXTCDI-239

Expire RestScoped beans if it's used in different views

    Details

      Description

      I have to views (viewA and viewB) and both use the same model. If I change the view from A to B via GET the old model should be expired.

        Activity

        Hide
        Mark Struberg added a comment -

        hi!

        ad #1) yes, but remember that this only happens if the bean gets used on different views which use GET! This is not often the case. Usually you have 1 'entry page' with GET and then just do POST in between the other pages.

        ad #2) yup true, will take a look tomorrow.

        ad #3) do we have a default separator defined as static public final String somewhere already? I just did like to use a different one for the viewId than for the viewParameters.

        Show
        Mark Struberg added a comment - hi! ad #1) yes, but remember that this only happens if the bean gets used on different views which use GET! This is not often the case. Usually you have 1 'entry page' with GET and then just do POST in between the other pages. ad #2) yup true, will take a look tomorrow. ad #3) do we have a default separator defined as static public final String somewhere already? I just did like to use a different one for the viewId than for the viewParameters.
        Hide
        Gerhard Petracek added a comment - - edited

        #1
        losing the state only after a navigation via a get-request sounds confusing for users
        (e.g. someone refactors a view and uses a h:link instead of a h:commandLink and the behaviour of a scope changes doesn't sound like a nice idea).

        #2
        we don't need RestParameters#isPostback.
        we already have RequestTypeResolver#isPostRequest

        #3
        please add the reason for using "//" as separator - that's yet another new separator in the code-base

        Show
        Gerhard Petracek added a comment - - edited #1 losing the state only after a navigation via a get-request sounds confusing for users (e.g. someone refactors a view and uses a h:link instead of a h:commandLink and the behaviour of a scope changes doesn't sound like a nice idea). #2 we don't need RestParameters#isPostback. we already have RequestTypeResolver#isPostRequest #3 please add the reason for using "//" as separator - that's yet another new separator in the code-base
        Hide
        Mark Struberg added a comment -

        I now committed a fix based on one of Buetts patches.
        It will store the restParams and the view it's being used in diretly in the conversation handler (via the ExpirationEvaluator)

        Show
        Mark Struberg added a comment - I now committed a fix based on one of Buetts patches. It will store the restParams and the view it's being used in diretly in the conversation handler (via the ExpirationEvaluator)
        Hide
        Gerhard Petracek added a comment -

        currently that isn't the contract of the scope

        Show
        Gerhard Petracek added a comment - currently that isn't the contract of the scope
        Hide
        Mark Struberg added a comment -

        Oki I see where the problem is. It's the non-deterministic behaviour depending on whether a view already got served or not

        viewA?x=a -> viewB?y=b

        vs

        viewB?x=c -> viewA?x=a -> viewB?y=b

        Actually it might be ok to clean the bean if another view gets served via GET. Will need to think about it.
        In any case the safe bet is to not use the same backing bean for 2 GET pages.

        Show
        Mark Struberg added a comment - Oki I see where the problem is. It's the non-deterministic behaviour depending on whether a view already got served or not viewA?x=a -> viewB?y=b vs viewB?x=c -> viewA?x=a -> viewB?y=b Actually it might be ok to clean the bean if another view gets served via GET. Will need to think about it. In any case the safe bet is to not use the same backing bean for 2 GET pages.

          People

          • Assignee:
            Mark Struberg
            Reporter:
            Marcus Büttner
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development