From adffaces-dev-return-1883-apmail-incubator-adffaces-dev-archive=incubator.apache.org@incubator.apache.org Tue Dec 19 16:45:18 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-dev-archive@locus.apache.org Received: (qmail 82424 invoked from network); 19 Dec 2006 16:45:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Dec 2006 16:45:18 -0000 Received: (qmail 84083 invoked by uid 500); 19 Dec 2006 16:45:25 -0000 Delivered-To: apmail-incubator-adffaces-dev-archive@incubator.apache.org Received: (qmail 83945 invoked by uid 500); 19 Dec 2006 16:45:24 -0000 Mailing-List: contact adffaces-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-dev@incubator.apache.org Delivered-To: mailing list adffaces-dev@incubator.apache.org Received: (qmail 83936 invoked by uid 99); 19 Dec 2006 16:45:24 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Dec 2006 08:45:24 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of awiner@gmail.com designates 66.249.92.175 as permitted sender) Received: from [66.249.92.175] (HELO ug-out-1314.google.com) (66.249.92.175) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Dec 2006 08:45:14 -0800 Received: by ug-out-1314.google.com with SMTP id y2so2357103uge for ; Tue, 19 Dec 2006 08:44:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=b/9IWoyoK5SH01mQ8MxIrK6pdYLSXmIn70iULPm5QWhAezl7glnfG7WNTQthIcDWx69BedrsefTQPE5+Cy1XEktMpepAcz9y4Oa1totE/QzmNLUkRvNAn8huz7AKilh8oNpUl6nI98Q3FU0dWsH6ogayPrkGefE2ePLTjXjo3Ng= Received: by 10.67.121.15 with SMTP id y15mr7572235ugm.1166546692468; Tue, 19 Dec 2006 08:44:52 -0800 (PST) Received: by 10.67.102.2 with HTTP; Tue, 19 Dec 2006 08:44:51 -0800 (PST) Message-ID: <6dac79b90612190844i623555e7taf9a5f715378c549@mail.gmail.com> Date: Tue, 19 Dec 2006 08:44:51 -0800 From: "Adam Winer" To: adffaces-dev@incubator.apache.org Subject: Re: [PORTAL] Changes and API review? In-Reply-To: <45833247.1010804@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4581B6EF.8000107@gmail.com> <6dac79b90612141423l6682ede9k4b82052ff1d58207@mail.gmail.com> <4582D69A.8070906@gmail.com> <6dac79b90612151107l71266d15q6514c033a0c41ead@mail.gmail.com> <45830FC1.3020700@gmail.com> <6dac79b90612151509s4ae908fatf549c4d1ac29019c@mail.gmail.com> <45833247.1010804@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Scott, Why wouldn't methods that hook the start and end of the physical request be generically useful? Note that in my scheme, these'd just be empty methods, not abstract methods (or interface methods) that every configurator has to implement. For that matter, wouldn't we want to make the configurator - right off the bat - *only* hook the physical request? What's the use case for ever wanting to hook the action and render phases independently (via this API, that is)? -- Adam On 12/15/06, Scott O'Bryan wrote: > Hey Adam, > > First off, thanks for responding. Your suggestions have been > invaluable. :) Now... > > Adam Winer wrote: > > > >> So I guess basically I'm making one last appeal on the > >> GlobalConfigurator thing. If you still want it removed I'll get rid of > >> it. But I honestly think we're backing ourselves into an unnecessary > >> corner. I'll give in on everything else and make a new patch for the > >> jwaldman portal branch. > > > > I just don't get how we're getting extra flexibility. Can you give > > me a hypothetical scenario where having a different "global" > > configurator class (rather than just an instance) proves a big > > win? I don't see it yet. As best as I can see, my proposal > > still allows full access to the global instance to external > > developers. It just doesn't require a bonus class to do that. > > I absolutely can but bear with be because, like many of the Portal > usecases, it's kinda convoluted.. One thing currently being discussed > in JSR-301 (just as an example) is the lifetime of a Request attribute. > Consider, if you will, the Servlet case. A request attribute has a > lifetime of the physical request. This is sufficient because the > application is assumed to be the only application in the browser. This > means that every "physical" request from the browser to the server > should process the actions on the JSF lifecycle and then execute the > Render. In a Portal, however, this case is different. Really, request > attributes that were added during the Lifecycle.execute phases are > assumed to be there during each call the the Lifecycle.render phases. > And because there is more then one portlet on the screen, an action from > another portlet may cause a "render" to happen on our JSF Application. > > Understanding that, the nature of the "two phase" request of the portal > is such that the JSR-301 bridge might (TBD) execute the beginRequest and > endRequest methods at the beginning and end of the action AND render > phases rather then at the beginning and end of the physical request. > I'm pushing for the latter, but there are people that know a lot more > about Portal's then I do who are arguing the previous point. > > So one of the things I put on the GlobalConfigurator initially (and I > might need to put it back after I'm able to test this with the Bridge > enhancements I need and Pluto), was a set of methods to store and clean > up these items on the physical request. There is no reason that the > baggage for this should have to be carried around by each Configurator. > And if we have a getGlobalConfigurator which simply returns a > Configurator object now, we're going to have problems in the future if > that changes. Plus, it's one class of extra bloat, there are no real > debatable API's on it that lock us into anything, and there is no impact > at runtime to support this this class. It does, however, provide us a > needed layer of abstraction in an area that's still somewhat high risk. > > Scott > >