Templates
The underlying technology for Template implementation is (apache velocity). Velocity is a Java-based Template engine. In the context of ModelPro, the velocity engine is used to generate target artifact content. The velocity Template language is used as-is, with the following additional considerations for the ModelPro environment:
|
· The VTL comment block is used to communicate parametric information to the ModelPro provisioning engine. · The initial evaluation context is established by the ModelPro engine, as described below in the section on Evaluation Context (2). · Templates are located within a “project kind” folder, which is referenced by the <project> element within the Binding Specification.
|
Templates may be edited using an eclipse Text Editor.
A. VTL comment block
The VTL comment block is one of the forms of VTL comments, which is intended to store parametric information about the Template. For ModelPro, this is in the following form:
The syntactic form” @name value” denotes a parameter name/value pair. There are 2 parameters specifically required for ModelPro:
|
· @projectPath: the location to place the generated artifact, relative to the current target Project Context folder. This is expressed as a VTL expression, interpreted within the provided Evaluation Context described below. · @artifactContext: This is a string which identifies a named <artifactContext> within the Binding Specification. The specified Artifact Context expression is evaluated within the current Project Context to yield a set of model element instances. Each instance is expanded to an Evaluation Context for one execution of the Template, generating one target artifact.
|
B. Evaluation Context
The evaluation context is based on the model element instance selected by the <artifactContext> expression within the Binding Specification. Each element accessible via XPATH expression from the current Artifact Context is made available as a VTL property with the same name. VTL navigation from the provided Evaluation Context variables is via the VTL property and method mechanisms, which operate directly on the underlying java objects. Additionally, a variable named ${object} provides direct access to the java object underlying the current Artifact Context (to facilitate access to parameterized operations on, and macro invocation for, the selected Artifact Context).
C. Template
Configuration
The overall Template configuration is based on the following pattern:
|
· global folder o project folder (for each project kind) § resource file (including Template, velocimacro, other) o override folder § resource file (including Template, velocimacro, other) o default folder § resource file (including velocimacro, other)
|
Resolution of resources with the same name in multiple folders is based on the following precedence:
|
· override. Resources in this folder have highest precedence. This is the folder in which shared resources across all projects may be placed. · project. Resources in a project folder are available within the applicable Project Context, as defined in the <project> element of the Binding Specification. Exactly one project folder is associated with a Project Context. · default. The default resources have lowest precedence. Resources may include velocimacro and other files. Template files are ignored in this folder, since they are always lower precedence than project or override Templates.
|
A resource file may be one of the following:
|
· *.Template file. Each Template available for processing must have an extension “.Template”. The Template itself may be empty if it is overridden by an override /*.Template file, but it must be present in a project folder to be considered a targeted artifact for the project. · Velocimacro files. These files contain VTL macros which are automatically available for all Template evaluations. Note that precedence of macro selection is based on resource name, independent of resource location. There are 3 names which may be used: o VM_global_library.vm. This name is intended for use within the project folder. Macros within this resource have the highest precedence. o VM_override_library.vm. This name is intended for use within the override folder. Macros within this resource have medium precedence. o VM_default_library.vm. This name is intended for use within the default folder. Macros within this resource have lowest precedence. · Other files. Any other resource may be referenced by the VTL directives #include(?) and #parse(?), according to the resource resolution precedence described above.
|
D. Example
In the Binding Specification example, the “wsdl.Template” was used to explain concepts related to binding. Additional elaboration of that Template will be provided here:
As described earlier, the named Artifact Context “port” is used to identify an <Artifact Context > which has an XPATH @select expression used to specify a set of Artifact Context instances. The Template is evaluated for each Artifact Context instance. For this example, the Artifact Context instance is the port named “solicitationPort” on the component named “Solicitation Manager Composite Application”.
The @projectPath parameter within the VTL comment block is a VTL expression evaluated in the context of the current Artifact Context instance. The result of evaluating the expression is the relative path, from the current target project, to the location of the target artifact. An explanation for this expression:
|
· /src/jbiasa/ this part of the path is a constant · ${type references the “type” of current Artifact Context instance (which is a UML Class named “SolicitationManager” · .name} returns the name of the selected UML Class (“SolicitationManager”) · .wsdl this part of the path is a constant
|
The VTL directive “#bindingWsdl()” references a macro defined in a velocimacro library. In this case, the library is located in the same folder, with the name “VM_global_library.vm”. Examining the fragment of that library which defines the “#bindingWsdl()”:
The syntax for VTL itself is pretty well documented in the Velocity User Guide. The focus of this example is to illustrate the relationship between VTL expressions and navigation through the source model. An explanation of the highlighted VTL expression:
|
· ${type selects the “type” property of the current Artifact Context instance (which is the “solicitationPort”). The result is the “SolicitationManager” UML Class. · .allImplementedInterfaces} selects the set of all implemented UML Interfaces for the “SolicitationManger” class. In this case, the result consists of a single entry, the “SolicitationService” UML Interface.
|
The VTL #foreach directive iterates through each entry of the selected set, with the variable $ifc holding the current entry.
A visualization of this in terms of a UML diagram, where the highlighted item is the $ifc entry:
Figure 11Template Expression Selection:UML Diagram Rendering
All navigations are based on EMF model API. For the example provided, the UML API should be consulted. With respect to the example expression, the javadoc description for allImplementedInterfaces is:
