David, there will be a windowId fix in JSF-2.2. The main focus is on finally getting the state handling browser-tab aware.
See http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-949 http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1052 The user will mainly benefit from it by not loosing the client state in browser tab1 if they did too many clicks in browser tab2 ;) The internal API will be 1:1 sync with the proposed javax.faces API - we are just not allowed to do it directly in javax.faces before it's official. We will provide an abstraction for it to make it easily switchable later. LieGrue, strub ----- Original Message ----- > From: David Blevins <[email protected]> > To: MyFaces Development <[email protected]>; Mark Struberg > <[email protected]> > Cc: > Sent: Wednesday, July 18, 2012 9:46 PM > Subject: Re: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x > > Could be pretty good think to get in front of TomEE user's faces. JSF > is certainly one of the major draws and I bet people would be excited > about it. > > Do you know if this adds any changes to the javax.faces.* package? > > > -David > > > On Wed, Jul 18, 2012 at 12:00 PM, Mark Struberg <[email protected]> wrote: >> >> >> yikes, big +1 >> >> >> Would be a cool playground for getting this finally done - this issue is > open in the spec tracker since 2004 now ;) >> >> LieGrue, >> strub >> >>> ________________________________ >>> From: Gerhard Petracek <[email protected]> >>> To: MyFaces Development <[email protected]> >>> Sent: Wednesday, July 18, 2012 7:13 PM >>> Subject: [DISCUSS] [Core] window-id for myfaces-core 2.0.x and 2.1.x >>> >>> >>> hi @ all, >>> >>> >>> you might know that jsf 2.2 will introduce ClientWindow (= window-id). >>> besides the basic multi-tab handling (separation), it also allows to fix > state-saving (-> also view-scope) as well as the flash-scope for > multi-tab/window constellations. >>> >>> >>> since it's an important topic, we should discuss if it makes sense > to port it to myfaces-core 2.0.x and 2.1.x. >>> e.g. we could >try< to implement it for myfaces-core 2.0.x and > 2.1.x with a myfaces specific api -> the official api provided by myfaces > core 2.2.x could just delegates to it. >>> >>> >>> besides fixing the mentioned issues, we can also provide myfaces > specific adapters for myfaces codi and apache deltaspike. >>> users of myfaces-core v2.0.x and v2.1.x would benefit from this optional > feature (deactivated by default) and it allows us to get feedback about the > implementation (and possible issues) even before users start using > myfaces-core > 2.2.x. >>> >>> >>> the disadvantage is that it’s some extra work to do. >>> >>> >>> regards, >>> gerhard >>> >>> >
