Announcement Announcement Module
Collapse
No announcement yet.
Feedback requested: Redirect support in SWF Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Keith, is the api in the latest RC3 (setRedirectOnPause(boolean b)) to be considered stable?

    Comment


    • #17
      Kees,

      Yes.

      Keith

      Comment


      • #18
        Losing the requestScope objects when redirecting on pause to a view is requiring us to choose between the two features.

        On the one hand, the redirectOnPause affords us many great things, so I've tried moving the objects that really should only last the lifetime of the request/response to other scopes (conversation or flow), but this is not working out.

        On the other hand, I disable the redirectOnPause, and have to deal with issues I thought were resolved with browser navigation, form resubmission, posting the flow execution key, etc.

        I understand why the design change was made, but it would be great if the two could work together, or some other temporary scope in conjunction with redirection to a view; I suppose I could cobble together a flow listener to provide this functionality, but it seems like a common enough scenario that a view or redirect scope should be made accessible within the RequestContext.

        Comment


        • #19
          What would you like to see exactly and why? Flash scope? Why is flow scope not good enough?

          Elaborate :-)

          Keith

          Comment


          • #20
            Lost my property-editors

            I tried redirect, and have set my formErrorsScope to FLOW (otherwise, I lost my validation-errors). Only my propertyEditors are gone when the page is loaded (eg to format dates) What can I do to have this working? Where are these property-editors stored? I cannot find them in the original request-object.

            Comment


            • #21
              Indeed, property editors are registered with the data binder, which produces an errors collection. The collection itself can be placed in flow scope to preserve errros, however, the actual property accessor (with bound property editors) is transient so editors are lost.

              Can you open a JIRA?

              Keith

              Comment


              • #22
                Originally posted by Keith Donald
                What would you like to see exactly and why? Flash scope? Why is flow scope not good enough?

                Elaborate :-)
                The reason flow scope isn't a good fit for our use case is that some views we direct to are displaying results of queries and/or have objects linked to a persistence session. The good thing about storing such things in the requestScope is that we don't have to worry about them being accessed again later, when the results might be stale, or the persistence session no longer available (when a Hibernate object has been serialized/deserialized from continuation storage, for example).
                Another situation is starting a subflow and mapping in an object via the requestScope, like root.requestScope.foo->subflow.flowScope.foo. If we move this mapping from root.flowScope.foo->subflow.flowScope.foo, then we have to make sure we clean up the root.flowScope before re-launching the subflow again, so no old foo's get in when not intended.

                I guess the main consideration is adding what seems like unnecessary management code for adapting the flow scope to be used like the request scope; we generally use the flow scope for storing objects that *do* need to be around for the life of the flow execution, so it will have to take that into account also. It's doable, but I like the semantics of how the conversation/flow/request work already.

                What I'd like to see could be of two forms. One is probably what you're referring to as flash scope; this would be something that was aware of view redirection and would be available from the initial flow activation to the ultimate rendering of a view (and then gone). Possibly context.viewScope? Another idea would be an easy way to propagate what is needed from the requestScope of the original request to the requestScope of the redirected view. For example, applying an attribute mapper at the redirection point where one could specify i.e. "searchResultsBean" as output and input to the redirected view's requestScope.

                Comment


                • #23
                  Ande,

                  Good, practical suggestions. We'll see if we can make some of these happen before 1.0 final. We have some time before the release, as we are going to release after 2.0 final to recommend SWF with 2.0 (though SWF will run on 1.2.7 or >).

                  Keith

                  Comment


                  • #24
                    Had some feedback on the usefulness of my prior suggestions...

                    Regarding the flash or view scope idea, as is, I don't think this would provide what I was going for. From what I gather, when a flowExecutionKey is provided with no eventId, as is the case with the redirectOnPause, the view is considered to be a refresh, and the flow execution is resumed accordingly. I created a listener that would temporarily store the requestScope on pause, and populate it on resume, and this works ok in the case of the redirect. This doesn't work when the view is resumed from either use of the browser navigation (back/forward), or an actual page refresh, or use of a bookmarked link, etc, because there is no event occurring, and thus nothing to populate the requestScope to begin with.

                    The next idea would be to serialize the requestScope along with the flowExecution to keep it available for a view resume, but this defeats the purpose as outlined. Curious... pre-1.0, did the redirectOnPause execute events when navigating to the redirected URLs? I don't remember encountering this issue with the requestScope then.

                    One possibly better idea is to have a set of actions defined in a view-state that could be executed to back the view; so even on refresh, you would do something like: context.getCurrentState().getViewActionList().exec ute(context);

                    Comment


                    • #25
                      We didn't have redirectOnPause pre 1.0...there was no redirect support at all...

                      Keith

                      Comment


                      • #26
                        Perhaps it was the EA vs RC1 behavior I was interested in then. At some point there were redirect URLs created like /flow/_<encodedFlowExecutionKey> , instead of having the flowExecutionKey URL param.

                        Comment


                        • #27
                          1.0 EA had the notion of a "conversation" redirect, which was replaced by the "flow execution redirect" in 1.0 RC1. At one point the RequestPathFlowExecutorArgumentExtractor actually embedded the key as part of the request path by default, but what does that have to do with the requestScope issue you are having?

                          Is what you after "refresh actions" or view-state actions to be re-executed on a refresh?

                          Keith

                          Comment


                          • #28
                            No worries, I was thinking out loud on the EA vs RC1. I didn't think I had the same issues in the original implementation.

                            The idea of "refresh actions" would be a set of actions defined within a view-state that get executed when the view is to be displayed. If not redirecting, they behave as normal view-state actions; if redirecting, they get executed only after having been redirected to the flowExecution so that they can support the display of the view.

                            As an example, I moved all my view support actions (that populate the requestScope) to entry-actions, and then made a listener that executes these actions when the resumed() method is called on the listener; this basically did what I wanted, with the disadvantage of the entry-actions getting called twice when transitioning: once when you enter a state, then again with the redirect request. It would be cool to be able to define <view-actions> that would explicitly be run when the ApplicationView is to be part of the reponse instruction.

                            Comment


                            • #29
                              Requested feature: view-actions or view-refresh-actions

                              Hi Keith and Ande,

                              I'd like to chime in on this notion of "view-actions" and add my 2 cents.

                              Originally posted by ande
                              The idea of "refresh actions" would be a set of actions defined within a view-state that get executed when the view is to be displayed. If not redirecting, they behave as normal view-state actions; if redirecting, they get executed only after having been redirected to the flowExecution so that they can support the display of the view.

                              ...

                              It would be cool to be able to define <view-actions> that would explicitly be run when the ApplicationView is to be part of the reponse instruction.
                              I think this is a missing feature set in SWF currently. I have experienced similar problems with entry-actions that provide reference data for the view. Specifically, I call a POJO service that provides a privacy policy in the language corresponding to the current locale. Here's an excerpt from my flow definition:

                              Code:
                              <view-state id="view.editProfileBasics" view="registration/editProfileBasics">
                                <entry-actions>
                                  <action bean="policyService" method="getPrivacyPolicy()" resultName="privacyPolicy" />
                                </entry-actions>
                                <transition on="back" to="view.editAddress">
                                  <action bean="registrationWizard" method="bind" />
                                </transition>
                                <transition on="continue" to="bindAndValidateProfileBasics" />
                              </view-state>
                              This code works fine when entering the view-state, as the name "entry-actions" implies; however, if the user clicks on a language link on the page to switch to a different language, the actions defined in the entry-actions will not be reexecuted, since the view-state is not actually reentered. Rather, it is simply refreshed, as if the user had hit the "reload" button in the browser. In my particular use case, this is an error, since the privacy policy will not be updated.

                              I realize that you would not want or expect entry-actions to execute on every view refresh in every use case. Thus, I feel that SWF needs the concept of view-actions or view-refresh-actions that would execute on every refresh of the view, regardless of whether or not the view-state is being entered.

                              An alternative would be simply to add a new execute-on-refresh attribute to the standard action element nested within an entry-actions element. Thus, for backwards compatibility, entry-actions without execute-on-refresh="true" (or set to "false", the default) would only execute on entering the view-state; whereas, entry-actions with execute-on-refresh="true" would execute on entering the view-state and for every refresh of the view-state.

                              The following is a proposed example:

                              Code:
                              <view-state id="view.editProfileBasics" view="registration/editProfileBasics">
                                <entry-actions>
                                  <action bean="policyService" method="getPrivacyPolicy()" resultName="privacyPolicy" execute-on-refresh="true" />
                                </entry-actions>
                                <transition on="back" to="view.editAddress">
                                  <action bean="registrationWizard" method="bind" />
                                </transition>
                                <transition on="continue" to="bindAndValidateProfileBasics" />
                              </view-state>

                              @Keith: what are your thoughts on this concept? Would you be willing to implement this in SWF? If not, can you propose a best practice work-around to solve this issue?

                              Thanks for your feedback,

                              Sam

                              p.s. I should mention that I have not yet upgraded from EA to RC3, since I am awaiting the final release before migrating all of my code. Thus, if this issue has already been dealt with in RC3, please let me know. Though based on Ande's comments, I assume it has not been implemented.

                              Comment


                              • #30
                                This is good discussion.

                                I agree something like "view-state actions" is needed.

                                I'm hesistant about overriding entry-action behavior for one state type.

                                What about this:

                                Code:
                                <view-state id="displayForm">
                                    <action bean="formAction" method="setupForm"/>
                                </view-state>
                                setupForm.formAction would be invoked on enter before display as well as on refresh. Similiar to action-state, you could have a chain here.

                                Thoughts?

                                Keith

                                Comment

                                Working...
                                X