On Wed, Jul 21, 2010 at 10:00 PM, Gerhard Petracek <[email protected]> wrote: > hi blake, > basically you can use an external map in cdi context implementations. > however, with cdi you shouldn't do that. "everybody" could just change or > clear it and you would bypass important mechanisms of cdi. i would vote -1 > for such an approach.
I think the best is to continue with the default being part of Trinidad and start thinking about a *smart* CODI-Trinidad module. I hope it makes sense to others as well. > if you plan that trinidad hosts an own window scope > (based on cdi), you have to re-implement parts which are available in > portable cdi extensions like codi. why should Trinidad integrate CDI, at this point? We are just polishing an exiting feature. No need to integrate CDI yet > or trinidad just provides some additional > events which would allow a better compatibility (if there are issues). > plain trinidad ... jsf + trinidad without any other lib (in this case: libs > for additional scopes). > @trinidad scopes: so, for pageFlowScope: we could do the same trick: let's work on a Trinidad-CODI module, which allows you to pull in CDI, if you want. It does sound right to me. It would be a great start and nobody said that the CDI-based stuff will NEVER be the default. Why not starting with the modules? -Matthias > that's my point - besides some other great frameworks, we now have a spec. > for scopes which allows portable extensions. imo trinidad is just the wrong > place for adding new scopes. users can just use e.g. trinidad dialogs in > combination with the access scope provided by libs like codi. > and with trinidad support modules we could close potential gaps. > 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]> >> >> On Jul 21, 2010, at 10:05 AM, Gerhard Petracek wrote: >> >> hi blake, >> @trinidad window map & cdi: >> we are just interested in some special events like a page-refresh >> (triggered by the user). >> everything else is handled internally. -> (currently) i don't see a reason >> for using such an external map. >> >> I'm not sure what you are asking here. There should be a small number of >> requirements on the provider of a scope implementation. The CDI code should >> be able to plug into any scope provider. I would assume that part of that >> contract would be providing a Map as a storage abstraction and some kind of >> lifecycle. If Trinidad users want to use CDI to inject beans into the >> window scope, it would be nice for them to be able to configure Trinidad as >> the implementor of the window scope. >> >> @stand-alone trinidad window map: >> do you mean there are some internal project guidelines like: >> the project has to use plain trinidad. >> ? >> >> I'm not sure what you mean by "plain". The requirement is that the >> Trinidad WindowManager needs to be running on the requests that want to use >> the Trinidad apis to access the per-window map, since the window map is >> retrieved from the current window. >> >> @page flow scope: >> that's a similar story - besides @WindowScoped codi provides >> @ConversationScoped (similar to the conversations of orchestra) as well as >> @ViewAccessScoped (similar to the access scope of orchestra). >> >> That's right and the implementations of all of the scopes are pluggable in >> Trinidad so that they can delegate to any installed implementation. >> -- Blake Sullivan >> >> 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]> >>> >>> On Jul 21, 2010, at 5:02 AM, Gerhard Petracek wrote: >>> >>> hi mark, >>> nobody said that it would harm (at least i'm not aware of technical >>> issues). >>> (maybe some people would use it even though they shouldn't - e.g. because >>> they have an alternative which should be used in their application/s.) >>> furthermore, i agree with martin - most projects are using (or will use) >>> one of the mentioned frameworks. >>> the questions are: >>> who would use this feature? >>> >>> Anyone who needed to store information on a per window basis and could >>> live without managed bean support. We already had several teams trying to >>> build this on their own. The finer-grained scopes, such as page flow scope, >>> should be built on top of this directly. As teams have been dealing with >>> fail-over issues, they are finding that they want this. >>> >>> - new projects? i don't think so. >>> >>> If they had the above issues, sure. >>> >>> - existing projects? would they upgrade to a new version of trinidad >>> just for using this feature? >>> >>> I don't understand. If the bar for new features is that they must be the >>> driving force for customers to upgrade, very few features would be added to >>> any project. >>> -- Blake Sullivan >>> >>> maybe it's the right time to discuss our plans for the future of >>> trinidad. (at least if we should use the maven shade plugin for modularizing >>> trinidad. in such a case we could also provide an all-in-one package via >>> special modules. so users won't see any difference, if they prefer the >>> existing monolithic package.) >>> 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 Mark Struberg <[email protected]> >>>> >>>> Hmm difficult topic. >>>> >>>> Please allow me a few questions: >>>> >>>> a.) Trinidad components would still work with using either Orchestra >>>> conversations or CODI? >>>> b) You are not relying on other components or the users using your >>>> conversation >>>> stuff if they don't like? >>>> c) if the user doesn't make use of this feature, it will not pollute the >>>> viewRoot or cause heavy performance hits? >>>> >>>> If all this is ok, then there is imo no argument against adding it to >>>> Trinidad. >>>> This doesn't mean I like it either, but it doesn't hurt at least ;) >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> > >>>> >From: Gerhard Petracek <[email protected]> >>>> >To: MyFaces Development <[email protected]> >>>> >Sent: Wed, July 21, 2010 10:16:23 AM >>>> >Subject: Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with >>>> > each window >>>> > >>>> >or tab that the user is interacting with >>>> > >>>> >i agree with martin. >>>> > >>>> > >>>> >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 Martin Marinschek <[email protected]> >>>> > >>>> >Hi Matthias, >>>> >> >>>> >> >>>> >>> Not everybody is using CDI and/or Spring. >>>> >> >>>> >>well, in the real world and a little while in the future, there is not >>>> >>many people who will not have one of these frameworks in their >>>> >>applications. >>>> >> >>>> >> >>>> >>> 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? >>>> >> >>>> >>yes, this is what we could and what we should. Why not take this >>>> >>addition as a reason to do this right now? If we don´t take such >>>> >>additions as a reason to do this, what else will be our reason? >>>> >> >>>> >>best regards, >>>> >> >>>> >>Martin >>>> >> >>>> >>-- >>>> >> >>>> >> >>>> >>http://www.irian.at >>>> >> >>>> >>Your JSF powerhouse - >>>> >>JSF Consulting, Development and >>>> >>Courses in English and German >>>> >> >>>> >>Professional Support for Apache MyFaces >>>> >> >>>> > >>>> >>>> >>>> >>> >>> >> >> > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
