[
https://issues.apache.org/jira/browse/SLING-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved SLING-455.
-------------------------------------
Resolution: Fixed
Resolving this issue for now, not closing it though due to the open sub task
requesting documentation.
> Extend SlingPostServlet to support references to existing repository content
> ----------------------------------------------------------------------------
>
> Key: SLING-455
> URL: https://issues.apache.org/jira/browse/SLING-455
> Project: Sling
> Issue Type: New Feature
> Components: Servlets Post
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: 2.0.0
>
>
> After SLING-422 an interesting (for some applications important) side effect
> of the old SlingPostServlet has gone: With the old implementation it was
> possible to have files uploaded to the repository in one or more requests and
> and in a follow up request create another content and move the previously
> uploaded file to the newly created content.
> To better illustrate: Assume a CMS where you edit some kind of content. The
> content is composed of one or more images to be uploaded as image files and a
> title and a body text field. Now the CMS wants to present a user friendly
> interface and has implemented some cool file upload dialog, which shows
> upload progress.
> This feature is now used to pre-upload the image files to a temporary
> location. Upon sending the rest of the content - the title and body text -
> the image files should of course also be moved from the temporary location to
> the final destination in the same place as the title and body text.
> With the old SlingPostServlet, the image files could be moved by simply
> including :moveSrc/:moveDst parameter pairs for each image file. With the new
> SlingPostServlet this is not currently possible.
> To make such things possible again, the ModifyOperation of the
> SlingPostServlet is to be extend such as to recognize special parameters.
> Similar to the solution proposed in SLING-130 (@ValueFrom suffix to refer to
> values of another form field), I propose the following parameter name
> suffixes:
> @CopyFrom - Copies the items from the repository locations indicated by
> the parameter value
> @MoveFrom - Moves the items from the repository locations indicated by the
> parameter value
> Example use: To move an image file uploaded previously to "/tmp/image000.gif"
> to the "image" child node, the HTML form to submit the content (along with
> title and text fields) could be defined as:
> <form method="POST" action="/some/new/content">
> <input type="hidden" name="[EMAIL PROTECTED]"
> value="/tmp/image000.gif" />
> <input type="text" name="title" value="..." />
> <input type="text" name="text" value="..." />
> <submit />
> </form>
> If the item referred to in a @CopyFrom/@MoveFrom parameter is a node of type
> nt:file, treatment is special: If the natural type of the destination item is
> nt:file, the addressed node is simply copied or moved. Otherwise the the
> jcr:content child node is copied or moved. In case of a move the nt:file node
> is of course also removed.
> Example use (continued): After processing the request defined by the above
> form, the original item /tmp/image000.gif is gone and the contents is now
> located in /some/new/content/image.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
