Well, in this specific instance, it therefore doesn't "bloat" every configurator, since it only appears in one location.
-- Adam On 12/19/06, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
I'm still wondering why we should bloat the API of every configurator. And not ALL of the methods I'm looking at adding here can be static. Scott Adam Winer wrote: > 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 >> > >> > >> >> >
