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

The purpose of the WindowId API is to explicitly establish an association between a browser view and a UIComponent hierarchy rooted at a single UIViewRoot. A browser view may be a tab, a window, or even a pop-up.

Lifecycle

This section explains the touch-points of the existing JSF Request Processing Lifecycle and the WindowId API.

• When is the windowId created?
• When is it updated?
• How is it stored during the execution of the lifecycle?
• Who renders the windowId to the response, and when?

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

Concrete rules for a Request-Token

Max. window-count

Factory for the window

WindowWrapper

Window#close

JS-API

jsf.getWindowId(rootId)

Parameters

• rootId, type:String, optional

returns the current window id of the current window/dialog.
The parameter rootId, specifies the rootId which has a reference to the windowId to be determined.
(needed for inframe subdialogs which might have different window ids)

If no viewRootId is given or the viewRootId is null the central viewRootId is used
(this goes hand in hand with the jsf.js ViewRoot extensions filed for jsf 2.2)

If the windowId mechanism is off, then this method will return null, if the mechanism is on
then this method will always return the windowId depending on the rootId or viewRoot.

Changes in the behavior on the ajax side

On the ajax side the parameter javax.faces.WindowId must be passed down. If the parameter is stored
in a hidden field like it is proposed before then this happens automatically.
If not then the jsf.ajax.request must add this value before submitting the form, if present on the window url.

Under discussion, additional methods needed?

Any api needed for handling the open in new tab usecase, http get usecase, open or close windows?

Handling of Pop-ups and Dialogs

Rules for automated entry points (to avoid that new windows get created and are around for a long time)

Topics for JSF 2.3+

Portlets

Keepalive (the frequency should decrease over time to allow proper cleanup in case of max. window-count)

Optional onunload hook (in some browsers it just works with a sync. request - and not with async. requests)