On Mon, Jul 19, 2010 at 10:01 PM, Gerhard Petracek <[email protected]> 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)
right now for this feature, I think a close integration to Trinidad does make sense, since we already have window handling, including lifecycle and an (complete) event system. Hence the proposed API is "just" a small addition. > 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 o...@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 >>> >>> >> >> > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
