incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [PORTAL] Changes and API review?
Date Tue, 19 Dec 2006 16:46:31 GMT
That method could easily be a static method on Configurator
in my scheme.

-- Adam


On 12/15/06, Scott O'Bryan <darkarena@gmail.com> 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
> >
> >
>
>

Mime
View raw message