incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Subject Re: [PORTAL] Changes and API review?
Date Sat, 16 Dec 2006 00:36:46 GMT
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 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

View raw message