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 >> >> >> > >> >> >> >> > >
