Проект "MonoDevelop Add-in для PascalABC.NET" - История изменений

AlexHit в 13:38, 8 декабря 2009

2009-12-08T13:38:19Z

← Предыдущая версия		Версия от 16:38, 8 декабря 2009
Строка 249:		Строка 249:
	- GUI add-in root содержит только GUI библиотеку.		- GUI add-in root содержит только GUI библиотеку.

	Есть 2 основные причины включать ~~сболрку~~ в add-in root:		Есть 2 основные причины включать сборку в add-in root:

	-Сборка определяет несколько классов или интерфейсов для применения add-ins.		-Сборка определяет несколько классов или интерфейсов для применения add-ins.
Строка 276:		Строка 276:

	'''Extensible libraries'''		'''Extensible libraries'''
			Когда add-in root помещается в библиотеку, в результате мы получаем библиотеку расширения. Правильно в этом случае правильно инкапсулировать подход точек расширенпия к библиотеке.

	~~When an add-in root is entirely composed by libraries~~, what we have in fact is an extensible library. It is important in this case to properly encapsulate the access to extension points in the library. In this way the library will look like any other regular library, ~~and any application will be able to use it like any other library~~.		Таким образом, библиотека будет выглядеть как любая другая библиотека,и любое приложение будет иметь возможность использовать ее как любую другую библиотеку.

	Mono.Addins ~~supports having several copies of the same~~ add-in root ~~in different locations~~. ~~When loading an~~ add-in root, the add-in engine ~~will take care of loading the add-ins that extend that specific add-in root version~~.		Mono.Addins поддерживает несколько одинковых копий add-in root в разных местах. Когда загружается add-in root, the add-in engine будет заботитья о загрузке надстройки для данной версии и включит ее в нее..

	~~For example~~, ~~let's say somebody implements a generic library for parsing source code files called~~ NParser. NParser ~~would provide~~:		Например, допустим, кто-то реализующей общую библиотеку для разбора файлы с исходным кодом называется NParser. NParser обеспечит:

	* A common API ~~for parsing files~~.		- Общий API для разбора файлов.
	* An extension point to be used by add-~~ins to add support for new languages~~.		- Точка расширения для использования надстроек для добавления поддержки новых языков.

	Any application might be able to use NParser by just linking to it and distributing it as a private assembly, or using it from the GAC. In this case, add-ins for the library would be loaded from the global registry, unless the application specified a different add-in registry.		Any application might be able to use NParser by just linking to it and distributing it as a private assembly, or using it from the GAC. In this case, add-ins for the library would be loaded from the global registry, unless the application specified a different add-in registry.

AlexHit в 22:00, 7 декабря 2009

2009-12-07T22:00:59Z

← Предыдущая версия		Версия от 01:00, 8 декабря 2009
Строка 268:		Строка 268:
	'''Add-ins'''		'''Add-ins'''

	Add-ins ~~have many similarities to~~ add-in roots, ~~because~~ add-~~ins can also behave as~~ add-in hosts ~~for other~~ add-ins. So, add-ins ~~can be composed by several assemblies and other files~~, ~~and they can be described using a standalone manifest~~, ~~and embedded manifest or by applying the~~ [assembly:Addin] ~~attribute to an assembly~~.		Add-ins во многом схожи с add-in roots, потому что add-in могут так же себя вести как add-in hosts для разных add-ins. Таким образом, add-ins могут содержать несколько сборок и других файлов,и они могут определить использование отдельных манифестов, и встроенных манифестов или применить атрибуты [assembly:Addin] для данных сборок.

	~~The following diagram shows an~~ add-in ~~composed by two assemblies, and extended by another~~ add-in:		Данная диагрмма отображает add-in сборки и определенный другими add-in:

	Add-in roots ~~and~~ add-ins ~~are described using the same~~ Add-in ~~Description Model~~, ~~but they are handled differently by the add-in engine~~. Add-in root assemblies ~~are loaded by~~ applications hosts ~~like regular assemblies~~, ~~while~~ add-ins are ~~dynamically discovered and loaded by the~~ add-in ~~engine~~.		Add-in roots и add-ins описывают использование разных Add-in моделей описания, но они обходятся разными инструментами.
	Extensible libraries		Add-in root assemblies загружают applications hosts использу "регулярные" сборки, пока add-ins are динамично обнаруженные и загруженные add-in инструментом.

			'''Extensible libraries'''

	When an add-in root is entirely composed by libraries, what we have in fact is an extensible library. It is important in this case to properly encapsulate the access to extension points in the library. In this way the library will look like any other regular library, and any application will be able to use it like any other library.		When an add-in root is entirely composed by libraries, what we have in fact is an extensible library. It is important in this case to properly encapsulate the access to extension points in the library. In this way the library will look like any other regular library, and any application will be able to use it like any other library.

