>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > 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. 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
