Hi Thanks Dominik for bringing this up. I really like the direction this discussion is taking.
We really learned a lot about the Sling POST Servlet since we first created it and it is probably time for a complete rearchitecture. > If we can also consider the post servlet as a pipeline of operations > (validate, pre-process, store etc.) we'd have a flexible mechanism > where you can avoid registering too many global things. A Pipeline sounds great. As for validation: This is something we are sourely lacking in Sling anyway. I think input validation is definitely something which should be part of the default Sling POST Servlet processing. But it should also be a feature, which is available independently for those cases, where the POST request is fully handled outside of the POST servlet. > I have long thought SlingPostOperations should be registered against the > resource type in the same way SlingServlets are registered against a > resource type. +1 I think all extension points for the POST servlet (as well as the future input validation framework) should be configurable with a resource type. > I also +1 the idea of having a pipeline with different stages of > processing where a dev can hook in based on some criteria (like > resourcetype, path, extension and so on) to be able to break down the > processing in the various aspects and therefore be able to implement > reusable parts. But I think neither the request selectors nor the request extension should be taken into account. The request URL should solely be addressing the resource and -- as a compromise to not being able to fully influence the Accept request header -- the resource representation. It should never contain request methods. Taking the resource path into consideration is interesting, though: For now we completely ignore the resource path in any resolution of scripts, filters and servlets. I fully agree, it may make sense for POST processing and for filters. But, would it maybe also make sense for general script and servlet resolution ? And if so, how ? (please spawn a new thread if you want to discuss this, thanks) Regards Felix Am 28.06.2013 um 11:15 schrieb Dominik Süß: > As far as I got it right most agree that it would be great to have an > optimized way to utilize the SlingPostServlet. > I also +1 the idea of having a pipeline with different stages of > processing where a dev can hook in based on some criteria (like > resourcetype, path, extension and so on) to be able to break down the > processing in the various aspects and therefore be able to implement > reusable parts. > > There also where some concerns about having this as the only way of > posting. And I also +1 that the support of custom Servlets should be > optimized anyway and not be dropped. If a developer decides to get rid of > this pipeline and taking care of all the aspects on his own he should be > free to do that. In this case he would (intentionally) lose all the > implicit logic provided by the SlingPostServlet and is completely on his > own just having the SlingHttpServletResquest & Response like for the GET > Servlets. > > I think the next step would be to define the pipeline, the serverside logic > that is applied on each step and the criteteria that shall be available to > register the extensions. An interesting aspect of that is transactional > behavior (like preventing session.save() up to a certain point in the > pipeline to have a contract how long the data in any case is just in a > transient state). > > Another idea that came into my mind on validation is the possiblity to have > the post params returned in an annotated response that allows the client to > resolve the problems and resubmit this (like Oak will be able to return > such Conflictannotations on Concurrent Changes on a node). And this could > also be used to implement multistepforms that need to be verified on the > intermediate steps without actually persisting something (creating a > restfull multistep form that way). > > WDYT? > Dominik > > > > > On Fri, Jun 28, 2013 at 8:51 AM, Daniel Platon <dpla...@gmail.com> wrote: > >> Hi everyone, >> >> I stand corrected, such a feature would not remove the SlingServlets >> entirely from the picture, since they are still needed for GET requests. >> >> +1 for the "pipeline of operations" concept. >> >> __ >> Dan >> >> >> >> >> -- >> View this message in context: >> http://apache-sling.73963.n3.nabble.com/Sling-Posthandling-thougts-about-the-current-behavior-tp4024713p4024751.html >> Sent from the Sling - Dev mailing list archive at Nabble.com. >>
