Dynamic Vfs structure

[filkaris]

This PR enables each app in egroupware to use a custom VFS file structure to save files for each entry.

In JS: vfs path is no longer hardcoded, but instead a function of base app (getVfsPath).
In PHP: Hooks were added so each app can modify the way the structure is created, and the way it's parsed to find the correct id.

If there are no hooks, and the app class does not implement getVfsPath, then the default path is used.

In our case, we split directories by digit to avoid having to load thousands of folders when browsing the vfs tree. For example, /app/appname/123 became /app/appname/d1/d2/d3/id123
We thought this would be something useful for the project, since we're adding abstraction and not using a hardcoded path.

[filkaris]

@hnategh @asig2016

Have you seen this?

We made this in our system because we were not able to load 1000s of folders in the webdav directory. There was too much of a delay, and even timeouts.

We have applied this in some apps which have a lot of entries, and it was the only way to load the structure via vfs client. With the new structure you need to load max. 20 folders each time, instead of thousands. We added the hooks so we can have this functionality without adding code in the api. It would be very helpful for us if this was merged, and I belive such functionality makes the application more flexible.

[filkaris]

Unfortunately, the [app] object is not available each time we might need it, in order to calculate the vfs path.

Since each app's code is loaded once the app is loaded, we have no way to call methods from other apps' objects, and this creates a big issue.

Closing for now, since this won't work.

[filkaris]

We changed the way the vfs path is fetched, and we're not using inheritance anymore.

I believe this is a very useful addition to egroupware, since the VFS path will not be hardcoded in javascript files anymore.
Instead it will be fetched via ajax from Link::vfs_path, which is already implemented.
This works well with the PHP hooks added as well.

Please review this, this will just make egw more flexible without breaking anything.
I believe it's more of a good practice, but let me know if I'm wrong.

The only thing I wasn't sure about, is where to put the egw.getVfsPath function. For now, it's placed in jsapi/egw_links.js

[filkaris]

@hnategh do you need anything else with this PR?

[ralfbecker]

@filkaris I don't have specific questions at this point in time, I just have other stuff to look into, with higher priority :(