[
https://issues.apache.org/jira/browse/SLING-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780121#comment-13780121
]
Francesco Mari commented on SLING-3133:
---------------------------------------
I could agree on a resourceType strategy to handle operations. With operations,
in this contentx, I mean arbitrary services (call them POST steps,
PostProcessors, etc.) which all contribute to a POST operation which is meant
to be executed by the POST servlet.
Nevertheless, I would better go with a filter triggered by a well defined
parameter, the alredy used :operation or another configurable parameter name.
This allows us to handle corner cases, e.g. when a POST request is handled by
the resource itself via its associated script. I would better let the POST
filter override the normal POST behaviour of resources, than the other way
around. I think this approach could make the POST logic more consistent, given
that the user explicitly triggered the correct functionality by using a
parameter in the request.
> [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
