Repository clients communicate with the REST APIs of remote repositories such as APTrust, Fedora, etc. For safety, these clients should be limited to read operations, such as showing a list of ingested objects or a list of pending work items from a queue.
Repository clients should inherit from RepositoryBase. They must implement the following methods:
A constructor that takes a RemoteRepository object as its first parameter.
A provides method that takes no parameters and returns a list of object describing what methods this object provides. Each of the described methods should return a promise that ultimately returns HTML to be displayed in the DART dashboard. See the APTrustClient for an example.
A hasRequiredConnectionInfo method that takes no parameters and returns true or false to indicate whether the client's RemoteRepository object appears to have enough info to query the repository. If this returns false, the DART dashboard will skip its automatic attempt to connect to the repo.
Because repository clients return HTML, they may use templates to translate the repository's JSON responses to fomatted markup. These templates should be in a directory whose name matches the file name of repository client, minus the .js at the end. For example, the APTrustClient is in the file plugins/repository/aptrust.js. It's templates are in plugins/repository/aptrust/.
DART uses Handlebars templates. The APTrustClient includes templates to display ingested objects and work items, which are items queued for ingest or restoration.
Since the APTrust client is currently the only existing repository client plugin, its source code is probably the best reference for writing your own client. The APTrustClient tests show how the client is expected to behave.
You can see what the output of the APTrust client looks like in the dashboard documentation. If you're interested in seeing how the dashboard loads reports from repository clients, see the
show() method of the DashboardController.
The API for repository clients is subject to change. Most changes will likely be additions.