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