This section describes the AMP plug-ins, extensions, and extension points.
Each AMP application comprises a set of AMP plug-ins, the functional units of an AMP application. As a developer, you decide how to decompose the application into its constituent plug-ins. Consider plug-ins to be application components that are either present (loaded) or absent (unloaded). In other words, design cohesive plug-ins that contain the parts of the application that function together, and tie plug-ins loosely to each other.
When decomposing an application, keep in mind that an AMP application loads at the granularity of plug-ins; by default, all parts of a plug-in are loaded together.
Plug-ins are defined with a plugin.xml descriptor file. Each plug-in has a unique identifier that is also the name of the directory in which the plugin.xml file is placed.
In the following example, the plug-in identifier is com.tibco.example.p1.
To register plug-ins, refer to them in the plugins.xml file, and place the file in the plugins directory at the root of the General Interface application that uses AMP. Alternatively, you can use the AMP API to register plug-ins programmatically. For each plug-in registered in the plugins.xml file, there should be a directory in the plugins directory with a name equal to the ID of the registered plug-in. Each of these directories should contain a plugin.xml file.
The following figure shows the plugins directory structure.
An extension point is declared in a plug-in descriptor file.
An extension is a concrete implementation of the extension point contract. You can define an extension in the same plug-in that defines its extension point or in another plug-in. In both cases, the point attribute of the extension element is the fully-qualified identifier of the extension point. The fully-qualified identifier is the id attribute of the extension-point element appended to the identifier of its plug-in and separated with a period (".").
The extension point-extension relationship is loosely coupled and controlled by the extension point. It is possible for an extension to extend an extension point that is not registered. Similarly, it is usually acceptable for an extension point to have no extensions.
Resources can declare a load setting with the load attribute, as in the example above. The possible values are early, normal (the default value), and manual. The load setting affects when the resource is loaded in relationship to the plug-in life cycle.
AMP plug-in life cycle follows this process:
XML, XSL and dynamic properties resources are defined inline as a document fragment. When defining these resources inline, make sure that you define the correct XML namespace for the content. If the xmlns attribute is not specified, the document fragment will inherit the AMP XML namespace.
Plug-ins and resources can define dependencies that enforce a load order. You must declare dependencies in order for the load order of application resources to be well-defined.
A plug-in can depend on another plug-in by declaring that it requires it in its descriptor file. When a plug-in requires another plug-in, then the required plug-in will load (step 5, above) before the requiring plug-in. In addition, the required plug-in is instantiated before the requiring plug-in. This means that all early load resources of the required plug-in are loaded before the early load resources of the requiring plug-in.
Similarly, a resource may require that another resource be loaded before it is loaded. A resource can also declare that a plug-in loads before the resource. This second option is useful for manual load resources for which the plug-in does not declare the dependency. In the following example, the com.tibco.example.lib plug-in loads before logic.js and logic.js loads before SampleClass.js.