The Trinidad WindowManager defines a lifecycle for windows which includes events for windows being created, unloaded, reloaded closed. etc. The implementation is free to use as much JavaScript as it needs to in order to ensure better results, including more prompt clean up of resources. However, from an api standpoint, that is neither here nor there. Trinidad already has Window objects and it would seem natural that a consumer of the Window object would like to associate state with it. The first place they would look is on the Window object itself. From an api perspective, what is wrong with a method on the Window object that returns a Map?
Consumers already use the fact that Windows have stable identifiers and fire lifecycle events to manage the storage themselves. This api handles that task for the simpler users of the Window class. -- Blake Sullivan On Jul 19, 2010, at 2:14 PM, Gerhard Petracek wrote: > hi blake, > > why do you think trinidad would provide a better implementation? > > 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/19 Blake Sullivan <[email protected]> > Gerhard, > > If users want to use those implementations they should be able to and > Trinidad should be able to delegate to them. However, if Trinidad has a > Trinidad WindowManager installed, that WindowManager can do a much better job > than any of those implementations regarding managing the lifecycle of the > scope. In addition, if the application, or framework itself wants to > programmatically shove objects into the Map representing this scope (which > has always existed at least in the implementation), its weird that it should > all of a sudden have to start using a new set of apis. > > -- Blake Sullivan > > > On Jul 19, 2010, at 1:01 PM, Gerhard Petracek wrote: > >> hi blake, >> >> no - my suggestion was that it should be a feature which can be used >> independently. >> if users need a window scope and they use >> * cdi, they can use codi >> * spring, they can use orchestra (if we implement it there as well) >> * ~plain jsf, they should be able to use a simpler version which is >> independent of a special component lib (e.g. provided by 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/19 Blake Sullivan <[email protected]> >> 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 >>>> >>> >>> >> >> > >
