[ 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.