Hazem, On Wed, Jul 21, 2010 at 9:57 PM, Hazem Saleh <[email protected]> wrote: > Blake, > > What is the complexity of moving this functionality to CODI as a Trinidad > extensions on the CODI land?
why do we have to introduce a new set of dependency, to just increase an existing feature? IMO it's kinda odd to be forced to pick up CDI instead of continuing our current as the "default". As said before, if there is need/demand of a module, based on Orchestra, CDI,... it is not impossibel So I think I don't see why it is that bad to continue with the default impl in Trinidad and having the option to replace it with a CoDi based module (or Orchestra, if you have to support Spring) -Matthias > > 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/ > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
