Hi guys, > 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.
certainly this makes sense from your current point of view - but it does not help you with more people adopting Trinidad. Trinidad is already widely seen as a rather monolithic block of something which is just too large - splitting this up into parts which deal with clearly defined responsibilitiies would make a lot more sense. I am not saying you can add a small API more to this monolithic block, I am just saying it would make sense to at one point of time split this up into something which is reusable elsewhere in the world. And if you put your ASF hat on, Matthias, you know this ;) best regards, Martin >> 2010/7/19 Blake Sullivan <blake.sulli...@oracle.com> >>> >>> 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 <blake.sulli...@oracle.com> >>>> >>>> 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 <jakob.korh...@gmail.com> >>>>> >>>>> 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 <blake.sulli...@oracle.com> >>>>>> >>>>>> 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 > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
