There was a small error:
1 Status quo CODI:
------------------------------------------------
should mean
1 Suggestions based on the status in CODI:
------------------------------------------------
Outside of that everything is correct now from my side.
Werner
On Fri, Mar 2, 2012 at 10:31 AM, Werner Punz <werner.punz_at_gmail.com> wrote:
> 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.
>
>
>
>
>