Use cases for each flow data scopes

[nitinkcv]

Hi all,

Could anyone please let me know a kind of a use case scenario basis for each of the flow data scopes. i.e. flow scope, view scope, conversation scope, request scope and flash scope.

I could kinda make out differences in flow, view and conversation, but nonetheless a use case for each would help solve the confusion.

Thanks.

[InverseFalcon]

For most of these, it's just a matter of where you need the data and where you don't. You'll use the same decisions as you would when deciding if a variable should be local, instance, or global.

Flow scoped attributes persist for the duration of the flow. Flows are usually designed to handle a specific use case consisting of actions and views. Flow scoped data, then, is only relevant within the use case the flow represents. Once the flow ends, flow scoped data is cleaned up. I'd say flow scope is the most used scope in SWF, since data is usually relevant across several pages and actions. You'll often pass flow-scoped data as inputs to subflows.

View scoped attributes persist for the duration of a view-state, so they only have relevance on the page in question. I typically use view scope for page flags and conditionals (to render something one way or another), page text (in a few rare cases), and data only needed for the backing page. If, on a transition, I need to ferry a view-scoped object into the next state, I can use a "set" action to move the attribute into request scope. That way the object only stays in scope as long as I need it and no longer. It gets cleaned up automatically.

Conversation scope holds data that persists across the top-level flow and all its subflows. It's similar to session scope, just a little more restricted, and conversation scoped data isn't saved with a snapshot, so I believe you're sharing conversation-scoped data between flow executions in the same conversation. That allows for race conditions or illegal states if you're modifying conversation-scope data across separate flow executions, so pay attention (you've got the same concern with session scope when you're not using SWF, like when you're using multiple tabs into the same session).

Request scope is pretty much just like normal request scope. Typically you'll only use request ccope in your on-render actions in a view-state, never the on-entry section (unless you've disabled redirects on your view-state). I'll talk about that in a moment. I also like moving view-scoped attributes into request scope on a transition from a view-state if I need to use it in the next state, but not across the rest of the flow.

Flash scope is like view-scope, but it survives redirects and browser refreshes. This is best used for messages, or data which you would typically use request scope (in a non-SWF environment).

Request and flash scope are similar enough to be confusing, and you'll likely run into even more confusion if you try to use request scope without understanding how SWF uses the POST-REDIRECT-GET pattern during rendering.

Here's the deal:

A form submit is always a POST. When a view-state is entered, the on-entry actions are executed. Then a REDIRECT->GET is issues to a stable URL for the page. This wipes out request-scoped data. Next the on-render actions are executed.

You can see that if you use requestScope before a view-state is entered, or in the on-entry actions, that it will get wiped out before the on-render actions and before the page is rendered. If you use flash scope instead, it will survive the redirect, and any refreshes of the GET URL.

Since the on-render actions are executed AFTER the redirect, it's safe to put something into request scope here.

[breaux]

This is a very helpful post, I just wanted to clear up one thing that my experience has shown. That is, Flash Scope does not survive browser refreshes. I really wish it did, but it does not.