imo we don't really need to move it. it would be enough to introduce events which get triggered by trinidad. in a trinidad support module we could process these special events and trigger the right parts of codi.
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 Hazem Saleh <[email protected]> > Blake, > > What is the complexity of moving this functionality to CODI as a Trinidad > extensions on the CODI land? > > > On Wed, Jul 21, 2010 at 10:37 PM, Blake Sullivan < > [email protected]> wrote: > >> Hazem, >> >> I'm still not sure what part you think Trinidad and CODI are duplicating? >> Trinidad defines a WindowManager and Window objects and contracts for their >> behavior. A WindowManager implementation may have interesting code for >> identifying windows and defining the lifecycle. CODI has simpler code for >> identifying windows. If that is the overlap you are talking about, then the >> explanation is that Trinidad WindowManagers are allowed to modify the page >> content in a much more intrusive manner than CODI. >> >> If the overlap is that Trinidad customers can have a scope that is >> associated with a Window without using CODI, then that's true, but that's >> been true for a long time. The only difference is that before our customers >> were doing this themselves using the functionality of the WindowManager. >> All this api does is makes everything dead simple. >> >> -- Blake Sullivan >> >> On Jul 21, 2010, at 12:27 PM, Hazem Saleh wrote: >> >> IMHO, Having a duplicate functionality implemented in both CODI and >> Trinidad is *not* a motivating thing for the users to upgrade the current >> working Trinidad version BUT it will be a painful thing to maintain on both >> projects. And for myself as an Apache MyFaces user, It is nice to see >> projects complementary to each others. >> >> On Wed, Jul 21, 2010 at 10:16 PM, Hazem Saleh <[email protected]> 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/ >>> >> >> >> >> -- >> 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/ >> >> >> > > > -- > 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/ >
