Hello everyone since the discussion goes into various directions and
there were some errors in most recent proposal
which then dragged themselves into the codebase, I had a really long IRC
discussion with the CODI guys who did the initial proposal (and are not
part of the EG) on IRC who asked me to speak here on their behalf. To
get things mostly right this time.
Hence here is an updated proposal which fixes the issues which were
accidentally pushed in. (WindowId per portlet is not needed)
https://cwiki.apache.org/confluence/display/MYFACES/WindowId+Proposal
And here is a summary as baseline for discussions/questions and future
revisions where CODI stands and the proposal and where we stand in the
discussion. This is a baseline document which will be revisioned in the
future to keep things together. Since the entire windowId stuff is if
you try to cover the corner cases rather complex.
I am not sure if I have covered our area fully correctly, but we can
roll future revisions of this document.
So please read the proposal first and then the document here. And also
feel free to ask the CODI guys, if things are unclear. You can meet them
on the ##jsf and #myfaces channel or I will be happy to forward
questions and answers (they monitor this list anyway)
1 Status quo CODI:
------------------------------------------------
1.1 General Definitions regarding Window-ID
------------------------------------------------------------
a) a window-id always refers to the tab (because 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]
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.