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
