That method could easily be a static method on Configurator in my scheme.
-- Adam On 12/15/06, Scott O'Bryan <[EMAIL PROTECTED]> 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 > >
