onmove - get file names by ids

[FalcoWolff]

In my project i use my own backend code to handle refresh/delete/move/rename... requests.
Every operation requires the full path of a file.
For example a delete action GET-Request would look like this https://......../fileHandlerInterface.php?fileName=/home/user1/test.txt&op=delete.
As a gui i used your code and it worked pretty well, until i started working with the move event.
It gives the user the srcpath, which is an array (not a folder object!).
And the moved files as an array of ids.
I tried everything to parse the ids into the correct format, but failed.
Can you help me?

my code:

onmove: function(moved, srcpath, srcids, destfolder) {
                    
	var sourcepath = "";

	srcpath.forEach(element => {
		sourcepath += element[1];
	});
                    
                    
	var destpath = dataContainer.buildAbsolutePath(destfolder);//own function creates absolute path from folder object

	console.log("onmove {sourcepath: " + sourcepath + " srcids: " + srcids + " destfolder: " + destpath + "}");

	moved("Server/Network error");

},

[cubiclesoft]

The reason an array is used is because Javascript objects can't be used on the clipboard or for drag-and-drop. A limitation imposed by the OS. Also, it is possible to copy and paste between compatible File Explorer instances in completely different tabs/windows and even different web browsers (e.g. Firefox -> Google Chrome). It's not possible for the widget to know where source paths/IDs came from except via the File Explorer "group" that is embedded in encoded JSON drop data but it does know the destination folder object and so it passes that.

Applications should ideally be using IDs (element 0). The IDs are whatever you specify to the widget. Could be filenames or database IDs as long as they are unique. But anyway, they are part of each folder and file object. The ID (element 0) maps to a display string (element 1), which is what is displayed to the user. The ID is considered to be internal to your application. They could be the same but they could also be vastly different.

If you want a string, make your IDs your path names and then do this and skip the first element of srcpath:

var basepath = '';
for (var x = 1; x < srcpath.length; x++)  basepath += '/' + srcpath[x][0];

Then for each move/copy/whatever request:

for (var x = 0; x < srcids.length; x++)
{
  var finalsrcpath = basepath '/' + srcids[x];

  // Do AJAX request here.  Although, you've got to be careful to use finalsrcpath before the next loop or otherwise goes out of scope.
}

Don't forget to sanitize the input path on the server. The point of the source path is so the server side can find the parent of each source item by tracing the path from root to the end and verify that the path is valid. Since there might be 1,000 IDs for some user, making 1,000 separate requests will be a bit tedious. You might consider modifying your server API to handle bulk requests.

I've updated the live demo to dump more information to the console log. That should make it easier to see the type of data that sent to each callback.

[FalcoWolff]

Thank you for your quick reply!

So one solution would be to use the filepath as id.
For example File {name:'test.txt', size: 4000, id: '/home/user1/test.txt', hash:'/home/user1/test.txt' }.
But then there are synchronize errors:
For example:
user1 deletes file /home/user1/huhu.txt
user1 create file /home/user1/huhu.txt with content 'hahahah you dont know about that hidden text'
user2 moves file /home/user1/huhu.txt to /home/user2/importantSystemFile.exe
Is there any clean way to solve that? Maybe notify changes with websocket connection?

I also have a suggestion:
A javascript object is not possible to use on the clipboard but instead of an object an array could be stored.
Or are there any hidden disadvantages?

My Backend verifies the path, but bulk requests are not implementated yet.

[cubiclesoft]

Even with two users on a real filesystem, the proposed scenario still plays out in the same sequence you presented (assuming permissions are set appropriately). I'm not seeing a problem here. If you are mirroring a real filesystem, you should be doing something approximately similar to the example PHP server-side helper class in your code. As for IDs, each ID is a path segment and then the path segments can be concatenated as I demonstrated earlier but IDs can be whatever you want them to be (they could even be JSON objects) but the longer they are, the more memory each object will consume.

When I said Javascript object, I meant the internal/native Javascript object for the source folder. Serialized content such as JSON is okay on the clipboard and is how the widget works - try pasting into a text editor - there should be a text/plain variant that you can look at of what is sitting your clipboard. There's no guarantee that the source folder is even loaded into RAM when a paste operation happens.