| View Providers |    | 
 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 | ||
 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.
 
 Register the provider with
 Register the provider with CDOViewProviderRegistry.
 A client's view provider implementation can be contributed programmatically to the CDOViewProviderRegistry,
 as the following example suggests:
 
 Get the target
 Get the target CDOViewProvider implementation.
 Add the provider instance to
 Add the provider instance to CDOViewProviderRegistry.
 A specific CDOViewProvider implementation can also be contributed using the
 org.eclipse.emf.cdo.viewProviders extension point. Clients specify:
 
class implementing the CDOViewProvider interface.
 URIs that should match with the contributed provider.
 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.