Hi guys, generally I'd like to see this in Trinidad for reasons as stated earlier.
few more comments inline: On Wed, Jul 21, 2010 at 4:52 AM, Gerhard Petracek <[email protected]> wrote: > hi blake, > @events: > libs like codi might benefit from such additional events. we could think > about a trinidad-support module. +1 on such a codi-trinidad 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. Not everybody is using CDI and/or Spring. I think, on long term we may want one clean and independent API, where all these projects offer an implementation for a window/event system: -CODI -Orchestra -Trinidad -etc However, right now, Trinidad has the base already and adding a new toolset to the belt feels kinda wrong. Again +1 on this to be inside of Trinidad. This does not mean that we could work on a better future version of a more unified API, for this. Right? -Matthias > 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 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