AlexHit в 21:24, 7 декабря 2009

2009-12-07T21:24:07Z

← Предыдущая версия		Версия от 00:24, 8 декабря 2009
Строка 264:		Строка 264:

	Add-in roots обычно имеют главный файл. Когда используется одиночный манифест, главным файлом является манифест. Когда же используется манифест включенный в сборку, или использует атрибут [AddinRoot], главный файл сборки. Только главный файл может включать другие файлы в add-in root.		Add-in roots обычно имеют главный файл. Когда используется одиночный манифест, главным файлом является манифест. Когда же используется манифест включенный в сборку, или использует атрибут [AddinRoot], главный файл сборки. Только главный файл может включать другие файлы в add-in root.


			'''Add-ins'''

			Add-ins have many similarities to add-in roots, because add-ins can also behave as add-in hosts for other add-ins. So, add-ins can be composed by several assemblies and other files, and they can be described using a standalone manifest, and embedded manifest or by applying the [assembly:Addin] attribute to an assembly.

			The following diagram shows an add-in composed by two assemblies, and extended by another add-in:

			Add-in roots and add-ins are described using the same Add-in Description Model, but they are handled differently by the add-in engine. Add-in root assemblies are loaded by applications hosts like regular assemblies, while add-ins are dynamically discovered and loaded by the add-in engine.
			Extensible libraries

			When an add-in root is entirely composed by libraries, what we have in fact is an extensible library. It is important in this case to properly encapsulate the access to extension points in the library. In this way the library will look like any other regular library, and any application will be able to use it like any other library.

			Mono.Addins supports having several copies of the same add-in root in different locations. When loading an add-in root, the add-in engine will take care of loading the add-ins that extend that specific add-in root version.

			For example, let's say somebody implements a generic library for parsing source code files called NParser. NParser would provide:

			* A common API for parsing files.
			* An extension point to be used by add-ins to add support for new languages.

			Any application might be able to use NParser by just linking to it and distributing it as a private assembly, or using it from the GAC. In this case, add-ins for the library would be loaded from the global registry, unless the application specified a different add-in registry.


			Description of Add-ins and Add-in Roots

			Every add-in and add-in root has to provide a description of the extensibility elements it provides. There are two ways of doing this:

			* Using custom attributes: Mono.Addins provides several attributes which can be used to mark classes as extensions or extension points. Attributes can also be used to declare add-in information and dependencies.
			* Using an add-in manifest: a manifest is an XML description of an add-in. Attributes are very easy to use, but not all extensibility features that Mono.Addins provides can be expressed using attributes. Any declaration that can be done using custom attributes can also be done in a manifest, but not everything that can be declared in a manifest can also be expressed using custom attributes. Manifests can be deployed as standalone files, or they can be embedded as a resource in assemblies. Manifest files are identified by their extension, which must be ".addin" or ".addin.xml".

			It is allowed to use a mix of both approaches to describe an add-in. That is, an add-in could declare simple extensions using attributes, and more complex extensions in a manifest embedded as a resource.

			As you can see from the previous examples, the description of an add-in root looks similar to the description of an add-in. In fact, from the point of view of the add-in engine, add-ins and add-in roots are almost the same, so they use the same description model.

			The following sections describe in detail all information that can be included in an add-in or add-in root description. The term add-in is used generically in this chapter to refer to add-ins and add-in roots, unless specifically differenced.

