Hi,

On 26.08.2010 15:34, Alexander Klimetschek wrote:
> On Thu, Aug 26, 2010 at 14:47, Felix Meschberger <[email protected]> wrote:
>> Hi,
>>
>> What is the exact use case ?
> 
> Have some servlet create something, but then use the standardized
> sling post request "syntax" to add additional unstructured data.
> 
>> Could it be solved by your servlet handling part of the post, and for
>> example create a request wrapper which exposes modified parameters. That
>> servlet could then forward to the default POST servlet for final processing.
> 
> Then the servlet looses a lot of control:
> - response handling

Would it be helpful to be able to "inject" another HtmlResponse class to
be used instead of the default ones ?

> - what operations are allowed to run

Why would you want to restrict ?

But then you could check the :operation property and act accordingly.

> 
> That could be handled, but only be complex logic where the servlet has
> to inspect the parameters, complex response wrappers, etc.
> 
> The nice thing is that the SlingPostOperation interface is there,
> ready to use... why not?

Because that interface is for use by operation providers consumed by the
Sling POST Servlet and you should not replicate the functionality of
Sling POST Servlet.

> 
>> As such I am currently opposed to exporting the internal operations.
> 
> Then making all of them services (2) is the way to go.
> 
> I probably could also have a SlingPostOperation myself, instead of the
> servlet, but that one couldn't make use of all the built-in logic of
> the existing operations.

What built-in logic ? Maybe we could expose some of this support logic.

You might also want to consider providing a SlingPostProcessor.

The problem around this is, that I do not see a clear and coherent
concept behind this "please expose the implementation" request.

I would like to keep as much of the functionality private to reserve the
freedom to change the implementation.

Exposing the existing SlingPostOperation implementations might be an
option, but I fear invitation to duplicate code ...

Regards
Felix

Reply via email to