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