On 12/16/06, Rahul Akolkar <[EMAIL PROTECTED]> wrote:
On 12/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: craigmcc > Date: Fri Dec 15 16:51:06 2006 > New Revision: 487741 > > URL: http://svn.apache.org/viewvc?view=rev&rev=487741 > Log: > Refine the dialog framework APIs as a foundation for improving handling of > browser navigation buttons: > > * Provide an "escape hatch" (getOpaqueState/setOpaqueState) such that a > DialogContext implementation can optionally request that additional > information be saved and restored with each JSF component tree that > is rendered. There is a restriction that any such opaque state data > must be Serializable. > > * Modify the two existing implementations to obey the updated API > contract,but otherwise do nothing at the moment. > > * Refactor DialogPhaseListener a bit: > > - Make Constants.CONTEXT_ID_ATTR a private constant in this class. > This information is a private implementation detail. > > - Create a private beforeRenderResponse() method, parallel to the > existing afterRestoreView() method, in case we have to deal with > more phases later. These are private APIs, so no disruption of > apps can occur > > - Implement the saving and restoring of opaque data, if requested > by the DialogContext implementation. If saved, it will be stored > as another generic attribute on the view root component, but (again) > this is an implementation detail not visible to callers. > > SHALE-61 > <snip/> The last experiment I did on this a while ago (link in JIRA), I was able to recover by trying to map the incoming view ID to the state ID (using an adhoc scheme) before proceeding in the dialog. The opaqueState addition is clearly better for this -- I think only the state ID String should be enough for the Commons SCXML impl (ofcourse, String may not hold for all dialog imps). I plan on digging into this towards filling up the shale-dialog-scxml bits early next week (Mon/Tue).
Me too (on the basic impl). The subdialog issue doesn't exist in the Commons SCXML impl (its one
machine, rather than a stack of machines at runtime) -- ofcourse, the downside is that IDs in the parent and subdialog need to be unique (there are a few best practices to mitigate that, plus the next WD may have other recommendations regarding this, IIUC).
The experiment I'm trying on the Basic impl is to declare, via a context init parameter, a "strategy" value for what getOpaqueData() should return, with the default being "none" as is the current behavior. I'm looking at a couple of possible strategies: * Current state name (+ some way to tell if you crossed a subdialog boundary so you can throw an exception) * The entire stack of Position instances, which includes the "data" objects at each level, so unwinding and rewinding changes everything. An interesting question to contemplate is what should happen with event firing with our shiny new DialogContextListener interface. -Rahul
Craig
