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
>
>
