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 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 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
