Hi,
On 20.07.2010 18:17, Carsten Ziegeler wrote:
> Am 20.07.10 15:20, schrieb Felix Meschberger:
>>
>> Maybe a request/response-builder is better:
>>
>> SlingHttpServletRequest = new SlingHttpServletRequestBuilder(
>> resolver)
>> .addAttribute(name,value)
>> .addParameter(name,value)
>> .setMethod(name)
>> .setPath(path)
>> .toSlingHttpServletRequest();
>>
>> Provided some useful defaults (like request method and path) and
>> constructor arguments (e.g. HttpServletRequest for the "default" use
>> case). This might be more flexible and easier to use.
>>
>> A corresponding SlingHttpServletResponseBuilder would do the same for
>> responses.
>>
> I think if we introduce some request processing interface on one way or
> the other, we don't need these factories. The interface should use plain
> http servlet request/response and not the Sling versions. And those
> objects can be created in any way.
>
Well, the simplest constructor, of course, will be :
SlingHttpServletRequest request =
new SlingHttpServletRequestBuilder(httpServletRequest)
.setResourceResolver(resolver)
.toSlingHttpServletRequest();
If you don't have a request object to base processing upon, you might
want to have more flexible setup of the request object.
> Using the servlet request / response interfaces makes integration this
> service easier as the calling client might already have such objects.
I think, the main call API should take SlingHttpServletRequest|Response
but might -- for ease of use -- provide API to take
HttpServletRequest|Response...
Regards
Felix
>
> Carsten
