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:44:51 GMT
Scott,

Why wouldn't methods that hook the start and end of
the physical request be generically useful?  Note that
in my scheme, these'd just be empty methods, not
abstract methods (or interface methods) that every
configurator has to implement.

For that matter, wouldn't we want to make the
configurator - right off the bat - *only* hook the
physical request?  What's the use case for ever
wanting to hook the action and render phases
independently (via this API, that is)?

-- Adam


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