Template Reference

In the wiki page Angular Template Reference, we provided some detail and background on the default Angular based template. The template includes a general framework of scripts for making WebAPI calls while the plugin will generate entity specific classes and interfaces for strongly typed scripting using TypeScript.

If this model works, then you should not need to make any changes to the template. If you would like to make updates, you can modify a copy of the template and use that version when generating your scripts. Or, you can use the tool to generate output that just provides a bit of information about your entities!

Samples of the templates are included in the Samples folder.

Template Structure and Syntax

A few different templating engines were investigated for this tool, but each had dependencies that were not portable. For example, Brendon initially wrote this templating tool as a windows application with a dependency on the Typewriter add in for Visual Studio. So we could not deploy as a plugin. A few others were reviewed but nothing suited the portable need.

So we wrote a very simple template model that relies on Xml and some regular expressions to get this done. The template itself is an Xml file with a simple structure:

<template>
	<![CDATA[ ]]>
	<entity>
		<![CDATA[ ]]>
			<attribute_list><![CDATA[ ]]></attribute_list>
		<![CDATA[]]>
	</entity>
	<![CDATA[ ]]>
</template>

This describes the general hierarchy used when generating the EntityMetadata and AttrbuteMetadata output: the template is the root, with child entity elements, which contain child attribute list elements.

Our current implementation is a bit of a brute force approach for now. Downstream, we plan on updating this syntax to add flexibility on looping. For example, if an attribute is a collection, such as an Array or List<>, we can iterate.

The <template> element provides a start and stop point for the overall parsing. Each <![CDATA[]]> section serves as the placeholder for the output content, the generating context based on its current parent element.

Available Properties

Within each of the CDATA sections, you can place the property escape elements. The context of the parent Xml element determines the which properties are available. For example, within the entity element, the global properties are available but no attribute properties are available. Within the attribute_list element, the attribute properties are available as well as the global and entity properties.

Generating the property relies on some syntax to escape the property. This syntax is similar to many others formats, using curly braces to wrap property values. The general format looks like:

{# variable #}

We have some 'hard wired' properties are available that provide Project Setting values for output.

• {#module_name#}: Module Name value from Project Settings
• {#module_notes#}: Module Notes value from Project Settings

To distinguish between entity and attributes, we provide an additional escape prefix. So for entities and attributes, we have:

• {#ent (property)#}: case insensitive property name. Ex: {#ent (IsSLAEnabled) #}
• {#attr (property)#}: case insensitive property name. Ex: {#attr (AttributeType) #}

For some additional output formatting, such as changing case, both entity and attribute metadata objects support these escape methods. :

• {#ent/attr upper(property)#}: converts the property value to upper case. Ex: {#ent (IsSLAEnabled) #} would result in TRUE or FALSE as the output.
• {#ent/attr lower(property)#}: converts the property value to lower case
• {#ent/attr title(property)#}: converts the property value to title case. Ex: {#ent (IsSLAEnabled) #} would result in True or False as the output.

For attribute properties, we provide some additional special output values.

• {#attr dt(AttributeType)#}: the attribute CRM data type converted to script data type. Currently, these are converted to either string or number. In later releases, we would like to provide the ability to map these via configuration.

NOTE: only applies to the attribute property of AttributeType which is an AttributeTypeCode

• {#attr api(SchemaName)#} - requires special formatting for Lookup attribute properties for the WebAPI calls. For example, the attribute createdby will be formatted named _createdby_value for the WebAPI query.

NOTE: only applies to the attribute SchemaName

The full Xml of the default Angular based template can be reviewed here: Angular.Xrm.ts.xml. You will see that the bulk of the template consists of the Angular scripts and the actual templated properties is relatively small.

For a much simpler example, you can refer to the sample template Xrm.Template.Sample.xml. This sample will simply generate a few entity property values and attribute property values in a list. This is the entire contents:

<template>
  <entity>
	<![CDATA[Entity Logical Name: {#ent title(LogicalName)#}, IsActivity: {#ent (IsActivity)#} ]]>
	<attribute_list>
<![CDATA[	Attribute Schema Name: {#attr api(LogicalName)#}	For WebAPI: {#attr api(SchemaName)#}	Data Type: {#attr dt(AttributeType)#}]]>
	</attribute_list>
  </entity>
</template>

You can see the entity properties usage, the attribute properties usage, and some of the special escaping syntax. The output would look something like this:

Entity Logical Name: Team, IsActivity: False  
	Attribute Schema Name: traversedpath	For WebAPI: traversedpath	Data Type: string  
	Attribute Schema Name: transactioncurrencyidname	For WebAPI: transactioncurrencyidname	Data Type: string  
	Attribute Schema Name: administratorid	For WebAPI: _administratorid_value	Data Type: string  

Properties Reference

For a list of available property values, you can refer to the SDK Online.
Entity metadata properties: EntityMetadata Class

Attribute metadata properties: AttributeMetadata Class