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

  • #31
    refresh-actions vs. view-state actions

    Hi Keith,

    Originally posted by Keith Donald
    I agree something like "view-state actions" is needed.

    I'm hesistant about overriding entry-action behavior for one state type.
    That's a valid argument which I fully understand.

    Originally posted by Keith Donald
    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
    Aside from the fact that you probably meant formAction.setupForm (), I think this is a perfectly viable alternative which covers all scenarios. In other words, you get my approval.

    Will this make it into the code base prior to 1.0 final?

    Regards,

    Sam

    Comment


    • #32
      A call to setupForm before display and on refresh sounds good to me. I don't understand the chain aspect, but having one method separate from other entry-actions would do what I had hoped.

      Comment


      • #33
        Action chaining example

        Hi Ande,

        Originally posted by ande
        I don't understand the chain aspect, ...
        By "action chains," Keith just means that you can declare multiple actions for a single state that will be executed in succession such as in the following example:

        Code:
        <view-state id="displayForm">
            <action bean="formAction" method="setupForm"/>
            <action bean="formAction" method="loadReferenceData1"/>
            <action bean="formAction" method="loadReferenceData2"/>
        </view-state>
        In this case, all three methods would be called on the formAction in a chain. For further discussion, search the forum on "action chain" or something similar. I'm rather certain it's also discussed in the reference manual and perhaps even demonstrated in one of the samples (though of course for action-states).

        HTH,

        Sam

        Comment


        • #34
          OK, I understand that then. So it would not just be a call to setupForm, it would be any actions defined for the viewState that get executed (apart from entry/exit actions)? That would also work nicely.

          Comment


          • #35
            Originally posted by ande
            So it would not just be a call to setupForm, it would be any actions defined for the viewState that get executed (apart from entry/exit actions)?
            Yes, exactly!

            - Sam

            Comment


            • #36
              Sam, Ande, all:

              One thing that occurred to me about "view state actions" is this:

              - view state is entered
              - entry actions executed (if any)
              - actions executed (if any)
              - view selection made

              [redirect]

              - view state refresh
              - actions again executed (if any)

              The view-state actions are executed twice! However, for a POST + REDIRECT + GET it's arguably they should only be executed on the GET (refresh).

              On the other hand, if they're *only* executed on refresh (GET), then they don't get executed at all if a refresh never occurs.

              Thoughts?

              Keith

              Comment


              • #37
                To me it seems the flowExecutor will have to know if the view is planned to be displayed via a redirect or not. Additionally, one reason I suggested setting these "view actions" apart from other types is that I think they should be executed after the view selection is made. My take on the execution process would be:

                Without redirecting:
                - view state is entered
                - entry actions executed (if any)
                - view selection made
                - view actions executed (if any)

                With redirecting:
                - view state is entered
                - entry actions executed (if any)
                - view selection made
                [redirect]
                - view state refresh
                - view actions executed (if any)

                The refresh, then, would look like:
                - view state refresh
                - view actions executed (if any)

                Again, I wouldn't plan on putting any actions as what I'm calling "view actions" unless they are only needed by the view (since, as you say, there is no guarantee they will executed if the view is never GOT). Any actions that needed to be executed when going into that view state I'd logically put in entry-actions.

                Comment


                • #38
                  It seems to me that just using 'action' is a bit of a generic name for these very special purpose actions: they basically prepare a view for display. This is in sync with Keith & Ande's last remarks: these special 'view-prep' actions are potentially never executed and should only be executed when you're actually going to display the view. A special name highlights the special nature of these actions, similar to the way 'entry-actions' are only executed when a state is 'entered'.

                  Erwin

                  Comment


                  • #39
                    Name proposal for &quot;view actions&quot;

                    Hi Keith, Ande, Erwin, et al,

                    Originally posted by klr8
                    It seems to me that just using 'action' is a bit of a generic name for these very special purpose actions: they basically prepare a view for display. This is in sync with Keith & Ande's last remarks: these special 'view-prep' actions are potentially never executed and should only be executed when you're actually going to display the view. A special name highlights the special nature of these actions, similar to the way 'entry-actions' are only executed when a state is 'entered'.
                    I agree with Ande's analysis of the "execution process" and give merit to Erwin's pointing out that we need a special name. Admittedly, the desired functionality would/could be the same semantically speaking using action elements nested directly under the view-state, analagous to action-states; however, as Erwin points out, that would likely be misleading to people new to SWF. Defining a new name for such "view actions" would help to clarify the intention.

                    I don't have the perfect name yet, but we can discuss what would make the most sense. I propose that the "view actions" be grouped together like the entry-actions. Possible names would include (in order of preference):

                    display-actions, view-prep-actions, view-actions, pre-view-display-actions, post-view-selection-actions.

                    I'd considered "reference-data-actions" as well, but I think we can throw that out, since not all "view actions" would necessarily provide reference data.

                    Can you guys come up with any better suited names?

                    - Sam

                    Comment


                    • #40
                      Some other things to note:

                      It is the FlowExecutor that 'handles' the refresh logic, switching to a FlowExecutionRedirect if a redirect is required (alwaysRedirectOnPause == true).

                      The FlowExecutor obtains a ViewSelection by calling into the execution layer (FlowExecution -- which in turn uses the RequestControlContext to call into the Flow or State instances to actually process an event or flow launch and return an appropriate ViewSelection created by a ViewSelector). The obtained ViewSelection is self contained and should hold all info required to 'render' the view, whatever that may mean.

                      So to do a refresh we just need the ViewSelection object for the view we need to refresh (the last view). The current approach taken by the FlowExecutor is to call back into the FlowExecution layer, but now with a 'refresh' call. Wouldn't it be much simpler if the FlowExecutor just tracked the last ViewSelection made in every flow for which it manages execution. That would make refresh logic trivial and contained completely within the FlowExecutor.

                      In a way this makes a lot of sense to me. 'Refresh' is really a problem related to the external client interacting with SWF, not an SWF intrinsic problem, so it seems correct to move it to the boundary of SWF instead of having it in the SWF core (e.g. FlowExecution.refresh()) like it is now.

                      Any thoughts?

                      Erwin

                      Comment


                      • #41
                        More ideas related to my last post:

                        If the FlowExecutor was completely responsible for handling 'refresh', it could delegate to a pluggable strategy for handling this logic, e.g. a RefreshHandler. That would do away with the goofy 'alwaysRedirectOnPause' property that FlowExecutorImpl has now.

                        One possible RefreshHandler implementation could just keep track of the last ViewSelection keyed by FlowExecutionKey. Another could just keep track of a single last ViewSelection in the HttpSession.

                        Furthermore, this could potentially give a solution to the problem of refreshing a view rendered from an end-state, which is not currently supported. (Although it's still better to just do an external redirect or flow redirect from an end state instead of directly displaying a confirmation.)

                        Erwin
                        Last edited by klr8; Jul 18th, 2006, 10:16 AM.

                        Comment


                        • #42
                          Originally posted by sbrannen
                          I don't have the perfect name yet, but we can discuss what would make the most sense. I propose that the "view actions" be grouped together like the entry-actions. Possible names would include (in order of preference):

                          display-actions, view-prep-actions, view-actions, pre-view-display-actions, post-view-selection-actions.
                          Consider the following as well:

                          pre-render-actions, render-actions (or pre-rendering-actions, rendering-actions)

                          - sam

                          Comment


                          • #43
                            Some more things I'm thinking of:

                            A TransitionableState can 'enter()' and 'reenter()'. A ViewState also has 'refresh()'. Should 'reenter()' and 'refresh()' be related in some way for a ViewState? Maybe 'refresh()' should be 'reenter()' since you're really re-entering the state to re-obtain the last view selection?

                            Since states have behaviour and are pluggable in SWF, we could have a RefreshViewState where 'enter()' does nothing and 'reenter()' does all the work...That would fix the problem we have now where view setup logic is executed uselessly when you set 'alwaysRedirectOnPause' to true on the FlowExecutor since it will throw away the ViewSelection and re-obtain it a second time for the refresh.

                            I like the idea of highlighting the fact that a view state supports 'refresh' since in general it's a non trivial matter and the flow developer will have to design the flow to support it (e.g. with special view prepping actions, putting stuff that cannot easily be re-obtained in flow scope, ...).

                            Erwin

                            Comment


                            • #44
                              I personally prefer 'render-actions' or 'view-actions'; view-actions might have a more obvious meaning, but then again could be redundant as they are part of a view-state. In this case, redundancy is fine with me, and it's Ok with me too.

                              As for the flowExecutor logic, the main problem I see there is that the flowExecutor doesn't/shouldn't know what the current state is, or whether it is a view state that requires view-actions to be executed. Seems we don't need just the ViewSelection, but if it is being backed by view-actions, we need the RequestContext, and the state/actions (i.e. the flowExecution).

                              If the view-actions only get executed on refresh (as I was suggesting in my execution flow), seems like the logic would be:

                              if event && redirectOnPause <--refresh will happen on redirect
                              flowExecution.signalEvent
                              return FlowExecutionRedirect.INSTANCE;
                              if event && !redirectOnPause <--refresh happens immediately
                              flowExecution.signalEvent
                              return flowExecution.refresh <--view-actions get executed in here

                              Comment


                              • #45
                                ViewState reenter() vs. refresh()

                                Originally posted by klr8
                                A TransitionableState can 'enter()' and 'reenter()'. A ViewState also has 'refresh()'. Should 'reenter()' and 'refresh()' be related in some way for a ViewState? Maybe 'refresh()' should be 'reenter()' since you're really re-entering the state to re-obtain the last view selection?
                                @Keith: what was your rationale for using refresh() instead of reenter()?

                                I must admit that I've not fully delved into the internal workings in detail, but would reenter() not be called for a ViewState when it's being refreshed? If not, what is the exact purpose of reenter()?

                                - Sam

                                Comment

                                Working...
                                X