Thanks Gerhard. Did you want Trinidad to be configurable to delegate to Orchestra if its available, in this case?
-- Blake Sullivan On Jul 19, 2010, at 12:23 AM, Gerhard Petracek wrote: > 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 >> > >
