incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <darkar...@gmail.com>
Subject Re: [PORTAL] Changes and API review?
Date Tue, 19 Dec 2006 17:53:18 GMT
I'm still wondering why we should bloat the API of every configurator.  
And not ALL of the methods I'm looking at adding here can be static.

Scott

Adam Winer wrote:
> That method could easily be a static method on Configurator
> in my scheme.
>
> -- Adam
>
>
> On 12/15/06, Scott O'Bryan <darkarena@gmail.com> wrote:
>> I just got one more example from your other input.
>>
>> I'm probably going to be adding a "disableConfiguratorForRequest" method
>> (or something similar) to the global configurator to support disabling
>> the configurator services from running.  It's cleaner then an attribute
>> me-thinks and will help if we run into scoping issues with the two part
>> portal request.
>>
>> See, I'm already going to need it.
>>
>> Scott
>>
>> 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
>> >
>> >
>>
>>
>


Mime
View raw message