[
https://issues.apache.org/jira/browse/SLING-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780076#comment-13780076
]
Dominik Süß commented on SLING-3133:
------------------------------------
Great to see movement in this area so fast.
I'm currently not so sure how I feel about using a Sling Request Filter for
this scenario. In any case I would not recommend to detect :operation but go
for the resourceType instead to make sure not to hook in for other servlets
than the POST Servlet. An alternative option would be to implement this as
custom operation itself that could 'coordinate' the processing of the phases.
What I am currently missing is the hard contract by phase, so registering
various phases seems not sufficient - we probably need an interface where we
inject a specific behavior (e.g. read only, or no commit/save available)
probably through a specific ResourceProvides. Such a ResourceProvider should
also prevent something like adapting to Session or Node so in such a phase the
contract cannot be broken for the resourceResolver of the request (we cannot
circumvent this for Factorygenerated ResourceResolvers, but at least the
contract for the request is not broken).
(After the talk of Senol Tas about RESTFul transactions I also thought that we
might than use this to enable multi-step forms in a RESTful manner)
> [Proposal] Sling POST workflow
> ------------------------------
>
> Key: SLING-3133
> URL: https://issues.apache.org/jira/browse/SLING-3133
> Project: Sling
> Issue Type: Improvement
> Components: Servlets
> Reporter: Francesco Mari
> Priority: Minor
> Attachments: SLING-3133.patch
>
>
> I would like to propose a quick proof of concept about handling POST requests
> in Sling. This could be a replacement (or an enhancement) for the current
> implementation of the POST Servlet. The proposal is mainly inspired by the
> talk by Dominik Süß at adaptTo() 2013.
> I implemented a Filter which monitors incoming requests for an :operation
> parameter. If this parameter is present, the POST workflow is executed. I
> opted for a filter because I don't want the resource/script resolution logic
> to trigger, I want to completely override it if the :operation parameter is
> present in the request.
> The workflow is an aggregation of two different components:
> - POST phases: each phase has a name, which is a symbolic identifier used by
> POST steps to attach to it.
> - POST steps: a step is the unit of work of the component. It is associated
> to one or more POST phase by means of a multi-value service parameter
> targeting the symbolic name of one or more phase.
> Steps and phases can be registered dynamically as OSGi components.
> The execution of the workflow sort each phase by service ranking, and for
> each of them executes the steps associated to it. Steps are executed in
> service ranking order, too.
> Please keep in mind that the attached patch is just a quick sketch of my
> idea, is far from being complete. In particular, I'm still think about the
> following topics:
> - How to enable steps (e.g. validation steps) to abort the workflow for the
> current operation? What happens to the work executed by previous steps?
> - Should steps be able to pass information to one another? Is some kind of
> shared context needed to glue them together (without strictly coupling them)?
> - How to track changes made by steps? And how to communicate which changes
> have been made to the end user?
> I would like to know if this could be of any interested to the community, and
> of course it would be great to hear from you.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
