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

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

-Rahul

Reply via email to