+1 On Wed, Jul 21, 2010 at 11:09 PM, Gerhard Petracek < [email protected]> wrote:
> 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/ >> > > -- 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/
