Open aaronpk opened 6 years ago
This would set the order of the two channels given. All other channels would remain in the same order.
It is not clear to me what that means. does this put the second channel immediately after the first?
I agree with sknebel, I don’t quite understand the outcome of this. It seems like a useful approach especially in iOS where the UITableView delegate methods probably match right up with this. But I’m curious what the output array would be after this method
There must be a better way to describe this then. The idea is that only the orderings of the provided items would be affected by the operation. Some examples:
given: [a b c d e]
command: [c b]
("move c
up")
result: [a c b d e]
given: [a b c d e]
command: [d b]
("swap b
and d
")
result: [a d c b e]
This works equally well if you specify three items in the command, although I can't think of an interface where this would happen:
given: [a b c d e]
command: [e d b]
result: [a e c d b]
If you wanted to set the positions of every item, you can just provide the new order:
given: [a b c d e]
command: [b c a e d]
result: [b c a e d]
The way I would think about it is imagine every item in the list has a numeric position. You only affect the numeric positions of the items specified in the command.
So to clarify, if I had:
[a b c d e f g]
and using the UI I dragged f
up to between c
and d
, I would need to return an array of the entire list. Because if I were to try to send f
and c
or d
, it would want to swap them. Is that accurate?
That seems fine, but just wanted to verify I'm understanding it correctly. Essentially just using the two ids means swap these objects. If they are next to each other, then it essentially moves the one below above it. If they are further apart, it's more apparent that the swapping is occurring. If you need to move the ids in any way that is NOT a direct swap of their places, you return the entire array with new placements
You can always send the entire list, but there's another option in your example. Dragging f
to between c
and d
is actually only affecting the order of d e f
-> f d e
. What I'm not sure about is whether sending just those three would be easier than sending the whole list from the client's perspective. Thoughts?
I think at that point, sending the whole list is probably easier, since we are just talking about string ids. It would probably be more work to detect the subarray than return the new entire array.
Next question is what should the response be? Flickr's response is just blank.
The swapping seems kind of weird - is there a UI case where you'd want to do that for elements that are not next to each other?
The only benefit of this I see is that it doesn't have issues at the start/end of the list, other than that I'd think a command like "put $items immediately before/after $item, in that order" would be clearer and maybe matches drag-and-drop UI better?
EDIT: to solve the start/end, it could also be "replace $item with $list (containing item)", possibly with a default for when it is not in the list (e.g. then putting it at the end of $list), which is how I interpreted the current proposal first
The “put X before Y” is originally how I read the API description, rather than the swapping. So that does feel more intuitive to me personally, but I’m also okay just returning the full array for my purposes. As far as the return information, I would say blank with a success http response or an https error response with error body on failure. That way if something went wrong with the re-arranging, the client could either try again or pop up an error and revert the list back to the original placement.
(Originally published at: https://eddiehinkle.com/2018/02/11/6/reply/)
This has been implemented in Aperture and documented in the spec: https://indieweb.org/Microsub-spec#Set_Channel_Order
Looking at the spec documentation, does this mean only 2 out of the 4 example operations will be supported going forward?
[a b c d]
will change to [a d b c]
:
&channel[]=d
&channel[]=b
[a b c d]
will change to [b a c d]
:
&channel[]=b
&channel[]=a
&channel[]=c
&channel[]=d
That is: swapping will not be supported, neither will the “three items” case?
No, that's not what I meant.
Only the order of the channel IDs specified will be changed
In your example 1, c
has moved as well, even though only d
and b
were given.
To move a channel up or down...
This is equivalent to swapping two adjacent items.
I didn't give an example of setting the order of three items because I couldn't think of a UI where it would make sense, but it is still possible.
The nice thing about this approach is that the same update logic works for all the use cases, and doesn't matter how many items are in the list, and is atomic.
I just updated the text to hopefully be more explicit about this: https://indieweb.org/Microsub-spec#Set_Channel_Order
Just to document: Indigenous for Android allows setting the order, it sends all channels and their current/new order; The Drupal IndieWeb module accepts the request too to save the new order.
Having used Indigenous and Together for a little while, it's quickly become apparent that I want to be able to set an explicit order to the channels.
The Flickr API has a nice mechanism for ordering, which involves very little effort on the part of the client:
"Ordered, comma-delimited list of photo ids. Photos that are not in the list will keep their original order" https://www.flickr.com/services/api/flickr.photosets.reorderPhotos.html
In Microsub, this could be done in a similar way with a "channel" action:
This would set the order of the two channels given. All other channels would remain in the same order. This enables a simple drag and drop interface or a "move up/move down" button in clients, while also providing the ability for more complex interfaces that want to set the order of all channels in one command.