hi blake, it's similar to the conversation context id of orchestra - we just have an id for every window.
(in case of @WindowScoped we just add a component to the view-root (before the page gets rendered). the window id is stored as state of the component. in case of jsf 1.2 and redirects we need an url parameter for the get-request. the implementation is pluggable - so it's possible to provide a custom implementation for storing and restoring the information. in case of jsf 2.0+ and redirects you won't see an url parameter. in this case we use the flash scope to store the required information.) i'll add all the details to the wiki page [1]. i've finished the implementation of the first draft by the end of last week. so i've to cleanup some parts and i've to write further javadoc and documentation. regards, gerhard [1] http://wiki.apache.org/myfaces/Extensions/CDI/DevDoc/Conversations http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/19 Blake Sullivan <[email protected]> > What code actually associates the scope with the browser windows? For > example, in Trinidad, we have a WindowManager tasked with that job. > > -- Blake Sullivan > > On Jul 17, 2010, at 1:47 PM, Gerhard Petracek wrote: > > hi blake, > > @WindowScoped (provided by myfaces codi) is a portable extension for cdi. > therefore not every project will be able to use it. > > anyway, imo it would be better to provide a cdi independent version of it > e.g. in myfaces-orchestra and/or myfaces-commons. > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2010/7/17 Jakob Korherr <[email protected]> > >> Hi Blake, >> >> Just FYI: we have also implemented a window scope for MyFaces Codi >> (ext-cdi). Maybe you want to take a look at it ;) >> >> Regards, >> Jakob >> >> 2010/7/17 Blake Sullivan <[email protected]> >> >> We currently have scopes for: >>> Application >>> Session >>> PageFlow >>> View >>> >>> I propose that we add a Map associated with each window or tab that the >>> user is interacting with. This would slop into the scope hierarchy between >>> the Session and PageFlow scopes. We would also expose the storage for the >>> current window on the RequestContext. If no WindowManager was exposed and >>> therefore there was no current Window, this Map would be the SessionMap. >>> >>> For high availability, each of the attributes stored in a Window's map >>> would be stored as separate attributes in the Session. >>> >>> At least initially, we would not expose this map directly through its own >>> top-level windowScope EL property. >>> >>> Proposed apis: >>> >>> RequestContext: >>> >>> /** >>> * Returns a Map of objects associated with the current window if any. >>> If there is no >>> * current window, the Session Map is returned. >>> * @return Map for storing objects associated with the current window. >>> * @see org.apache.myfaces.trinidad.context.Window#getWindowMap >>> */ >>> public Map<String, Object> getWindowMap() >>> >>> Window >>> >>> /** >>> * Returns the Map for storing data associated with this Window object. >>> If the environment is >>> * configured for fail-over, the contents of this Map must be >>> Serializable. >>> * @return The client data storage Map. >>> */ >>> public abstract Map<String, Object> getWindowMap(); >>> >>> Since we would provide a default implementation of getWindowMap using >>> import org.apache.myfaces.trinidadinternal.util.SubKeyMap, we would also >>> have to make SubKeyMap public as well. >>> >>> >> >> >> >> >> -- >> Jakob Korherr >> >> blog: http://www.jakobk.com >> twitter: http://twitter.com/jakobkorherr >> work: http://www.irian.at >> > > >
