hi blake, @events: libs like codi might benefit from such additional events. we could think about a trinidad-support module.
@trinidad window map: i'm still not convinced. i would use a scope provided by libs like orchestra, codi,... if there aren't quite a lot of users who use trinidad without such additional frameworks, i would vote -0. 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/21 Blake Sullivan <[email protected]> > Gerhard, > > Do you have any comments on this? > > -- Blake Sullivan > > On Jul 19, 2010, at 2:37 PM, Blake Sullivan wrote: > > 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 >>>>> >>>> >>>> >>>> >>> >>> >> >> > > >
