Hi all,
I've been playing a bit with the Tiles Request API (awaiting github :))
and I'd like to share a couple of thoughts about it.
The ability to call any Renderer with any kind of Request is even better
than I thought. I've written several Renderers in no time, and I can now
assemble multiple versions of a single web site from half a dozen
languages. I've written a couple of Request implementations, too, both
to support the tiles Taglib in Velocity and Freemarker, and to support
calling Tiles "offline" from a batch. It works well, but it is a bit
stretchy at times.
IMHO the Request interface could be made easier to implement, and that
could perhaps favor its adoption by other projects. More to the point:
(+) The Request interface provides access to a number of things that are
absolutely needed: accessing attributes by scope, as well as headers and
params; indeed it improves on the HttpServletRequest interface in these
matters.
(-) Yet I believe it would benefit from a diet. Because more methods are
more work to do when implementing it, but also because:
* getApplicationContext is only used as way to access the Application
scope. I'm afraid there may be two solutions to a single purpose here. I
understand why Renderers need to know the ApplicationContext, but
perhaps it should be provided to them as separate object during
initialization, and the application scope should be accessible only
through the Request interface to avoid confusion.
* isResponseCommitted, dispatch and include: those are a pain to
implement. These concepts are unrelated to the request we are currently
processing: they belong to the ApplicationContext (like
getRequestDispatcher belongs to the ServletContext). Besides, I'm not
sure why we need "dispatch" and "isResponseCommitted" from a theoretical
point of view. Forwarding a request is a controller behaviour, not
something a renderer should attempt. It's only used by Tiles as an
optimization of "include" for the servlet environment, and optimizations
should not be exposed in the API imho.
* setContentType is a controller concept, a renderer should not attempt
to change the content type. Besides, Tiles is not using it.
* getOutputStream would be useful if we wanted to render binary data,
but none of our current technologies actually support it. Perhaps a
future addition?
* getRequestObjects seems only here for historical purpose; it is not used.
(+) It's good that the request body is not accessible. It should never
be used in rendering anyway. The response headers are missing, too
(except for ContentType), and that's a good thing, too. They're a
concern of the controller, not the renderer, and because they're not
there, the API helps to avoid mistakes.
Overall it's a good API and we can do much by extending Tiles 3 that we
could not do with Tiles 2. IMHO it still needs improvement, but perhaps
that can be postponed for a while.
It's just my opinion anyway, but I hope this can help in improving tiles
further.
Nick
