New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement copy/paste or move. #180

Closed
tisto opened this Issue Jan 3, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@tisto
Copy link
Member

tisto commented Jan 3, 2017

We need to think about how we would want to implement copy/paste or moving items via rest api. One could argue that can already be handled by the frontend (GET => copy, POST => paste, DELETE => move). Though, especially for larger folder structures or larger files, we might want to think about keeping all this on the backend.

Opinions?

@tisto tisto self-assigned this Jan 3, 2017

@tisto tisto added this to the BeethovenSprint2017 Preparation milestone Feb 24, 2017

@tisto tisto referenced this issue Feb 27, 2017

Closed

Beethoven Sprint Planning #214

18 of 56 tasks complete
@buchi

This comment has been minimized.

Copy link
Member

buchi commented Mar 3, 2017

I propose two new POST endpoints @copy and @move. The URL path identifies the destination of the operation. The source can be specified in the JSON body of the request.

Examples for POST http://localhost/plone/@copy

{
  "source": "http://localhost/plone/front-page"
}

Copying multiple objects:

{
  "source": [
    "http://localhost/plone/front-page",
    "http://localhost/plone/document1"
  ]
}

Copying to a specific target id

{
  "source": "http://localhost/plone/front-page",
  "target_id": "copy-of-frontpage"
}

POST http://localhost/plone/@move would work the same way

@fulv

This comment has been minimized.

Copy link
Member

fulv commented Mar 3, 2017

This comment is my very first "contribution" to this project, so my apologies if I'm missing some of the underlying knowledge and assumptions. Here goes:

A simple rename (1:1) seems to me like it's simply a resource state change, so it could be handled by a PUT on the old object, with the new name part of the request entity-body.

For multiple objects, and for cut/copy/paste, perhaps there is a need for a "clipboard" resource, even though it's just a resource on the session and it's not persistent. Traditionally, in Plone the clipboard is just a session cookie (roughly speaking). Given a "clipboard" resource, it could then accept standard HTTP methods. Making a PUT or POST request to the clipboard resource would be the semantic equivalent of cutting or copying, with the list of items to be cut or copied in the entity-body as @buchi suggests. However, perhaps the option could be given to use UUIDS there, as well. Conversely, to paste to a new location, you would make a request to that resource with a PUT or PASTE, and the URL of the clipboard resource in the entity-body. The tricky part would be differentiating between cut and copy. That could be done by adding a flag for each item on the clipboard, or for the clipboard as a whole.

@buchi

This comment has been minimized.

Copy link
Member

buchi commented Mar 3, 2017

@fulv The clipboard is something that's only needed on the client/frontend side. In that context copy or cut would ideally do nothing on the server side. Only paste would actually copy or move an item. That's why I am suggesting endpoints for copy and move.

Beside of using URLs for the source, we should also support UUIDs and paths maybe.

@fulv

This comment has been minimized.

Copy link
Member

fulv commented Mar 3, 2017

@buchi Yes, the clipboard as a concept is relegated to the frontend. However, my suggestion is to translate this concept into a resource that can accept HTTP methods. My suggestion is really not that different from yours, except for the treatment of @clipboard as a resource, vs your endpoints @copy and @move as verbs. Also, it might be useful to have a clipboard to copy and cut items to when implementing a frontend, even though those actions don't do anything on the server (but they do something in the session).

@buchi

This comment has been minimized.

Copy link
Member

buchi commented Mar 3, 2017

@fulv If I understand you correctly you suggest POST /content/@clipoard for copy and PUT /content/@clipboard for move?

@fulv

This comment has been minimized.

Copy link
Member

fulv commented Mar 3, 2017

Differentiating copy and cut by PUT and POST is one possibility, though I'm not sure which I would choose for which.

Another possibility is to pick one, e.g. PUT, and then store a flag in the entity-body, e.g.:

{
    'cut':  true,  // defaults to false for copy
    'source': [
        'http://localhost/plone/front-page',
        'http://localhost/plone/document1'
    ]
}

You would send this entity-body to http://localhost/plone/@clipboard with a PUT.
The cut flag would allow the "paste" to delete the content in source. The "paste" operation would look like a PUT to http://localhost/plone/destination, with:

{
    'source': 'http://localhost/plone/@clipboard'
}

I have not yet looked at how you guys have implemented the creation of a new resource at /destination, so this might need to be adjusted.

buchi added a commit that referenced this issue Mar 4, 2017

buchi added a commit that referenced this issue Mar 4, 2017

buchi added a commit that referenced this issue Mar 4, 2017

@tisto tisto added the in progress label Mar 4, 2017

@davisagli

This comment has been minimized.

Copy link
Member

davisagli commented Mar 4, 2017

@buchi's proposal makes sense, and a clipboard resource feels like unnecessary server-side complexity to me. These days it probably makes more sense to keep clipboard items in the browser's localstorage rather than any approach which requires network communication.

@tisto tisto closed this in #233 Mar 7, 2017

@tisto tisto removed the in progress label Mar 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment