JS API / container for apps to embed viewers/editors

[PVince81]

Currently every file viewer / file editor app is registering a FileAction and then doing whatever they want to try and embed themselves into the current view.
Also, back button support, URL and breadcrumb need to be managed by the app itself.

A new API / container need to be developed in the files app that allows apps to register viewer/editor handlers. The API will automatically support this:

1. getViewerContainer() will return the container that the viewer must use to embed itself
2. event APIs to communicate between the viewer and the files app (open event, close event, etc)
3. back button handling
4. URL handling:

• modify URL to point to the file upon file opening
• if the URL was opened directly in the browser, automatically open the matching editor
  5) this must also work in public preview mode (files_sharing public link)

@DeepDiver1975 @tomneedham @LukasReschke

[michaelstingl]

00002190

[SergioBertolinSG]

The problem with going back using the browser remains in 8.0.0.4, I think users will find it really annoying.
Entering a folder, previewing a pdf or a text file and going back distorts web UI.

[PVince81]

I can try and look into this for 8.1

[PVince81]

One important part is that the viewer implementations should not compute download URLs by themselves. They need to use the ones given by the API/container because the viewer cannot predict in which view it is. This would also make it possible to view files in the trashbin.

The container could also inject an instance of JS Files API (#13905) so the viewer/app can access any file operation if needed (including download/upload)

[tomneedham]

@PVince81 Yes. Hard part is handling the additional stuff that the text editor needs. If this will truly handle 'editors' there needs to be some consideration into the saving part.

[PVince81]

I thought about it. If I remember well the additional part is about checking if the file was changed on the server ? Basically some kind of conflict detection ?
This should be doable over WebDAV too, just like the sync client does.
If the viewer knows the etag of the file before saving, it could call api.saveFile(path, contents, {etag: oldEtag}); and the WebDAV call might fail with "409 conflict" if the file was changed.

[tomneedham]

Essentially yes. The only other bit is some fixes on the encoding, but this might be handled by core now, considering this was written for OC3: https://github.com/owncloud/files_texteditor/blob/master/ajax/savefile.php#L47

[PVince81]

I see. Either it could be done in pure JS (if that is even possible), or the text editor would still have to use its own endpoint, but that one needs to be made flexible to be able to load files from the trashbin as well.

[jancborchardt]

Would be good indeed. Then we can consistently place the viewers, fade the background, display file actions etc.

[PVince81]

Enhancement/refactor/API change, but we're past feature freeze -> 8.2

[oparoz]

Yes, please! :)

[PVince81]

• Idea: viewers or app could register JS URL routes to make it work with the history API (back/forward button) instead of the anchor hackery

[oparoz]

I guess this is now for 9.0 @PVince81 ?

[PVince81]

Yes, move to 9.0 or backlog

[DeepDiver1975]

Yes, move to 9.0 or backlog

@cmonteroluque

[PVince81]

@michaelstingl can you confirm that the blue ticket part is fixed ? Last time I checked the back button was properly closing the text editor, so it should work.

We should defer this ticket here to 9.0 or backlog and also remove the blue ticket tag as its part was fixed.

[ghost]

holding off for @michaelstingl's answer

[michaelstingl]

@PVince81 @cmonteroluque I can confirm: Closing text editor with browser back button keeps user in the current directory. This solves this problem described here: owncloud/files_texteditor#50 (comment) Thanks!

[PVince81]

Moving to backlog for now, no time for this

[PVince81]

By extension, also to provide a diff view, see #4056

[PVince81]

this will be reconsidered with Phoenix owncloud/web#215