On Wed, Jul 21, 2010 at 3:32 PM, Gerhard Petracek <[email protected]> wrote: > imo we should analyze which modules would make sense as stand-alone modules. > if there are 2+ of them, we should really think about such a modularization. > we might get new users who just use some of the stand-alone modules instead > of using something completely different (e.g. because they don't like to use > trinidad as a whole). > i'm fine with starting a new thread.
cool > 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 Matthias Wessendorf <[email protected]> >> >> On Wed, Jul 21, 2010 at 2:51 PM, Gerhard Petracek >> <[email protected]> wrote: >> > hi, >> > an optional trinidad-support module for codi, orchestra,... could use >> > the >> > special events of trinidad. -> these trinidad-support modules would have >> > a >> > dependency to trinidad (and not the other way round). if users don't use >> > the >> > support module for trinidad, the std. behavior of these frameworks would >> > be >> > used as fallback. >> >> I am fine with that, in parallel. At least CODI sounds interesting (for >> me). >> >> > i'm not talking about one jar file. >> > internally we would have several modules (e.g. a stand-alone skinning >> > module). >> > -> we can release the fine grained modules as well as trinidad-api and >> > trinidad-impl. >> > (we would need special modules just for packaging trinidad-api and >> > trinidad-impl jar files via the shade plugin of maven.) >> > -> some users would use the fine grained modules and the rest continues >> > to >> > use trinidad-api and trinidad-impl (like today). >> >> hrm, is that really needed? >> Not sure that there is a lot of benefit from it, beside the extra work... >> On other subprojects, like CODI itself, it does make sense, since it >> is more modular. >> >> heck, this is a different topic, let's discuss that on a different >> (->new) thread :) >> >> -Matthias >> >> > 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 Matthias Wessendorf <[email protected]> >> >> >> >> On Wed, Jul 21, 2010 at 2:02 PM, Gerhard Petracek >> >> <[email protected]> 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. >> >> >> >> a lot != most :) >> >> >> >> > the questions are: >> >> > who would use this feature? >> >> > - new projects? i don't think so. >> >> >> >> possible.. >> >> >> >> > - existing projects? >> >> >> >> yes, why not? >> >> >> >> > would they upgrade to a new version of trinidad just for using this >> >> > feature? >> >> >> >> pretty soon, I hope end of July, there will be a new release >> >> (2.0.0-beta), >> >> since >> >> the JSF2 and also its (jsf2) ajax bridge is kinda stable, now >> >> >> >> > maybe it's the right time to discuss our plans for the future of >> >> > trinidad. >> >> >> >> I know that - at least my goal - is finishing on the JSF 2.0 uptake. >> >> not sure if I am too thrilled about forcing hard dependencies to >> >> CDI/Spring >> >> >> >> but I said before, that we could layout an *independent* API for >> >> something >> >> like window/event systems and let submodules implement with APIs they >> >> want, >> >> e.g. CDI or more heavy-weight: Spring >> >> >> >> > (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.) >> >> >> >> for runtime dependency its is trinidad-api and trinidad-impl; >> >> wanna pack that into one jar? >> >> >> >> > 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 >> > >> > >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
