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:07:49 GMT
On 12/19/06, Scott O'Bryan <darkarena@gmail.com> wrote:
> The global configurator already treats the render and action request as
> a single entity.  The real question comes in about what happens during
> subsequent render requests.  Sometimes, like storing render attributes,
> you want the request attributes to hang around for an action request and
> each subsequent render.  Other times, you want it to only hang around
> for the physical request.  This is something that the Servlet container
> does not address.

I don't think you ever want request attributes to hang around for
subsequent renders.  Nor do I get why, if there were some
funky lifecycle issues to deal with here, why every configurator
wouldn't be forced to understand them and handle them.

-- Adam


> Now that being said, I didn't say the methods were not generally
> applicable.  They are.  But there is no reason, in my opinion to pad the
> API with these additional methods.  The global configurator (and only
> the global configurator) should be accessed directly.  It's
> beginRequest, and endRequest methods will be called whenever appropriate
> whereas the Configurators, by contract, should only be called once per
> physical request (the Global configurator handles state saving).  I had
> to add a new method to disable the GlobalConfigurator for one request
> (to handle the ResourceServlet case.  So putting all this stuff on the
> base configurator object is unclean in my opinion.  Especially
> considering that all configurators should have the same functionality
> for these methods so it would force us to finalize them in order to
> PREVENT people from overriding them in one Configurator and not in another.
>
> Scott
>
> Adam Winer wrote:
> > 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
>
>

Mime
View raw message