The basic functionality of an adapter is to enable the user to browse through the content of an external system in the Studio library. You have to implement the following interfaces:

<YOUR_ADAPTER_NAME>Settings

Settings interfaces are used to map adapter specific connection parameters (like a connection URL) to Java code. You only have to declare the Settings interface according to the data your adapter needs. Implementations are generated automatically, backed with the data of your configuration. The getter methods of these interfaces must match the corresponding fields of the settings struct as described in Section 9.27.2, “Adapter Configuration”. The name of the interface is arbitrary, the Settings suffix is just a convention.

com.coremedia.contenthub.api.ContentHubAdapterFactory

An implementation of ContentHubAdapterFactory declares the type (a ContentHubAdapterType) of an adapter. While a factory can create multiple adapter instances (for example multiple RSS connections), the type defines attributes that are common for all adapter instances of the factory. The factory implements the factory method createAdapter to create an adapter instance. createAdapter has one argument, the binding, which in particular provides a settings property of your Settings interface. The method getId identifies the factory and is used when an adapter configuration is read from the content.

com.coremedia.contenthub.api.ContentHubAdapter

A ContentHubAdapter implementation resolves the tree structure of entities of an external system. It returns Folder and Item instances. Concrete examples and more documentation about ContentHubAdapters can be found in the Blueprint and in the Javadoc of the interface com.coremedia.contenthub.api.ContentHubAdapter

com.coremedia.contenthub.api.Item

The Item interface extends the ContentHubObject interface which describes their common attributes such as the name and the ID of the entity. Items have a type described by an instance of com.coremedia.contenthub.api.ContentHubType. A com.coremedia.contenthub.api.ContentHubType consists of a name and a parent type. The type hierarchy determines the icons the items are shown with in Studio.

If the items in your external system have names like file names, with extensions suitable to determine a MIME type from (for instance myimage.jpg), you can start with the com.coremedia.contenthub.api.BaseFileSystemItem, which derives the ContentHubType from the MIME type. Otherwise, you must implement getContentHubType().

com.coremedia.contenthub.api.Folder

The Folder interface extends the ContentHubObject interface which describes their common attributes such as the name and the id of the entity. Folders have the default com.coremedia.contenthub.api.ContentHubType folder that may be overridden if you want to use more specific icons in Studio.

com.coremedia.contenthub.api.search.ContentHubSearchService

If your external system allows for searching, you can propagate this to your Content Hub adapter by implementing a ContentHubSearchService and returning it in your ContentHubAdapter#searchService() implementation. You must implement at least the actual search method. The search capabilities of particular external systems differ. Therefore, the ContentHubSearchService has some feature flags that you can activate if you can support them via the external system. For details see the Javadoc of ContentHubSearchService.

Note

Adapter implementations should be stateless objects to ensure that pressing the Reload Button in Studio will invalidate the backend data as well. For example the RSS adapter does not keep the root folder as an Object variable. The adapter recreates the root folder with its feed items when the node is re-requested / when the user presses the reload button.

Note

Each adapter decides if and how to paginate the request of children. The Content Hub always requests all children until the specified page. It might be necessary to cache each page to reduce requests. Be aware that ContentHubAdapter.invalidate() will be called when the author explicitly wants to refresh a folder. In this case the cached data has to be invalidated.

The pagination will be triggered by scrolling in the client. Should a user scroll to the last element of a folder (library tree, or library list view) that supports pagination, the next page will be requested automatically.