Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 198 invoked from network); 21 Jul 2010 13:34:30 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Jul 2010 13:34:30 -0000 Received: (qmail 78243 invoked by uid 500); 21 Jul 2010 13:34:30 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 78027 invoked by uid 500); 21 Jul 2010 13:34:27 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 78020 invoked by uid 99); 21 Jul 2010 13:34:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 13:34:27 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gerhard.petracek@gmail.com designates 209.85.213.53 as permitted sender) Received: from [209.85.213.53] (HELO mail-yw0-f53.google.com) (209.85.213.53) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 13:34:20 +0000 Received: by ywh2 with SMTP id 2so819479ywh.12 for ; Wed, 21 Jul 2010 06:33:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=RDAFn7pNHE8pHYYbrsnUeJeZS6MvCHcOaaV2YLXynHM=; b=afiTTea0iC6vSeJxyB4DqtvP/R6VjEeqIjMoP3wvvJbau0+gQD8WzEoeP6dO/kvzUy 6MLHYxwjUxvqnCMw1qOIEZ1WMDXDIQ9yeFUWb8zR6xuxmtsD2KxYjhdWD0MMxIQC4w4y w4+RJyOaj+apIRvW6/QiCKy01070BnLfNMBpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=B1OgiggpTow+nenZ3P3dEmVCnG6wSfyMP9QNp2xs7HwychkSVfr408FgylBUYcXq7G HZpLaVUgRnhk7m1JFaqgyUs6BNSszVX+S5ffP4/msouWSKPzVGIqo/mJlyEFGreCjyjL 3y9lgyeeEVVglrNJjmm1tqSDLLc2zXtozYFrU= Received: by 10.100.53.30 with SMTP id b30mr233481ana.43.1279719187701; Wed, 21 Jul 2010 06:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.152.194 with HTTP; Wed, 21 Jul 2010 06:32:47 -0700 (PDT) In-Reply-To: References: <8352AC40-86E4-4807-A619-A85DFFC181F1@oracle.com> <43559121-BB54-4061-95CE-113DA92D4FBB@oracle.com> <8EC46670-FA7A-464F-A67A-25A66565571E@oracle.com> <497254.90263.qm@web27801.mail.ukl.yahoo.com> From: Gerhard Petracek Date: Wed, 21 Jul 2010 15:32:47 +0200 Message-ID: Subject: Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with each window or tab that the user is interacting with To: MyFaces Development Content-Type: multipart/alternative; boundary=001485f770a29871a1048be5d7ec X-Virus-Checked: Checked by ClamAV on apache.org --001485f770a29871a1048be5d7ec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 us= e trinidad as a whole). i'm fine with starting a new thread. 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 > On Wed, Jul 21, 2010 at 2:51 PM, Gerhard Petracek > wrote: > > hi, > > an optional trinidad-support module for codi, orchestra,... could use t= he > > special events of trinidad. -> these trinidad-support modules would hav= e > a > > dependency to trinidad (and not the other way round). if users don't us= e > the > > support module for trinidad, the std. behavior of these frameworks woul= d > 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 > >> > >> On Wed, Jul 21, 2010 at 2:02 PM, 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. > >> > >> a lot !=3D 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 speci= al > >> > 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 > >> >> > >> >> Hmm difficult topic. > >> >> > >> >> Please allow me a few questions: > >> >> > >> >> a.) Trinidad components would still work with using either Orchestr= a > >> >> 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 pollut= e > >> >> 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 > >> >> >To: MyFaces Development > >> >> >Sent: Wed, July 21, 2010 10:16:23 AM > >> >> >Subject: Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated wit= h > >> >> > 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 > >> >> > > >> >> >Hi Matthias, > >> >> >> > >> >> >> > >> >> >>> Not everybody is using CDI and/or Spring. > >> >> >> > >> >> >>well, in the real world and a little while in the future, there i= s > >> >> >> 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 versio= n > 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=B4t take suc= h > >> >> >>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 > --001485f770a29871a1048be5d7ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
imo we should analyze which modules would make sense as stand-alo= ne 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.

=
regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF = Consulting, Development and
Courses in English and German

Professional Support for Apache MyFace= s



2010/7/21 Matthias Wessen= dorf <matzew@apac= he.org>
On Wed, Jul 21, 2010 at 2:51 PM, Gerhard Petracek
<gerhard= .petracek@gmail.com> 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 wou= ld be
> used as fallback.

I am fine with that, in parallel. At least CODI sounds interesting (f= or me).

> i'm not talking about one jar file.
> internally we would have several modules (e.g. a stand-alone skinning<= br> > 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 conti= nues 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<= /a>
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
> 2010/7/21 Matthias Wessendorf <matzew@apache.org>
>>
>> On Wed, Jul 21, 2010 at 2:02 PM, Gerhard Petracek
>> <gerhard.petracek= @gmail.com> 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 applic= ation/s.)
>> > furthermore, i agree with martin - most projects are using (o= r will use)
>> > one
>> > of the mentioned frameworks.
>>
>> a lot !=3D most :)
>>
>> > the questions are:
>> > who would use this feature?
>> > =A0- new projects? i don't think so.
>>
>> possible..
>>
>> > =A0- existing projects?
>>
>> yes, why not?
>>
>> > would they upgrade to a new version of trinidad just for usin= g 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 fu= ture of
>> > trinidad.
>>
>> I know that - at least my goal - is finishing on the JSF 2.0 uptak= e.
>> 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 s= omething
>> like window/event systems and let submodules implement with APIs t= hey
>> want,
>> e.g. CDI or more heavy-weight: Spring
>>
>> > (at least if we should use the maven shade plugin for modular= izing
>> > trinidad.
>> > in such a case we could also provide an all-in-one package vi= a special
>> > modules. so users won't see any difference, if they prefe= r 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 <struberg@yahoo.de>
>> >>
>> >> Hmm difficult topic.
>> >>
>> >> Please allow me a few questions:
>> >>
>> >> a.) Trinidad components would still work with using eithe= r Orchestra
>> >> conversations or CODI?
>> >> b) You are not relying on other components or the users u= sing your
>> >> conversation
>> >> stuff if they don't like?
>> >> c) if the user doesn't make use of this feature, it w= ill 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 <gerhard.petracek@gmail.com>
>> >> >To: MyFaces Development <dev@myfaces.apache.org>
>> >> >Sent: Wed, July 21, 2010 10:16:23 AM
>> >> >Subject: Re: [Trinidad][api]TRINIDAD-1857 Add a Map a= ssociated with
>> >> > each
>> >> > =A0window
>> >> >
>> >> >or tab that the user is interacting with
>> >> >
>> >> >i agree with martin.
>> >> >
>> >> >
>> >> >regards,
>> >> >gerhard
>> >> >
>> >> >htt= p://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 <mmarinschek@apache.org>
>> >> >
>> >> >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 framew= orks in their
>> >> >>applications.
>> >> >>
>> >> >>
>> >> >>> I think, on long term we may want one clean = and independent API,
>> >> >>> where
>> >> >>> all these projects offer an implementation f= or a window/event
>> >> >>> system:
>> >> >>> -CODI
>> >> >>> -Orchestra
>> >> >>> -Trinidad
>> >> >>> -etc
>> >> >>>
>> >> >>> However, right now, Trinidad has the base al= ready 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 b= etter future version of
>> >> >>> a
>> >> >>> more unified API, for this. Right?
>> >> >>
>> >> >>yes, this is what we could and what we should. Wh= y not take this
>> >> >>addition as a reason to do this right now? If we = don=B4t 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
>
>



--

--001485f770a29871a1048be5d7ec--