Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 71767 invoked from network); 21 Jul 2010 12:22:46 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Jul 2010 12:22:46 -0000 Received: (qmail 6132 invoked by uid 500); 21 Jul 2010 12:22:45 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 5619 invoked by uid 500); 21 Jul 2010 12:22:41 -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 5605 invoked by uid 99); 21 Jul 2010 12:22:40 -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 12:22:40 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mwessendorf@gmail.com designates 209.85.215.53 as permitted sender) Received: from [209.85.215.53] (HELO mail-ew0-f53.google.com) (209.85.215.53) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 12:22:34 +0000 Received: by ewy19 with SMTP id 19so2372711ewy.12 for ; Wed, 21 Jul 2010 05:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=A345BsPKQ/bx0KYfCt0edwhw1sEie/4GFArO1wGpfbU=; b=EhyQ7rnqJiYxMIOfFFq1o2OKpuJTnX/0FqbeSoyaFbjXV1g7MoWUVzfJk38FtPUbmW MRMuOx5j4aBt7QIbjNMvsDQn9pL6mmG6pKGfMKNw3ESygzi29rsYaajQReeeGz61YTPg VSLXDc/ma1Rp2Y0lUNAwiCaiziZZGfyVCTuZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=UzE2pv9jdDGoBiuAE/Qa18gjnJ1HsBGKYdHvaeG6CkJBxOdyqVfgP67CBWwwRPpfC1 BSL234cxTnc0e9RacmNcV/cU8DaekBi/yQ7J3h8wDFux1uqRVcgQsT/c9qQ9fJNpXJAY VTVgARjBMgv6C3G3aYHBIzIfVz+4peV1L0NCo= MIME-Version: 1.0 Received: by 10.216.231.97 with SMTP id k75mr110127weq.4.1279714885083; Wed, 21 Jul 2010 05:21:25 -0700 (PDT) Sender: mwessendorf@gmail.com Received: by 10.216.192.25 with HTTP; Wed, 21 Jul 2010 05:21:24 -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> Date: Wed, 21 Jul 2010 14:21:24 +0200 X-Google-Sender-Auth: p_UxLVucf5xaiS1YNO1fGI0fgDE Message-ID: Subject: Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with each window or tab that the user is interacting with From: Matthias Wessendorf To: MyFaces Development Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 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 issue= s). > (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? > =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 using this featu= re? 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 trinid= ad. > 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 >> >> 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 >> >To: MyFaces Development >> >Sent: Wed, July 21, 2010 10:16:23 AM >> >Subject: Re: [Trinidad][api]TRINIDAD-1857 Add a Map associated with eac= h >> > =A0window >> > >> >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 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, whe= re >> >>> 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=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 >> >> >> > >> >> >> > > --=20 Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf