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? Depends on the algorithm selected to handle the windowId.
- Short answer: as soon as possible. At least before the JSF Request Processing Lifecycle starts.
- In http://wiki.apache.org/myfaces/Drafts/WindowId you can see different solutions. In the solution used in MyFaces Codi when the case is detected where a windowId needs to be created, the faces server responds to the request by sending down a special page, containing only JavaScript, that will ask for the same page as before, but with the windowId. Note that the obvious solution of a 302 redirect is not appropriate here because we want to give the client the responsibility to create the window ID.
- In other solutions it is generated by the server. So, the api is thought with the intention to provide such details as implementation details just overriding Window object. Look the part on this wiki that says something about different modes (url-Mode, client-Mode).
When is it updated?
- It is updated when the application triggers the creation of a new window. Here it also depends on the algorithm selected to handle the windowId. Each strategy to handle windowId has its flaws, and there is no perfect solution for it, because it is a failure of the underlying protocol (http).
How is it stored during the execution of the lifecycle?
- Since the windowId does not change at any moment over the view lifetime (the same view will be rendered always on the same browser window), it can be stored as a property of the view, but note the windowId is defined by the environment, and should be unique according to that. Two views can receive the same windowId if and only if the views are rendered on the same browser window, which happens when for example a GET occur in the same browser window.
Who renders the windowId to the response, and when?
- In the proposal, the ResponseStateManager should render the windowId in a hidden field, in the same moment the state hidden field is written, maybe delegating to Window object. The api proposed looks just like Flash object, but one idea is use Window object to fix Flash scope. If there is a windowId identifier, it can be used for Flash object.

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

Also is it better to have new window-ids per request, if no js is available, or one window-id for all windows?

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?

Overview

Community

Development

Sponsorship

Child pages

WindowId Proposal