On Wed, Jul 21, 2010 at 9:44 AM, Felix Meschberger <[email protected]> wrote:
> ...So we have to have functionality to
> (a) create
> SlingHttpServletRequest/Response objects out of regular HTTP objects
> and
> (b) create SlingHttpSeervletRequest/Response objects "out of nothing".
>
> For (a) we can of course reuse the real HTTP request/response objects
> for (b) we can't...
Agreed, and those "synthetic" request/response objects also need to be
available to the client for wrapping.
For example, if you want to save the output of a background request,
including (some) HTTP headers, you'd need to wrap the synthetic
request in a custom wrapper to catch addHeader() calls.
So I agree that we need a "synthetic request factory" that's exposed,
that cannot just happen in the SlingServlet service.
>
> Thus by defining two simple builders to setup a
> SlingHttpServeltRequest/Response object which is at the heart of all
> Sling processing, we can handle both cases transparently without special
> casing again...
I like your suggested API for those builders, but can't they be
services instead of just public classes?
i.e. instead of
SlingHttpServletRequest = new SlingHttpServletRequestBuilder(
resolver)
.addAttribute(name,value)
...
use
@Reference
private SlingHttpServletRequestBuilder b;
...
SlingHttpServletRequest = b.createRequest(resolver)
.addAttribute(name,value)
...
>
> Please remember my other proposal: Separate SlingMainServlet
> functionality from the SlingServlet service implementation. The
> SlingServlet.process method will take SlingHttpServletRequest/Response
> objects, which can (but are not required to be) built with the builder
> helpers....
That's probably good but I see it as in implementation detail, it's
more important that we agree on the API.
-Bertrand
