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