Yes, stored in session, however they are not overwritten on concurrent requests because if a new scope is opened, and there are any scopes open, a request query parameter is added:
https://github.com/seam/faces/blob/develop/impl/src/main/java/org/jboss/seam/faces/context/RenderScopedContext.java#L118 This has the benefit of avoiding the ugly parameter if only one window is open at a time, or only one request is submitted at a time. I highly recommend a strategy like this for window-scope as well if it's possible to identify when you have more than one browser open while doing this... ~Lincoln On Mon, Oct 15, 2012 at 12:24 PM, Mark Struberg <[email protected]> wrote: > Thanks Lincoln, indeed that sounds very useful. > > Where do you store it between the requests? I guess in the Session, right? > Thus 2 concurrent requests would overwrite each other, isn't? > > I think that's another neat example which should actually be > per-browser-tab. > > LieGrue, > strub > > > > > ----- Original Message ----- > > From: "Lincoln Baxter, III" <[email protected]> > > To: [email protected] > > Cc: > > Sent: Monday, October 15, 2012 5:58 PM > > Subject: Re: [DISCUSS] JSF Scopes > > > > Just for clarification - @RenderScoped holds contextual objects until the > > next "Render Response" phase is completed, at which point the scope is > > cleared. IMO, much simpler than the flash, and much more intuitive - > > perfect for holding Faces Messages or other "must show up once" type > > values. > > > > ~Lincoln > > > > On Mon, Oct 15, 2012 at 7:55 AM, Gerhard Petracek < > > [email protected]> wrote: > > > >> @ #1: > >> not in case of a redirect. you can keep them by using a jsf-api > manually, > >> but in this case they will be stored in the flash-scope... -> you have > 2 > >> disadvantages: > >> 1) you have to do it manually > >> 2) you have to wait for jsf 2.2 to get a flash-scope which works as > >> expected > >> > >> @ #2: > >> you are talking about something completely different. the > window-context > >> isn't a cdi context implementation. > >> it's a mixture of a manager for the current window and the > > representation > >> of the client-window which contains different properties (or > information > >> like faces-messages which need to survive a redirect) as well as > different > >> scope-types. > >> please have a look at the link i provided with my first mail. there > you see > >> that the window-scope is handled like any other scope bound to a > window (it > >> just has a different strategy to expire and you can't use features like > >> groups). > >> -> only if you close the window-context (again: which is >not< the > >> window-scope), you close all scopes bound to a window and you drop the > >> information for/about this window (like the faces-messages). > >> > >> regards, > >> gerhard > >> > >> > >> > >> 2012/10/15 Mark Struberg <[email protected]> > >> > >> > I don't understand. The FacesMessages are held by the > > FacesContext. > >> > > >> > If we talk about a WindowContext we always have to distinguish > between > >> the > >> > list of active window contexts and the 1 which is active for the > > current > >> > request. > >> > > >> > LieGrue, > >> > strub > >> > > >> > > >> > > >> > > >> > ----- Original Message ----- > >> > > From: Gerhard Petracek <[email protected]> > >> > > To: [email protected] > >> > > Cc: > >> > > Sent: Monday, October 15, 2012 11:26 AM > >> > > Subject: Re: [DISCUSS] JSF Scopes > >> > > > >> > >t hat isn't correct. i thought about that as well, but some > > people use > >> it > >> > > instead of std. cdi conversations to get rid of the > > disadvantages. > >> > > -> if you would close (or restart) the window-scope and you > > don't have > >> an > >> > > independent window-context, you would lose the information stored > > for > >> the > >> > > current window (like faces-messages you need in case of a > > redirect). > >> > > > >> > > regards, > >> > > gerhard > >> > > > >> > > > >> > > > >> > > 2012/10/15 Mark Struberg <[email protected]> > >> > > > >> > >> Well, the Window Context is just the backing for > > @WindowScoped. We > >> > should > >> > >> try to not overengineer things. > >> > >> > >> > >> All the Conversation scopes are based on the WindowContext. > >> > >> We should definitely get @ViewAccessScoped as this is > > something most > >> > users > >> > >> really love. > >> > >> But I'm sure there is also quite some interesting stuff > > in Seam3 we > >> > > should > >> > >> look at.Thanks Antoine so far for the start. Anything > > missing in his > >> > list? > >> > >> > >> > >> LieGrue, > >> > >> strub > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> ----- Original Message ----- > >> > >> > From: Gerhard Petracek > > <[email protected]> > >> > >> > To: [email protected] > >> > >> > Cc: > >> > >> > Sent: Monday, October 15, 2012 11:00 AM > >> > >> > Subject: Re: [DISCUSS] JSF Scopes > >> > >> > > >> > >> > imo we should create: > >> > >> > - a client-window adapter (as spi) for a 1:1 delegation > > to the > >> > >> > client-window-api of jsf 2.2+ > >> > >> > - a client-window implementation for jsf 2.0 and 2.1 > >> > >> > - a window-context similar to what we have in codi > > (that isn't the > >> > >> > window-scope - see [1]) > >> > >> > - scopes + a fine grained api to manage them (the > > window-scope is > >> > also > >> > >> just > >> > >> > a kind of conversation which is very similar to std. > > cdi > >> > > conversations). > >> > >> > > >> > >> > we could think about a more specialized spi per scope > > (since we saw > >> > > that > >> > >> > some edge-cases with the ViewAccessScoped required > > internal > >> > > workarounds) > >> > >> > and we could skip some SPIs for now. > >> > >> > > >> > >> > the first step is an agreement about the api, spi and > > the basic > >> > > behavior. > >> > >> > > >> > >> > regards, > >> > >> > gerhard > >> > >> > > >> > >> > [1] > >> > >> > > >> > >> > >> > > > >> > > >> > > > https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-Scopes > >> > >> > > >> > >> > > >> > >> > > >> > >> > 2012/10/15 Mark Struberg <[email protected]> > >> > >> > > >> > >> >> Hi folks! > >> > >> >> > >> > >> >> I finally like to start working on JSF scopes for > > DeltaSpike. > >> > >> >> > >> > >> >> We already have the following 2 features > > implemented and working > >> > >> >> (including unit tests): > >> > >> >> > >> > >> >> * JFS @ViewScoped Context support > >> > >> >> * JSF-2-CDI scope mapping. > >> > >> >> * injecting typesafe JSF messages > >> > >> >> > >> > >> >> > >> > >> >> The next item on my list is the > >> > >> >> > >> > >> >> * @WindowScoped > >> > >> >> > >> > >> >> > >> > >> >> This is kind of a Session per browser tab. Does > > Seam3 provide a > >> > > similar > >> > >> >> mechanism? If not, I suggest taking a peak what we > > do over in > >> > > CODI. > >> > >> >> There is quite some trickery necessary, but we > > finally found a > >> > > solution > >> > >> >> which works pretty well [1]. This is also the base > > of the > >> > > windowId > >> > >> feature > >> > >> >> most probably coming with JSF-2.2 btw. > >> > >> >> > >> > >> >> > >> > >> >> Once we have the @WindowScoped support we can > > build much more > >> > > fine > >> > >> grained > >> > >> >> conversation stuff which is perfectly browser tab > > aware based on > >> > > it. > >> > >> >> > >> > >> >> > >> > >> >> Wdyt? > >> > >> >> > >> > >> >> Any cool features related to this to look at in > > Seam3? > >> > >> >> Who is interested to help hacking this stuff? > >> > >> >> > >> > >> >> > >> > >> >> LieGrue, > >> > >> >> strub > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> [1] > >> > >> > > https://cwiki.apache.org/confluence/display/EXTCDI/JSF+WindowHandler > >> > >> >> > >> > >> >> > >> > >> > > >> > >> > >> > > > >> > > >> > > > > > > > > -- > > Lincoln Baxter, III > > http://ocpsoft.org > > "Simpler is better." > > > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."
