org.eclipse.gmf.runtime.common.core/src/org/eclipse/gmf/runtime/common/core/service/package.html - gmf-runtime/org.eclipse.gmf-runtime - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
 <html>
 <head>
 <!--

 /******************************************************************************
  * Copyright (c) 2004, 2005 IBM Corporation 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
  *
  * Contributors:
  *    IBM Corporation - initial API and implementation
  ****************************************************************************/

 -->
 </head>
 <body>

 Provides the base interfaces for all service providers. The following examples are some of the services in the modeling platform:
 <ul>
 <li>Layout Service
 <li>Property Service
 <li>Decorator Service
 </ul>
 <p>
 The modeling platform consists of a set of services whose requests are fulfilled by service providers that implement {@link org.eclipse.gmf.runtime.common.core.service.IProvider IProvider}.
 Each service exposes an extension-point that providers extend to be discovered and used. This package contains classes that define the abstract contract for service providers.</p>
 </p>

 <h2>Package Specification</h2>
 <p>
 When it receives a client request, a service typically embeds the request information in an {@link org.eclipse.gmf.runtime.common.core.service.IOperation IOperation} and then evaluates the
 extensions of its defined extension-point to find potential providers for the request. To determine to which providers to delegate a request,
 a service uses two sequential filters:
 <ol>
 <li>The service evaluates the information in each provider's extension descriptor. The service extension-point schema typically filters
 out most providers in this step and prevents the unnecessary loading of a provider.
 <li>The service requests information from each provider about whether it can support the request. The provider's
 {@link org.eclipse.gmf.runtime.common.core.service.IProvider#provides IProvider.provides} implementation performs this action.
 </ol>
 </p>
 <p>
 Typically, the service sorts the providers that passed the filters according to the priority that the service provider extension descriptor defines.
 Depending on the service and the request, the service might request one or more providers to perform the operation. After the required providers are defined, the service
 delegates the execution of the request for each provider to the operation's {@link org.eclipse.gmf.runtime.common.core.service.IOperation#execute IOperation.execute} implementation.
 Each service provides its own IOperation subclass that subsequently delegates to the provider.
 </p>
 <p>
 Most services expose an abstract class implementing IProvider that providers should subclass. The abstract class specifies the contract between the service and its providers since
 it specifies the API to perform requests. The abstract class usually extends
 {@link org.eclipse.gmf.runtime.common.core.service.AbstractProvider AbstractProvider} to leverage the notification support of this class.
 </p>
 <p>
  Some services require notification from a provider if the provider's state changes. This notification occurs through the
  {@link org.eclipse.gmf.runtime.common.core.service.IProviderChangeListener IProviderChangeListener} interface. These types of service connect to their provider using
  {@link org.eclipse.gmf.runtime.common.core.service.IProvider#addProviderChangeListener addProviderChangeListener} and disconnect using
  {@link org.eclipse.gmf.runtime.common.core.service.IProvider#removeProviderChangeListener removeProviderChangeListener}. Services often
  provide their own derived {@link org.eclipse.gmf.runtime.common.core.service.ProviderChangeEvent ProviderChangeEvent} classes to convey more
  service-specific information about the state change.
 </p>
 <p>
 Sometimes, it is impossible to provide enough information in a service provider extension descriptor to avoid
 the unnecessary loading of the provider plug-in. When the cost of loading a provider plug-in is high, it might be preferable to move
 the implementation of {@link org.eclipse.gmf.runtime.common.core.service.IProvider#provides IProvider.provides} to a lightweight plug-in.
 To do this, a service provider extension descriptor should include a "Policy" subelement with
 a class attribute that references a class that implements {@link org.eclipse.gmf.runtime.common.core.service.IProviderPolicy IProviderPolicy}. This
 interface is a subset of IProvider that only includes the
 {@link org.eclipse.gmf.runtime.common.core.service.IProviderPolicy#provides IProviderPolicy.provides} member.
 </p>
 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
	<html>
	<head>
	<!--

	/******************************************************************************
	* Copyright (c) 2004, 2005 IBM Corporation 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
	*
	* Contributors:
	* IBM Corporation - initial API and implementation
	****************************************************************************/

	-->
	</head>
	<body>

	Provides the base interfaces for all service providers. The following examples are some of the services in the modeling platform:
	<ul>
	<li>Layout Service
	<li>Property Service
	<li>Decorator Service
	</ul>
	<p>
	The modeling platform consists of a set of services whose requests are fulfilled by service providers that implement {@link org.eclipse.gmf.runtime.common.core.service.IProvider IProvider}.
	Each service exposes an extension-point that providers extend to be discovered and used. This package contains classes that define the abstract contract for service providers.</p>
	</p>

	<h2>Package Specification</h2>
	<p>
	When it receives a client request, a service typically embeds the request information in an {@link org.eclipse.gmf.runtime.common.core.service.IOperation IOperation} and then evaluates the
	extensions of its defined extension-point to find potential providers for the request. To determine to which providers to delegate a request,
	a service uses two sequential filters:
	<ol>
	<li>The service evaluates the information in each provider's extension descriptor. The service extension-point schema typically filters
	out most providers in this step and prevents the unnecessary loading of a provider.
	<li>The service requests information from each provider about whether it can support the request. The provider's
	{@link org.eclipse.gmf.runtime.common.core.service.IProvider#provides IProvider.provides} implementation performs this action.
	</ol>
	</p>
	<p>
	Typically, the service sorts the providers that passed the filters according to the priority that the service provider extension descriptor defines.
	Depending on the service and the request, the service might request one or more providers to perform the operation. After the required providers are defined, the service
	delegates the execution of the request for each provider to the operation's {@link org.eclipse.gmf.runtime.common.core.service.IOperation#execute IOperation.execute} implementation.
	Each service provides its own IOperation subclass that subsequently delegates to the provider.
	</p>
	<p>
	Most services expose an abstract class implementing IProvider that providers should subclass. The abstract class specifies the contract between the service and its providers since
	it specifies the API to perform requests. The abstract class usually extends
	{@link org.eclipse.gmf.runtime.common.core.service.AbstractProvider AbstractProvider} to leverage the notification support of this class.
	</p>
	<p>
	Some services require notification from a provider if the provider's state changes. This notification occurs through the
	{@link org.eclipse.gmf.runtime.common.core.service.IProviderChangeListener IProviderChangeListener} interface. These types of service connect to their provider using
	{@link org.eclipse.gmf.runtime.common.core.service.IProvider#addProviderChangeListener addProviderChangeListener} and disconnect using
	{@link org.eclipse.gmf.runtime.common.core.service.IProvider#removeProviderChangeListener removeProviderChangeListener}. Services often
	provide their own derived {@link org.eclipse.gmf.runtime.common.core.service.ProviderChangeEvent ProviderChangeEvent} classes to convey more
	service-specific information about the state change.
	</p>
	<p>
	Sometimes, it is impossible to provide enough information in a service provider extension descriptor to avoid
	the unnecessary loading of the provider plug-in. When the cost of loading a provider plug-in is high, it might be preferable to move
	the implementation of {@link org.eclipse.gmf.runtime.common.core.service.IProvider#provides IProvider.provides} to a lightweight plug-in.
	To do this, a service provider extension descriptor should include a "Policy" subelement with
	a class attribute that references a class that implements {@link org.eclipse.gmf.runtime.common.core.service.IProviderPolicy IProviderPolicy}. This
	interface is a subset of IProvider that only includes the
	{@link org.eclipse.gmf.runtime.common.core.service.IProviderPolicy#provides IProviderPolicy.provides} member.
	</p>
	</body>
	</html>