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