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 20:06:33 GMT
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 <darkarena@gmail.com> 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 <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