Intro

Leonardo proposed the APIs after a discussion with Gerhard and Mark and based on the experience with MyFaces CODI (which was based on the experience with MyFaces Orchestra).
Originally we started at http://wiki.apache.org/myfaces/Drafts/WindowId

This proposal doesn't propose a new Scope. It just proposes an id for identifying a browser-tab/window.

Suggested APIs

ExternalContext (and ExternalContextWrapper)

String #getWindowId

#setWindowId(String)

Window #getWindow

javax.faces.context.Window

#calculateWindowId(FacesContext)

Extract the windowId from the current request

#createWindowId(FacesContext)

Creates a new Window-Id. Since it might be used e.g. for pop-ups it shouldn't call #setWindowId automatically.

Further discussions needed for

#doPrePhaseActions(FacesContext)

#doPostPhaseActions(FacesContext)

#encodeXYZ

ResponseStateManager

WINDOW_ID_PARAM

//Hidden input field name to store the windowId for POST requests.
public static final String WINDOW_ID_PARAM = "javax.faces.WindowId";

Suggested Rules

Restoring the Window-Id

The window-id gets restored before the JSF Request-Lifecycle starts (e.g. directly after restoring the Flash Scope).

Levels (javax.faces.WINDOW_ID_MODE)

• none
• url
• client

none-Mode

By default Window-Id's are deactivated to ensure backward compatibility.

url-Mode

That's a very simple approach which has some disadvantages. It just adds the Window-ID to all URLs. That works if users don't open e.g. a link in a new tab (it would clone a window - that isn't nice but not worse than the HTTP session itself).

client-Mode

This mode will also add a small JS impl to the page to fix the restrictions of the 'url-Mode' (esp. via dropping the old Window-Id if users open e.g. a link in a new tab).
If a HTML5 browser gets detected, HTML5 features will be used by the JS implementation.

Open Topics

Max. window-count

Factory for the window

WindowWrapper

Window#close

JS-API

Handling of Pop-ups and Dialogs

Portlets