[
https://issues.apache.org/jira/browse/SLING-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated SLING-3133:
----------------------------------
Attachment: SLING-3133.patch
The previous patch contained some mistakes. Replaced the old patch with a new
one.
> [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
