But still it is stupid to now stick in CDI and replace our pageFlowScope (exists since every) and overhaul our Window/Event system with it.
I said before that we can have modules for that: * CODI-Trinidad-PageFlow * CODI-Trinidad-WindowManager both could be sub-modules under an umbrella "trinidad module" (thanks to the shade plugin) I also agree that adding the Shade plugin to Trinidad makes sense, since the "CODI-Trinidad-PageFlow-Module" does not really need a dependency to the Trinidad Filter ;-) (before I get to Shade plugin, I'd like to have at least one or two beta release of the 2.0.0 stuff) So with these new codi-modules, users will have the freedom to go with Trinidad default (those that don't need CDI) or with the CDI-based option, for that that like the new lightweight JavaEE stuff. For Spring/Orchestra I don't feel to strong about it, but on the CDI side of things, I am offering help Greetings, Matthias On Wed, Jul 21, 2010 at 11:08 PM, Gerhard Petracek <[email protected]> wrote: > imo martin summarized the "objection" perfectly [1]. > regards, > gerhard > [1] http://www.mail-archive.com/[email protected]/msg47448.html > 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 1:00 PM, Gerhard Petracek wrote: >> >> hi blake, >> basically you can use an external map in cdi context implementations. >> however, with cdi you shouldn't do that. "everybody" could just change or >> clear it and you would bypass important mechanisms of cdi. >> >> That's assuming that the requirements for a scope provider didn't include >> notification when the contents changed. Since it would, that isn't a >> problem. >> >> i would vote -1 for such an approach. if you plan that trinidad hosts an >> own window scope (based on cdi), you have to re-implement parts which are >> available in portable cdi extensions like codi. >> >> That's also not what I said. I said that Trinidad users that want to have >> the abstraction of a per-window Map provided by Trinidad act as a full scope >> should be able to integrate this with CODI. And that such schemes should >> allow such a separation of responsibilities. >> >> or trinidad just provides some additional events which would allow a >> better compatibility (if there are issues). >> >> Which events? >> >> plain trinidad ... jsf + trinidad without any other lib (in this case: >> libs for additional scopes). >> >> I'm not sure what you mean here. I should be able to use Trinidad and >> JSF and have a per-window Map if I have a WindowManager installed with >> Trinidad. >> >> @trinidad scopes: >> that's my point - besides some other great frameworks, we now have a spec. >> for scopes which allows portable extensions. imo trinidad is just the wrong >> place for adding new scopes. >> >> We explicitly did not add a scope in that sense. We added a per-window >> Map. There is no out-of-box bean management. The system could be >> configured to map this to a real scope and that could be implemented as an >> out-of-the-box feature later, but that is also implementation. >> >> users can just use e.g. trinidad dialogs in combination with the access >> scope provided by libs like codi. >> and with trinidad support modules we could close potential gaps. >> >> Users can already do that if they want. It would be nice to have a >> CODI-Trinidad module, but that should not be required for customers who >> don't need CDI. >> I am still trying to get my head around is your specific complaint. >> Do you object to Trinidad making it easier for Trinidad customers to >> associate Objects with their windows? That is specifically what the api >> question is. As I have written a number of times, they can already wire >> this up by themselves today, so it seems cruel to prevent us from making it >> easy for them to do this correctly. If the complaint is that Trinidad has >> per-window Objects, the feature is already in there and make perfect sense >> for a UI framework. >> -- Blake Sullivan >> >> 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 10:05 AM, Gerhard Petracek 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. >>> >>> I'm not sure what you are asking here. There should be a small number of >>> requirements on the provider of a scope implementation. The CDI code should >>> be able to plug into any scope provider. I would assume that part of that >>> contract would be providing a Map as a storage abstraction and some kind of >>> lifecycle. If Trinidad users want to use CDI to inject beans into the >>> window scope, it would be nice for them to be able to configure Trinidad as >>> the implementor of the window scope. >>> >>> @stand-alone trinidad window map: >>> do you mean there are some internal project guidelines like: >>> the project has to use plain trinidad. >>> ? >>> >>> I'm not sure what you mean by "plain". The requirement is that the >>> Trinidad WindowManager needs to be running on the requests that want to use >>> the Trinidad apis to access the per-window map, since the window map is >>> retrieved from the current window. >>> >>> @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). >>> >>> That's right and the implementations of all of the scopes are pluggable >>> in Trinidad so that they can delegate to any installed implementation. >>> -- Blake Sullivan >>> >>> 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 >>>>> >> >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