AlexHit в 21:16, 7 декабря 2009

2009-12-07T21:16:49Z

← Предыдущая версия		Версия от 00:16, 8 декабря 2009
Строка 260:		Строка 260:
	-Использование [assembly:AddinRoot] атрибутов для сборок.		-Использование [assembly:AddinRoot] атрибутов для сборок.

	~~In the first and second case~~, a Runtime ~~section in the~~ manifest ~~can be used to reference other assemblies to be included in the~~ add-in root. ~~In the second and third case~~, ~~other assemblies can be referenced using the attribute~~ [assembly:AddinAssemblyInclude].		В первом и во втором случае, секция Runtime в manifest может использовать ссылку на сборки, включенных в add-in root.
			Во втором и третьем случае, различные сборки могут ссылаться на используемые атрибуты [assembly:AddinAssemblyInclude].

	Add-in roots ~~always have a main file~~. ~~When using an standalone manifest~~, ~~the main file is the manifest file~~. ~~When using a manifest embedded in an assembly~~, ~~or when using the~~ [AddinRoot] ~~attribute~~, ~~the main file is the assembly~~. ~~Only the main file can include other files in the~~ add-in root.		Add-in roots обычно имеют главный файл. Когда используется одиночный манифест, главным файлом является манифест. Когда же используется манифест включенный в сборку, или использует атрибут [AddinRoot], главный файл сборки. Только главный файл может включать другие файлы в add-in root.

AlexHit в 20:59, 7 декабря 2009

2009-12-07T20:59:21Z

← Предыдущая версия		Версия от 23:59, 7 декабря 2009
Строка 256:		Строка 256:
	Mono.Addins обеспечивает несколько путей декларирования add-in roots и сборок, связывающих их. Это объясняет деталь описания Add-ins и Add-in Hosts секцию, но в кратце, существуют 3 способа:		Mono.Addins обеспечивает несколько путей декларирования add-in roots и сборок, связывающих их. Это объясняет деталь описания Add-ins и Add-in Hosts секцию, но в кратце, существуют 3 способа:

	-		- Создание файла add-in manifest (XML файл с расширением .addin).
	* By creating an add-in manifest ~~file~~ (an XML ~~file with a~~ .addin ~~extension~~).		- Создание файла add-in manifest и вставка сборок в ресурс.
	* By creating an add-in manifest ~~file and embedding it in an assembly as a resource~~.		-Использование [assembly:AddinRoot] атрибутов для сборок.
	* By applying the [assembly:AddinRoot] ~~attribute to an assembly~~.

	In the first and second case, a Runtime section in the manifest can be used to reference other assemblies to be included in the add-in root. In the second and third case, other assemblies can be referenced using the attribute [assembly:AddinAssemblyInclude].		In the first and second case, a Runtime section in the manifest can be used to reference other assemblies to be included in the add-in root. In the second and third case, other assemblies can be referenced using the attribute [assembly:AddinAssemblyInclude].

	Add-in roots always have a main file. When using an standalone manifest, the main file is the manifest file. When using a manifest embedded in an assembly, or when using the [AddinRoot] attribute, the main file is the assembly. Only the main file can include other files in the add-in root.		Add-in roots always have a main file. When using an standalone manifest, the main file is the manifest file. When using a manifest embedded in an assembly, or when using the [AddinRoot] attribute, the main file is the assembly. Only the main file can include other files in the add-in root.

AlexHit: -

2009-12-07T20:52:56Z

