Re: [Springframework-developer] Web Flow - Complex StateTransitions

[Erwin V. <erw...@er...>]

> Sure. We are currently building flows to support CRUD operations on our
> domain objects. Let's just look at the create case, as it illustrates
> our problem.
>
> The user clicks a button in our application to create a new domain
> object. This pops up a window that contains the appropriate form. At the
> bottom of the form, we have buttons for Save (create and continue
> editing), Save and New (create and new blank form), Save and Close
> (create and close popup), and Cancel (close without saving). When the
> user clicks any of the three Save buttons, the web flow must initially
> do the same thing, regardless of which one was pressed (bind and create
> domain object). After it has finished doing that, however, all three
> have different behavior.

Here I think the best solution would be to just have multiple "save states": 
a
saveAndNew, saveAndClose and so on. As I mentioned in my previous
mail, I don't think state definition reuse is a good thing. Granted, you'll 
have a few
states in your flow that use the SaveAction, but all those states are 
different
in that they tell the flow what should happen in the different situations: 
e.g.
save and new, or save and close, ...

> The Save (create and continue editing) button brings up another
> interesting issue... Because we have defined each of our CRUD operations
> in a separate web flow, we really want to forward directly to our edit
> web flow after creating (we don't want to nest a subflow). While this is
> possible using end state and a view (forward:...), it isn't possible to
> send any request attributes along to the edit flow. Therefore, it is not
> possible to send the primary key of the domain object that we wish to
> edit.

Actually, that is possible. All data in the request scope will be put in the
request attributes by Spring MVC, even when forwarding to another top-level
flow using "forward:...". The only little snag is that the top level flow 
will have
to obtain the domain object id from the request attributes, while it is 
typically
in the request parameters or flow scope (e.g. when mapped in).
If you want to reuse your flows both stand-alone, as a subflow, or as a flow
triggered via a forward, the easiest solution is to have an "input parameter 
setup"
action at the start of the flow. This action will do some logic like this:

if (id in flow scope) {
    success
}
else if (id in request attributes) {
    take from request attributes and put in flow scope
    success
}
else if (id in request parameters) {
    take from request parameters and put in flow scope
    success
}
error

> For now, we are working with a top level flow that contains subflow
> states representing each CRUD operation. By using an attribute mapper,
> we are trying to pass attributes from one subflow to another. It seems
> to be overkill however, as we really just want to be able to have end
> states that forward to a flow with attributes mapped.
>
> Again, perhaps we are missing something that would better support what
> we are trying to do?

This is indeed a bit of a heavy solution. Try the "input parameter setup 
action" and
you'll feel better :)