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 client window and a UIComponent hierarchy rooted at a single UIViewRoot.
This section explains the touch-points of the existing JSF Request Processing Lifecycle and the WindowId API.
This proposal doesn't propose a new Scope. It just proposes an id for identifying a browser-tab/window.
Extract the windowId from the current request
Creates a new Window-Id. Since it might be used e.g. for pop-ups it shouldn't call #setWindowId automatically.
//Hidden input field name to store the windowId for POST requests.
public static final String WINDOW_ID_PARAM = "javax.faces.WindowId";
The window-id gets restored before the JSF Request-Lifecycle starts (e.g. directly after restoring the Flash Scope).
By default Window-Id's are deactivated to ensure backward compatibility.
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). Furthermore, a "drop" script detects the "open in new tab" use-case and drops the current window-id and requests the page again with a new window-id.
There must be a per-use way to disable the inclusion of the URL in a link.
This mode allows that a JSF implementation or RenderKit provides a proprietary mode which is even more optimized - e.g. using an intermediate page which can be stored in the local-storage of HTML5.
Values: custom:name of the mode e.g.: <param-value>custom:intermediate-page</param-value>
Also is it better to have new window-ids per request, if no js is available, or one window-id for all windows?
returns the current window id of the current window/dialog.
The windowId must be present in the url otherwise a null is returned.
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.
Any api needed for handling the open in new tab usecase, http get usecase, open or close windows?
1 Suggestions based on the status in CODI:
------------------------------------------------
1.1 General Definitions regarding Window-ID
------------------------------------------------------------
a) a window-id always refers to the tab to allow a proper isolation (it should/can be stored in the browsers window.name)
b) a window-id always is unique in the session of the user. A session contains exactly 1 window-id per browser tab.
c) rendering multiple window-ids per browser tab is not allowed hence also not in portlet mode.(because the window-id is stored in the browsers window.name)
1.2 Modes and special cases
---------------------------------------
1) no mode: no window-id is generated - legacy mode
2) url-Mode: the window-id is stored in the browser url
hidden fields are shadowed into the forms also to keep the window-id support for post requests.
windowId parameters are added to http get links.
Server side the windowId needs to be processed over the sent windowId parameters.
This is even the same for Portlet cases since the window-id has
a referential pattern of 1:n to the scopes
The same goes for sub scopes.
If a new tab is opened a Javascript script detects that use case and basically re-renders the page with a new window-id dedicated to the tab.
How that is done is up to the implementation. The basic implementation is to check for an empty or non-matching window.name and then redirect the page without a window-id in the url to force a new one.
3) custom-Mode:
Allows to use a custom mode provided by the JSF implementation or a custom RenderKit.
Value: custom:[name of the mode] e.g.: <param-value>custom:intermediate-page</param-value>
TBD
5) Bookmark case or a href … target=_new: This is handled in CODI by opening a new window-id or recycling the old one (bookmarking case with same windowid in the bookmark as the existing one)
2. Status quo of the spec discussion compared to CODI:
---------------------------------------------------------------------------
a) URL mode: checked is discussed.
b) overriding the URL not yet fully discussed: since it opens another can of worms (f)
c) synchronizing the URL with hidden fields: checked is discussed due to having hidden fields holding javay.faces.windowId
d) Open in new tab script: soon under discussion
e) hidden field only mode: Breaks e.g. the get requests and browser refresh, therefore not doable
f) jsf.getWindowId can be simplified (is now in the proposal) if (b) is omitted or postponed, otherwise it needs to be investigated, if the current implementation can hold. The entire code was programmed under the assumption that we have a window-id per Portlet use case, which cannot hold for (d) see also (g)
g) Ajax protocol ViewRoot either redundant, or in case of (b), cannot work on ViewRoot level
because single forms can if override is enabled be updated with different ViewRoots.
(my mistake i was under the wrong assumption between window-id and scope and because of (g) )
h) window-id per Portlet, is there a use case for that one? Especially since it breaks the new
tab detection jsf.getWindowId can hold for (g)
i) server side part of the window-id handling, where to be rendered, under discussion
h) open point: what to do with the a hrefs and pages where you don´t want to have a window id. Should a link to a different window-id be possible, how can you turn it off/on.