OCP namespaces for JS code

[PVince81]

So far the JS code doesn't have any difference between public and private namespace.

We should introduce a "OCP" namespace and rewire/wrap functions/classes to their corresponding private counterparts.

Please note that Javascript doesn't have the concept of interfaces.

In some cases it might be enough to just alias a class or object, for example:

    OCP.Myclass = OC.Myclass;

In more complex cases, a wrapper class can be used. Functions can be aliased one by one, or wrapped in other functions.

The first steps would be to identify what APIs are already used by apps, like the OC namespace.

• OCP for the main OC namespace
• OCP.Util for OC.Util
• OCP.Files for OC.Files (for Web UI uses Webdav instead of ajax/* calls #16902)
• OCP.Files.FileActions to register file actions: already used by viewer apps
• OCP.Files.FileList to be able to extend the file list class (ex: sharing overview, etc)
• OCP.EventSource

This will significantly increase the number of Javascript files, so we might want to solve the module loading / JS dependencies problem first: #17169

If we don't it means an app developer might have to add a lot of extra files with addScript in the correct order (private first, then public) to make sure the wrapping is done properly.

This ticket is to discuss and brainstom how to do this in the future.

@MorrisJobke @Raydiation @rullzer @oparoz @icewind1991 @schiesbn @karlitschek @DeepDiver1975

[PVince81]

Hmm, remember that we also have the "OCA" namespace for apps. So file list related stuff might need to stay in "OCA". We don't have public namespaces for OCA either on the PHP side.

[oparoz]

Hmm, remember that we also have the "OCA" namespace for apps

Indeed! Might be a good idea to try and sort that one out as well. oC can't tell devs to not have inter-app communication and then only offer some APIs via OCA.Files, even if I understand that Files is a special app. There is also the problem that different methods have to be called depending on whether the Files app is reached via a private or a public URL.

On the PHP side, we don't need to call any Files methods afaik, everything is available via the public framework or OCP.

[DeepDiver1975]

OCP namespace sounds reasonable for any logic/code which is provided by core (outside the scope of any app).

Big question to me: which functionality would this be?

Almost anything listed above is related to giving apps the possibility to be extended by other apps.
(e.g. hooking up file actions)

Based on the idea to have apps isolated and not depend on each other this is a rather tricky topic.

[PVince81]

We could have some kind of service provider in core and apps can register their service providers there. I believe we might have a similar discussion already for the PHP side.

As for FileActions alone, we could move this to core. I think any app might be interested to get access to file viewers (ex: opening an attachment from the mail app) without having to resort to the files app (which is a file list app). But this requires all file viewers to follow a specific API and not assume that there is a file list present and just embed themselves. See #13414

[karlitschek]

makes a lot of sense IMHO. Should help to avoid a lot of strange inter app dependency bugs.

[th3fallen]

like the idea but i agree #17169 should be resolved before hand. imho

[oparoz]

OCP.EventSource (JS) is missing for apps builders #12800
In Gallery, a different polyfill is being used, but other apps may want to use the one provided in core.

[PVince81]

@oparoz added