Plug-in pattern - Revision history

Thomas Linder Puls: spelling

2015-02-12T15:35:34Z

spelling

← Older revision		Revision as of 17:35, 12 February 2015
Line 8:		Line 8:
	:The ''host'' of the ''plug-in''.		:The ''host'' of the ''plug-in''.
	;Site		;Site
	:The ''plug-in'' ~~explose~~ data and functionality to the ''host'', but the ''plug-in'' may also need to draw upon data and services from the ''host''. The ''site'' represent the ''plug-in'''s ''host'' access.		:The ''plug-in'' expose data and functionality to the ''host'', but the ''plug-in'' may also need to draw upon data and services from the ''host''. The ''site'' represent the ''plug-in'''s ''host'' access.

	There are two contracts in the pattern:		There are two contracts in the pattern:

Thomas Linder Puls: link support pattern

2013-08-22T11:21:07Z

link support pattern

← Older revision		Revision as of 13:21, 22 August 2013
Line 14:		Line 14:
	*The plug-in interface, which defines the ''hosts'' view of the ''plug-in''		*The plug-in interface, which defines the ''hosts'' view of the ''plug-in''
	*The site interface, which defines the ''plug-in'''s view of the ''host''		*The site interface, which defines the ''plug-in'''s view of the ''host''

			[[PFC]] has many of uses the [[Support pattern]], which is a specialization of the plug-in pattern.

	;Example		;Example

Thomas Linder Puls: -

2013-08-22T10:57:52Z

← Older revision		Revision as of 12:57, 22 August 2013
Line 6:		Line 6:
	:The ''plug-in'' (sometimes called the client), which is plugged into the ''host''.		:The ''plug-in'' (sometimes called the client), which is plugged into the ''host''.
	;Host		;Host
	:The ''host'' of ~~the ''plug-in'', which hosts~~ the ''plug-in''.		:The ''host'' of the ''plug-in''.
	;Site		;Site
	:The ''plug-in'' explose data and functionality to the ''host'', but the ''plug-in'' may also need to draw upon data and services from the ''host''. The ''site'' represent the ''plug-in'''s ''host'' access.		:The ''plug-in'' explose data and functionality to the ''host'', but the ''plug-in'' may also need to draw upon data and services from the ''host''. The ''site'' represent the ''plug-in'''s ''host'' access.
Line 15:		Line 15:
	*The site interface, which defines the ''plug-in'''s view of the ''host''		*The site interface, which defines the ''plug-in'''s view of the ''host''

	Example:		;Example

	A SAPI (i.e. Speech API) speech recognizer engine is a plug-in hosted by the Windows SAPI system.		A SAPI (i.e. Speech API) speech recognizer engine is a plug-in hosted by the Windows SAPI system.

Thomas Linder Puls: initial

2013-08-22T10:54:25Z

initial

New page

The ''plug-in pattern'' is a [[:Category:Design Pattern|design pattern]]. I believe it is widely used, but I have not seen it described anywhere, and ''plug-in pattern'' is the name I have given it.

The pattern have three actors:

;Plug-in
:The ''plug-in'' (sometimes called the client), which is plugged into the ''host''.
;Host
:The ''host'' of the ''plug-in'', which hosts the ''plug-in''.
;Site
:The ''plug-in'' explose data and functionality to the ''host'', but the ''plug-in'' may also need to draw upon data and services from the ''host''. The ''site'' represent the ''plug-in'''s ''host'' access.

There are two contracts in the pattern:

*The plug-in interface, which defines the ''hosts'' view of the ''plug-in''
*The site interface, which defines the ''plug-in'''s view of the ''host''

Example:

A SAPI (i.e. Speech API) speech recognizer engine is a plug-in hosted by the Windows SAPI system.

The engine is the ''plug-in'' and Windows SAPI is the ''host''. The ''plug-in'' must implement the interface [http://msdn.microsoft.com/en-us/library/ee413355(v=vs.85).aspx ISpSREngine], which is the ''host'''s view of the engine.

The ''host'' will call the function [http://msdn.microsoft.com/en-us/library/ee413414(v=vs.85).aspx ISpSREngine::SetSite] with an object of type [http://msdn.microsoft.com/en-us/library/ee413368(v=vs.85).aspx ISpSREngineSite]. This object is the ''site'' object and gives the ''plug-in'' access to data and functionality in the ''host''.

In the recognition process the ''host'' will feed audio buffers; notify grammar loads and unloads; etc through the '''ISpSREngine''' interface. On the other hand, the ''plug-in'' will return recognition results; interrogate about grammar details; etc. through the site ('''ISpSREngineSite''') object.

[[Category:Design Pattern]]