On Thu, Aug 26, 2010 at 16:52, Felix Meschberger <[email protected]> wrote: > On 26.08.2010 15:34, Alexander Klimetschek wrote: >> On Thu, Aug 26, 2010 at 14:47, Felix Meschberger <[email protected]> wrote: >> 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 ?
No. >> - what operations are allowed to run > > Why would you want to restrict ? I only want modify operations in my case, no moves, or deletes. > But then you could check the :operation property and act accordingly. I don't want to do that, just calling the SlingPostOperation would be IMO much more elegant than a forward with all its required request/response wrapping. >> 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. I am not replicating it, I want to integrate a certain part of it inside the logic of my 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. That's exactly what I want :-) Making them available as services is fine for me, as long as one can directly call the "modify" post operation service. > You might also want to consider providing a SlingPostProcessor. No, I want to use the ModifyOperation in my context, not the other way around. Apart from doing an internal forward (I find this awkward, also not sure if this properly works for new nodes/resources created in the request's session), there is no way to "call" this useful, existing logic. > 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. But the associations of operations to their names are "fixed", as they are exposed as HTTP API already. Also, the SlingPostOperation is a public interface already. > Exposing the existing SlingPostOperation implementations might be an > option, but I fear invitation to duplicate code ... Why? If they are not accessible, one is invited to re-implement the logic from the ModifyOperation themselves. That would be code duplication. Regards, Alex -- Alexander Klimetschek [email protected]
