Hazem, Where is the duplication of functionality? We are talking about an api. As for the implementation, we can make it pluggable, though in fact, it already is. If someone wants a WindowManager implementation that uses the Orchestra scheme for identifying windows, they can do so.
-- Blake Sullivan On Jul 21, 2010, at 12:16 PM, Hazem Saleh wrote: > -1 for having a duplicate functionality. > +1 for using CODI for the @WidnowScoped. > > On Wed, Jul 21, 2010 at 8:05 PM, Gerhard Petracek > <[email protected]> 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. > > @stand-alone trinidad window map: > do you mean there are some internal project guidelines like: > the project has to use plain trinidad. > ? > > @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). > > 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 >> >> >> > >> >> >> >> > > > > > > -- > Hazem Ahmed Saleh Ahmed > > Author of (The Definitive Guide to Apache MyFaces and Facelets): > http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 > http://www.amazon.com/-/e/B002M052KY > > Web blog: http://hazems.blogetery.com/ > > [Web 2.0] Mashups Integration with JSF: > http://code.google.com/p/mashups4jsf/
