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 Fri, 15 Dec 2006 23:39:51 GMT
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