Skip navigation links

Package com.liferay.document.library.repository.external

This package contains the interfaces exported by the document-library-repository-external framework to allow for third party implementation of external repositories for Liferay Portal.

See: Description

Package com.liferay.document.library.repository.external Description

This package contains the interfaces exported by the document-library-repository-external framework to allow for third party implementation of external repositories for Liferay Portal.

The best way to know how to use this framework is to look at an existing implementation (like Sharepoint or Google Drive external repositories), but the overall idea is explained below.

When implementing an external repository, implementations must be provided for four main interfaces: ExtRepository, ExtRepositoryFileEntry, ExtRepositoryFolder, and ExtRepositoryFileVersion. ExtRepository is in charge of the communication between Liferay Portal and the back-end repositories. The latter three interfaces describe the objects stored in the back-end repository: folders, files, and versions.

The classes implementing ExtRepositoryFileEntry, ExtRepositoryFolder, and ExtRepositoryFileVersion usually make a bridge between the methods of these interfaces and the methods in the back-end repository API. For instance, they may map Liferay's filename field to the back-end repository field holding the filename (example: field ows_BaseName in SharePoint).

ExtRepositoryFileEntry, ExtRepositoryFolder, and ExtRepositoryFileVersion are inside a hierarchy where two more interfaces exist: ExtRepositoryObject and ExtRepositoryModel. ExtRepositoryObject defines the properties which files and folders have in common, while ExtRepositoryModel has properties which are common to all three main types: files, folders, and versions. Implementors are free to define their own class hierarchy to implement these interfaces, but are advised to create one abstract class for ExtRepositoryObject and another one for ExtRepositoryModel so that they can be extended by the implementations of ExtRepositoryFileEntry, ExtRepositoryFolder, and ExtRepositoryFileVersion. It should be noted that the abstract implementation of ExtRepositoryObject should extend the abstract implementation of ExtRepositoryObject, to be coherent.

When implementing ExtRepository, all methods returning or receiving an ExtRepositoryFileEntry, ExtRepositoryFolder, and ExtRepositoryFileVersion must assume that even if the instances have the types of the interfaces, they, in reality, are implemented by the classes described in the previous paragraph. That is, if you are implementing a SharePoint external repository, you return SharepointFileEntry objects when called by Liferay, and Liferay will give you SharepointFileEntry instances as arguments to the methods.

To finish with, all data interchanged between Liferay and the implementations is in the back-end repository native format. These include object keys and user names. Liferay automatically converts these keys and user names to Liferay's IDs and user names, possibly with the help of some methods defined in ExtRepository (for instance: getLiferayUserName() must map back-end repository user names to Liferay user names).

Skip navigation links