[jira] [Resolved] (SLING-3133) [Proposal] Sling POST workflow

["Carsten Ziegeler (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler resolved SLING-3133.
-------------------------------------
    Resolution: Won't Fix

> [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 was sent by Atlassian Jira
(v8.20.10#820010)