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."
