Hi, On 21.07.2010 10:00, Bertrand Delacretaz wrote: > 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?
What's the use of a service here ? It just makes it more complicated requiring to add references etc. Or does the build have to know anything outside the data provided ? Regards Felix > > 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 >
