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.
>

Reply via email to