Redesign JS FileActions API with reuse in mind

[PVince81]

Currently the FileActions API action handlers require the following information:

• $file: the file element in the file list
• fileList: file matching FileList instance
• fileName: name of the file
• dir: directory of the file

This creates tight coupling of file actions with a file list.
This means that it is not possible to trigger file actions with only a file path for example

Also many file actions are triggering visual stuff on the FileList remotely, or calling methods on the FileList.

Now if we want to have FileActions available in other apps like GalleryPlus, they cannot depend on the FileList class which doesn't exist there. If it does, it means the Gallery app must implement the thumbnail list using an interface similar to FileList.

Also FileActions may be rendered differently in other apps, including the way how file actions affect the UI (for example renaming triggers a rename box, which rendering would be dependent on how the file list looks like, which might be different in Gallery).

So in the end FileActions needs to be more abstract: it should be just a collection of actions with the matching action handlers.

I even wonder if the action handler functions should rather be registered from outside, and then FileActions would trigger an event. Then from outside the file list could just listen to an event FileActions.on('action-rename') and then do whatever it is supposed to do.

Third party apps must still be able to add their custom actions to files (for example an action "lock" to exlusively lock the file for the current user), which means some action handlers would still come from the outside, but the action itself might not be compatible with the currently rendered list if it contains any UI element that is different from the regular file list.

So I'm not sure yet how to handle this. Needs further thinking.

Now that we have the right sidebar in the files app, we want to be able to trigger file actions from there. Since file actions require a file list, it means the sidebar needs to receive the FileList object too. This is not acceptable if we want the sidebar to be reusable in other contexts where no FileList object is available, like the GalleryPlus app.

CC @oparoz for some input

[PVince81]

also note that some file actions might need to behave differently depending on which list they are invoked in. Basically each FileList has its own list of supported actions.
For example TrashbinFileList only supports "delete" and "restore".

Currently many third party apps register file actions on the global object OCA.Files.FileActions.register(), this will only affect the "All files" section.
But in the future we might want such "global" file actions to also affect other lists like the gallery.

[PVince81]

Closing in favor of Phoenix implementation: owncloud/web#149

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.