Menu
▾
▴
springframework-developer
|
From: Will B. <wil...@ra...> - 2005-03-28 22:39:56
|
How should you do this in web flow? formState --(eventA, eventB, eventC)--> state1 ----> state2 --(?)--> We have a form that can submit three separate events (eventA, eventB, and eventC). In the web flow, we want all three events to go to state1, then state2, then branch to another state based on the event fired from formState. formState --(eventA)--> subFlowState1 --(eventX)--> formState --(eventB)--> subFlowState2 --(eventY)--> formState --(eventC)--> subFlowState3 --(eventZ)--> Right now, we have resorted to creating a subFlow that contains state1 and state2 and then defining three separate subFlow states (subFlowState1, subFlowState2, and subFlowState3) in the parent flow using the same subFlow definition with different transitions. Because we have several cases like this, the number of subFlows required is getting a little unwieldy. Anyone else have any suggestions as to how we could do this in a better way? Thanks, Will Butler |
|
From: Keith D. <ke...@in...> - 2005-03-28 23:13:34
|
Hmm.... Erwin and I were discussin the other day whether or not we needed flow state/event history. Seems like if we had it, that might be a better solution to your problem. Can you describe the use case for what you're trying to do, just to get some more background? -----Original Message----- From: spr...@li... [mailto:spr...@li...] On Behalf Of Will Butler Sent: Monday, March 28, 2005 5:40 PM To: spr...@li... Subject: [Springframework-developer] Web Flow - Complex State Transitions How should you do this in web flow? formState --(eventA, eventB, eventC)--> state1 ----> state2 --(?)--> We have a form that can submit three separate events (eventA, eventB, and eventC). In the web flow, we want all three events to go to state1, then state2, then branch to another state based on the event fired from formState. formState --(eventA)--> subFlowState1 --(eventX)--> formState --(eventB)--> subFlowState2 --(eventY)--> formState --(eventC)--> subFlowState3 --(eventZ)--> Right now, we have resorted to creating a subFlow that contains state1 and state2 and then defining three separate subFlow states (subFlowState1, subFlowState2, and subFlowState3) in the parent flow using the same subFlow definition with different transitions. Because we have several cases like this, the number of subFlows required is getting a little unwieldy. Anyone else have any suggestions as to how we could do this in a better way? Thanks, Will Butler ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Will B. <wil...@ra...> - 2005-03-29 13:33:33
|
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. 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. 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? Thanks, Will On Mon, 2005-03-28 at 18:12 -0500, Keith Donald wrote: > Hmm.... Erwin and I were discussin the other day whether or not we needed > flow state/event history. Seems like if we had it, that might be a better > solution to your problem. Can you describe the use case for what you're > trying to do, just to get some more background? > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On Behalf Of > Will Butler > Sent: Monday, March 28, 2005 5:40 PM > To: spr...@li... > Subject: [Springframework-developer] Web Flow - Complex State Transitions > > How should you do this in web flow? > > > formState --(eventA, eventB, eventC)--> state1 ----> state2 --(?)--> > > We have a form that can submit three separate events (eventA, eventB, > and eventC). In the web flow, we want all three events to go to state1, > then state2, then branch to another state based on the event fired from > formState. > > > formState --(eventA)--> subFlowState1 --(eventX)--> > formState --(eventB)--> subFlowState2 --(eventY)--> > formState --(eventC)--> subFlowState3 --(eventZ)--> > > Right now, we have resorted to creating a subFlow that contains state1 > and state2 and then defining three separate subFlow states > (subFlowState1, subFlowState2, and subFlowState3) in the parent flow > using the same subFlow definition with different transitions. > > Because we have several cases like this, the number of subFlows required > is getting a little unwieldy. Anyone else have any suggestions as to > how we could do this in a better way? > > Thanks, > > Will Butler > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Erwin V. <erw...@er...> - 2005-03-29 21:52:48
|
> 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 :)
|
|
From: Will B. <wil...@ra...> - 2005-03-29 23:15:24
|
I am now trying the "forward:..." approach, but when doing a forward to
another top level flow, the flowId of the original flow is still in the
request parameters. This causes an error in the
HttpServletFlowExecutionManager, since the flowId is for the first top
level flow... What can I do about that?
Thanks,
Will
> > 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
|
|
From: Erwin V. <erw...@er...> - 2005-03-30 07:48:32
|
This is a bug. It was possible in the original Ervacon web flow
implementation and should still be possible.
Fixing....
Done. I've added a unit test to verify the behaviour. Thanks for catching
this!
Erwin Vervaet
erw...@er...
----- Original Message -----
From: "Will Butler" <wil...@ra...>
To: <spr...@li...>
Sent: Wednesday, March 30, 2005 1:15 AM
Subject: Re: [Springframework-developer] Web Flow - Complex StateTransitions
>I am now trying the "forward:..." approach, but when doing a forward to
> another top level flow, the flowId of the original flow is still in the
> request parameters. This causes an error in the
> HttpServletFlowExecutionManager, since the flowId is for the first top
> level flow... What can I do about that?
>
> Thanks,
>
> Will
>
>> > 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
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
|
|
From: Erwin V. <erw...@er...> - 2005-03-29 21:16:24
|
> How should you do this in web flow? > > > formState --(eventA, eventB, eventC)--> state1 ----> state2 --(?)--> > > We have a form that can submit three separate events (eventA, eventB, > and eventC). In the web flow, we want all three events to go to state1, > then state2, then branch to another state based on the event fired from > formState. > > > formState --(eventA)--> subFlowState1 --(eventX)--> > formState --(eventB)--> subFlowState2 --(eventY)--> > formState --(eventC)--> subFlowState3 --(eventZ)--> > > Right now, we have resorted to creating a subFlow that contains state1 > and state2 and then defining three separate subFlow states > (subFlowState1, subFlowState2, and subFlowState3) in the parent flow > using the same subFlow definition with different transitions. > > Because we have several cases like this, the number of subFlows required > is getting a little unwieldy. Anyone else have any suggestions as to > how we could do this in a better way? I'm not sure I understand why your solution leads to an unwieldy number of subflows: e.g. in your example you have 3 subflow states, but only 1 subflow definition right? Anyway, I have found it to be a best practice to not try and reuse a state definitions in a flow. A state reuses an action implementation, but is not itself intented to be a reusable component. This can lead to flows that are a bit more elaborate in definition, but they will also be very simple to read. If you really don't like that, you could also put some discriminating value in the flow scope and use that to implement a switch in your flow: e.g. have a SignalEventAction that takes the discriminator from the flow scope and returns it as an event. Erwin |
