>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > On 9/16/06, Gary VanMatre wrote: > > > > >From: "Craig McClanahan" > > > > > > On 8/28/06, Rahul Akolkar wrote: > > > > > > > > Thinking aloud about the mandatory feature 11 on the > > > > DialogManagerFeature wiki page [1]. Just noted that SWF has some of > > > > the same limitations, and its possible to drop traces into the browser > > > > atleast with the continuation configurations I was looking at. > > > > > > > > In some previous experiments [2] as part of SHALE-61 [3], the approach > > > > taken was splitting the dialog's per turn processing into two bits: > > > > (a) Aligning the server-side state machine, if necessary > > > > (b) Once aligned, triggering the postback event on it > > > > > > > > > There are at least some use cases where re-syncing the server side state > > is > > > not necessary. For example, a simple wizard dialog that just collects > > data > > > won't necsesarliy suffer if the same data gets submitted twice. It's > > > scenarios where things like database updates have already taken place ( > > i.e. > > > what might happen in a typical "finish" state), where you'd want to deal > > > differently with syncing, even in the same dialog. > > > > > > I guess a fundamental question here is, can we actually recognize that > > these > > > events have occurred? If so, we could do something like trigger server > > side > > > events that would notify the dialog context, and it could make its own > > > adjustments (perhaps, for example, maintaining an undo log that gets > > > triggered when you press the back arrow). At the same time, the dialog > > > context could recognize special events that mean "don't make any further > > > changes" -- although, that is going to get tricky to implement if the > > view > > > states inside the dialog has input fields bound to properties on the > > context > > > data object. It'd probably need to cache away the values that were > > actually > > > used, and stop paying attention to updated input fields. > > > > > > As long as the state machine is residing on the other side of the > > > > network boundary, it seems a bit unclear whether (a) can at all be > > > > avoided. The effort for the developer, however, can be reduced if (a) > > > > is transparent to the developer, which was the exercise in [2] where > > > > the state machine was "decorated" with some additional transitions > > > > which realigned the dialog based on the view that posted back. I hear > > > > JSF 1.2 alleviates some browser button issue, is it possible for > > > > anyone to elaborate on that? > > > > > > > > > The improvements were primarily to match up the correct component tree, > > in > > > the face of the user pressing navigation buttons, when state is saved on > > the > > > server side. This part already worked for client side state saving, > > because > > > the saved state would get resubmitted along with the rest of the form. > > > > > > I think this only helps our situation, though, if the dialog state were > > also > > > saved and restored in the component tree itself (instead of just saving > > a > > > dialog identifier). I have concerns about what this could do to the size > > of > > > the serialized component tree for client side state saving -- but > > perhaps we > > > could figure out how to make this conditional to avoid that potential > > > problem. > > > > > > > Saving and restoring the dialog context to the views state, would might > > solve a couple of issues (undo state and restoring the context to > > a previous state). I think myfaces has a component to do that but > > I agree that the client state is not the right place for a large chunk > > of data. > > > > However, I really like what you have done with the dialog id. You've > > tucked it away under the view root. In this case, this state is saved > > with the view but it's only a simple integer. > > > > Maybe a similar concept would work for tracking the dialog context. > > What if the dialog manager tracked the context with a sequence id. > > The sequence id, a simple integer, could be saved in the view state > > with the dialog id. Then when the dialog is restored, it could use > > the sequence and id to resume execution. > > > Are you thinking about a "generation number" of the state of the context, > that would increment each request? That could work if the server maintained > a copy of each generation somehow, that you could go back to when the > repeated request came in. >
Ya, that way the only state the view has to worry about is the generated number along with the dialog id. We could also use the renderer decorator trick that we are using for commons validator to inject a couple hidden attribute into the form for the generated number and the dialog id. In addition add the parameter to the outputLink? BTW, I'm going to take a try at moving commons valiator out of the core. I might need some help with the clean up. Does "shale-commons-validator" sound ok for the project under "framework"? > On the other hand, there will be use cases where the application does *not* > want to allow the user to simply redo a previous generation. Consider the > checkout from an ecommerce app -- the user is going to be unhappy if the > system lets him or her check out, then use the back arrow, then check out > again and get two orders (and two charges to the credit card). > > I think we're going to need some sort of framework functionality that allows > the generation stuff to be disabled, if we go this direction. > Good point. That double charge scenario would really be a drag :-) Maybe we could have two implementations of the dialog manager? Gary > Craig > > If you wanted a undo, type of processing, the sequence id might > > be used as keys into a working db table. > > > > > > Gary > > > > > The additional concern, ofcourse, is whether (a) is always the right > > > > thing to do i.e. whether the side-effects of progressing the dialog > > > > are actually reversible / overwriteable (whether the underlying > > > > datamodel can be rolled back) -- what should be done if it can't, and > > > > what should be the authoring best practice (some dialog "tokens" etc.) > > > > > > > > -Rahul > > > > > > > > [1] http://wiki.apache.org/shale/DialogManagerFeature > > > > [2] http://people.apache.org/~rahul/shale/align-dialog/ > > > > [3] https://issues.apache.org/struts/browse/SHALE-61 > > > > > > > > > > > > > Craig > >
