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

Reply via email to