On 8/28/06, Rahul Akolkar <[EMAIL PROTECTED]> 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. 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