← Предыдущая версия		Версия от 23:52, 7 декабря 2009
Строка 246:		Строка 246:
	В данном примере приложение состоит из 2-х файлов: консольного и графического приложения.Приложение определяет 2 add-in roots:		В данном примере приложение состоит из 2-х файлов: консольного и графического приложения.Приложение определяет 2 add-in roots:

			-Логический корень add-in содержит 2 сборки:Logic.dll and LogicHelper.dll.
			- GUI add-in root содержит только GUI библиотеку.

	* The Logic add-in root ~~is composed by two assemblies~~: ~~Logic.dll and LogicHelper.dll. Since both assemblies are libraries, they can be reused from the console and the gui exes.~~		Есть 2 основные причины включать сболрку в add-in root:
	* The GUI add-in root is composed only by the GUI library.

	~~There are basically two reasons for including an assembly in an~~ add-in root:		-Сборка определяет несколько классов или интерфейсов для применения add-ins.
			-Сборке необходимо загрузить остальные сборки add-in root.

	* The assembly defines some classes or interfaces to be implemented by add-ins.		Mono.Addins обеспечивает несколько путей декларирования add-in roots и сборок, связывающих их. Это объясняет деталь описания Add-ins и Add-in Hosts секцию, но в кратце, существуют 3 способа:
	* The assembly is required to load other add-in root assemblies.

	Mono.Addins ~~provides several ways of declaring~~ add-in roots ~~and the assemblies they are bound to~~. ~~This is explained in detail in the Description of~~ Add-ins ~~and~~ Add-in Hosts ~~section~~, ~~but summarizing~~, ~~there are three ways~~:

			-
	* By creating an add-in manifest file (an XML file with a .addin extension).		* By creating an add-in manifest file (an XML file with a .addin extension).
	* By creating an add-in manifest file and embedding it in an assembly as a resource.		* By creating an add-in manifest file and embedding it in an assembly as a resource.

AlexHit в 20:35, 7 декабря 2009

2009-12-07T20:35:39Z

← Предыдущая версия		Версия от 23:35, 7 декабря 2009
Строка 242:		Строка 242:
	Add-in roots могут связывать одну или несколько сборок, которые могут быть выполняемыми или библиотеками. Сложные приложения состоят обычно из нескольких сборок,поэтому важно тщательно определять, что является add-in root, а что нет.		Add-in roots могут связывать одну или несколько сборок, которые могут быть выполняемыми или библиотеками. Сложные приложения состоят обычно из нескольких сборок,поэтому важно тщательно определять, что является add-in root, а что нет.

			[картика]

			В данном примере приложение состоит из 2-х файлов: консольного и графического приложения.Приложение определяет 2 add-in roots:

	In this example, an application is composed by two executables: a console app and a graphical app. Both executables share the same logic libraries, and the GUI app has a GUI library and a components library. The application defines two add-in roots:

	* The Logic add-in root is composed by two assemblies: Logic.dll and LogicHelper.dll. Since both assemblies are libraries, they can be reused from the console and the gui exes.		* The Logic add-in root is composed by two assemblies: Logic.dll and LogicHelper.dll. Since both assemblies are libraries, they can be reused from the console and the gui exes.

AlexHit в 20:18, 7 декабря 2009

2009-12-07T20:18:48Z

← Предыдущая версия		Версия от 23:18, 7 декабря 2009
Строка 240:		Строка 240:
	В порядке разрешения этих типов архитектуры, add-in roots должен иметь уникальный идентификатор.Add-ins должен ссылаться на этот ID(идентификатор add-in root).Add-in roots так же имеет номер версии, который используется для поддержания логичности между точками расширения, им используемыми, и расширения представляемых add-ins.		В порядке разрешения этих типов архитектуры, add-in roots должен иметь уникальный идентификатор.Add-ins должен ссылаться на этот ID(идентификатор add-in root).Add-in roots так же имеет номер версии, который используется для поддержания логичности между точками расширения, им используемыми, и расширения представляемых add-ins.

			Add-in roots могут связывать одну или несколько сборок, которые могут быть выполняемыми или библиотеками. Сложные приложения состоят обычно из нескольких сборок,поэтому важно тщательно определять, что является add-in root, а что нет.

	Add-in roots can be bound to one or more assemblies, which can be executables or libraries. Complex applications are usually composed by several assemblies, so it is important to carefully decide what constitutes an add-in root and what not.

	In this example, an application is composed by two executables: a console app and a graphical app. Both executables share the same logic libraries, and the GUI app has a GUI library and a components library. The application defines two add-in roots:		In this example, an application is composed by two executables: a console app and a graphical app. Both executables share the same logic libraries, and the GUI app has a GUI library and a components library. The application defines two add-in roots:

