# View Providers

Author: Victor Roldan Betancort

A `view provider` allows clients to inject custom logic into the `resource factory` mechansim, capable of handling the whole `session` and `view` instantiation process. This permits to obtain `resources` through the `resource set` API transparently, without any prior CDO client API code. The view provider automatically kicks in the middle of the `ResourceSet.getResource()` call, forgetting about the whole openning session / openning transaction process, which happens behind the scenes.

This is quite useful when integrating CDO with EMF-based frameworks and tools that are not prepared for a CDO scenario themselves.

Table of Contents

1 | Implementing a View Provider
2 | Contributing View Providers Programmatically
3 | Contributing View Providers Using Extension Points

## 1 Implementing a View Provider

Clients should implement the `CDOViewProvider` interface, or sub class the `AbstractCDOViewProvider` class, which provides common functionality.

The example below shows a simple implementation that opens a new `session` to a local server and a new `transaction` on that session.

| ExampleViewProvider.java |  |  |  |

`new AbstractCDOViewProvider("cdo\\.local:.*", 100)
{
private IManagedContainer container;
@Override
public CDOView getView(URI uri, ResourceSet resourceSet)
{
if (container == null)
{
container = new ManagedContainer();
Net4jUtil.prepareContainer(container);
TCPUtil.prepareContainer(container);
container.activate();
}
int startIndex = uri.toString().indexOf(':');
String repoName = uri.toString().substring(startIndex);
IConnector connector = (IConnector)container.getElement("org.eclipse.net4j.connectors", "tcp", "localhost");
CDONet4jSessionConfiguration config = CDONet4jUtil.createNet4jSessionConfiguration();
config.setConnector(connector);
config.setRepositoryName(repoName);
CDOSession session = config.openNet4jSession();
return session.openTransaction();
}
};`

The example provider catches all URIs with shape "cdo.local:<repoName>".
Register the provider with `CDOViewProviderRegistry`.

## 2 Contributing View Providers Programmatically

A client's view provider implementation can be contributed programmatically to the `CDOViewProviderRegistry`, as the following example suggests:

| ProviderContribution.java |  |  |  |
`// Instantiate your view provider CDOViewProvider viewProvider = org.eclipse.emf.internal.cdo.view.PluginContainerViewProvider.INSTANCE; // Add the instance to the registry CDOViewProviderRegistry.INSTANCE.addViewProvider(viewProvider);`

Get the target `CDOViewProvider` implementation.
Add the provider instance to `CDOViewProviderRegistry`.

## 3 Contributing View Providers Using Extension Points

A specific `CDOViewProvider` implementation can also be contributed using the `org.eclipse.emf.cdo.viewProviders` extension point. Clients specify:

- A mandatory `class` implementing the `CDOViewProvider` interface.
- A mandatory regular expression string indicating the shape of `URIs` that should match with the contributed provider.
- An optional `priority` integer value, to indicate preference over other implementations matching the same regular expression. A higher value indicates a higher priority, `Integer#MAX_VALUE` being the maximum priority value and `Integer#MIN_VALUE` the minimum.

Copyright (c) 2004-2023 Eike Stepper (Loehne, Germany) and others.
All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html