hi matthias, > We are just polishing an exiting feature.
i know - the question was: do we really need such "new features/apis"? imo it's time to move forward and use the right tools (again see [1]). using such a map for trinidad internals is ok. but it feels like a workaround if users start using it in an application. >Why not starting with the modules? i've created a jira component for the trinidad support module [2]. it isn't on the list for the first alpha. anyway, you are welcome to start in the meantime. regards, gerhard [1] http://www.mail-archive.com/[email protected]/msg47448.html [2] https://issues.apache.org/jira/browse/EXTCDI/component/12313641 http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/21 Matthias Wessendorf <[email protected]> > 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 >