AlexHit в 20:15, 7 декабря 2009

2009-12-07T20:15:01Z

← Предыдущая версия		Версия от 23:15, 7 декабря 2009
Строка 238:		Строка 238:
	Приложения расширения доложны объявлять один, как минимум add-in root, но при необходимости могут объявлять и больше.Определив нсколько add-in roots для приложения состоящего из нескольких модулей. Это один из возможных путей, использования инструмента add-ins , основанный на специфике модулей приложения.например мощь инструмента приложении в логике, в одной сборке и GUI в другой.		Приложения расширения доложны объявлять один, как минимум add-in root, но при необходимости могут объявлять и больше.Определив нсколько add-in roots для приложения состоящего из нескольких модулей. Это один из возможных путей, использования инструмента add-ins , основанный на специфике модулей приложения.например мощь инструмента приложении в логике, в одной сборке и GUI в другой.

			В порядке разрешения этих типов архитектуры, add-in roots должен иметь уникальный идентификатор.Add-ins должен ссылаться на этот ID(идентификатор add-in root).Add-in roots так же имеет номер версии, который используется для поддержания логичности между точками расширения, им используемыми, и расширения представляемых add-ins.


	In order to allow this kind of architectures, add-in roots must have an unique identifier. Add-ins must then specify the add-in root(s) they extend by referencing this ID. Add-in roots also have a version number, which is used to ensure consistency between the extension points they provide, and the extensions provided by add-ins.

	Add-in roots can be bound to one or more assemblies, which can be executables or libraries. Complex applications are usually composed by several assemblies, so it is important to carefully decide what constitutes an add-in root and what not.		Add-in roots can be bound to one or more assemblies, which can be executables or libraries. Complex applications are usually composed by several assemblies, so it is important to carefully decide what constitutes an add-in root and what not.

AlexHit в 19:54, 7 декабря 2009

2009-12-07T19:54:06Z

← Предыдущая версия		Версия от 22:54, 7 декабря 2009
Строка 236:		Строка 236:
	'''Add-in roots'''		'''Add-in roots'''

	~~Extensible applications must declare one~~ add-in root, ~~but they can also declare more than one~~. ~~Defining several~~ add-in roots ~~is useful for applications composed by several modules~~. ~~In this way it is possible to implement~~ add-ins ~~which target specific modules of the application~~. ~~For example~~, ~~an application might implement some logic in one assembly and the~~ GUI ~~in another assembly~~. ~~In this way it would be possible to build add-ins for extending the logic (with no GUI dependencies), and add-ins for extending the GUI, or add-ins extending both:~~		Приложения расширения доложны объявлять один, как минимум add-in root, но при необходимости могут объявлять и больше.Определив нсколько add-in roots для приложения состоящего из нескольких модулей. Это один из возможных путей, использования инструмента add-ins , основанный на специфике модулей приложения.например мощь инструмента приложении в логике, в одной сборке и GUI в другой.

	n order to allow this kind of architectures, add-in roots must have an unique identifier. Add-ins must then specify the add-in root(s) they extend by referencing this ID. Add-in roots also have a version number, which is used to ensure consistency between the extension points they provide, and the extensions provided by add-ins.

			In order to allow this kind of architectures, add-in roots must have an unique identifier. Add-ins must then specify the add-in root(s) they extend by referencing this ID. Add-in roots also have a version number, which is used to ensure consistency between the extension points they provide, and the extensions provided by add-ins.

	Add-in roots can be bound to one or more assemblies, which can be executables or libraries. Complex applications are usually composed by several assemblies, so it is important to carefully decide what constitutes an add-in root and what not.		Add-in roots can be bound to one or more assemblies, which can be executables or libraries. Complex applications are usually composed by several assemblies, so it is important to carefully decide what constitutes an add-in root and what not.