This article will explain each grammar element comprising the Enterprise Template Definition Language (TDL). You will learn about the TDL Grammar Hierarchy and where each grammar element fits in that hierarchy. Finally, you will study each TDL Grammar Element and be shown an example of its use.
This series is designed around two central premises: first, this series teaches foundational concepts of Enterprise Templates. Second, this series demonstrates how to create Enterprise Templates using various types of available Visual Studio .NET Projects. This article series will benefit two types of audiences the best: individuals curious about Enterprise Templates (with little knowledge or experience developing Enterprise Templates), and individuals familiar with the fundamental concepts of Enterprise Templates (but seeking a more application-oriented, tools-development approach to constructing Enterprise Templates).
Many of you have written and thanked me for explaining .NET Technology in easy-to-understand terms. Many of you have also asked if there will be books or more articles in the works. The answer is "YES" to both questions. I am currently trying to drum up support for a book on "Microsoft .NET CodeDom Technology." I am presently refining the outline for this book. You can visit my Web site at http://www.brandari.net. One of the initiatives underway is a full explanation of every .NET class, property, method, event, enumeration, interface, and construct in the .NET Framework - explained in easy to understand terms. The Web site is continually being added to and refined, so feel free to stop by and check it out. Thank you for your support and all the great feedback.
The .NET Architect Enterprise Template Series will help you build the following projects:
Enterprise Template Editor Add-In
Enterprise Template Editor Web Service
Enterprise Template Editor Windows Service
Enterprise Template Editor Web Control
Enterprise Template Editor Windows Control
Enterprise Template Editor Framework
Requirements
Visual Studio.NET Enterprise Developer, or Enterprise Architect Edition
Section 1: Introduction Section 2: TDL Grammar Elements Section 3: TDL Grammar Element Explanations Summary About The Author
Section 1: Introduction
To fully master any technology, you must first recognize the need to understand its fundamental concepts, terminology, and its dependencies on other technologies. This article will explain each Template Definition Language (TDL) tag. You will learn the basic, fundamental concept behind each tag, learn when to use it, and learn how to use it through practical code examples. It is imperative that you understand the basics of Enterprise Template Technology, including the Enterprise Template Definition Language (TDL) before you attempt to create your own template projects. If you have been reading this series and felt a little bewildered, take heart. In the next few articles, you will begin to actually create your own Enterprise Templates Projects, configure your own Policy Files, and see your templates in action.
Enterprise Template TDL Grammar elements are called nodes, which are created using an XML syntax. TDL Grammar Elements are written in UPPERCASE. Nesting of TDL Elements is enforced by consulting the TDLSchema.xsd file. Only nodes contained within the TDLSchema.xsd file may be used in creating policy files. Although you can use any text editor when creating Enterprise Templates, I recommend using Microsoft Visual Studio .NET. The productivity gains and time saving features are well worth the extra price tag.
As you near the informational conclusion to this series, you will begin to apply the knowledge you have learned toward building Enterprise Template Editors using several different types of Visual Studio .NET Projects. By doing so, you will expand your programming horizons into different areas such as add-ins, Web services, and Web controls. In addition, by implementing enterprise templates using various project types you will gain valuable breadth of experience in your .NET Development knowledge.
The .NET Architect Enterprise Template Series comprises the following articles:
Article 3: Enterprise Template TDL Language <-- YOU ARE HERE
Article 4: Enterprise Template Dynamic Help
Article 5: Enterprise Template Exercise
Article 6: Enterprise Template Editor Add-In
Article 7: Enterprise Template Editor Web Service
Article 8: Enterprise Template Editor Windows Service
Article 9: Enterprise Template Editor Web Control
Article 10: Enterprise Template Editor Windows Control
Article 11: Enterprise Template Editor Framework
Article 12: Enterprise Template Developer Notes
Section 2: TDL Grammar Elements
<CATEGORIES>
Defines a container for grouping
logically similar elements defined elsewhere in the policy file
<CATEGORY>
Defines a reusable grouping of
logically similar elements
<CATEGORYMEMBER>
Defines a reference to a predefined
policy file element
<CMDID>
Defines the absolute position ID of
a menu item in a menu hierarchy
<CONSTRAINTS>
Defines a container for defining
restrictions on IDE properties, menus, and toolbox items
<CONTEXT>
Defines the content information
displayed by the Dynamic Help Window when navigating between IDE elements
<CTXTATTRIBUTE>
Defines a container for resolving
contextual switching and initialization issues related to dynamic help within
theVisual Studio .NET IDE
<DEFAULT>
Defines a default value for
automatically initializing a property
<DEFAULTACTION>
Defines the default inclusion or
exclusion setting to apply to a group of policy file elements
<DEFAULTSETTINGS>
Defines global enterprise
templatepolicy file settings for
each element
<DESCRIPTOR>
Defines a unique ID for an IDE
toolbox control
<ELEMENT>
Defines a unique enterprise template
building block
<ELEMENTS>
Defines a collection of all building
blocks available to an enterprise template
<ELEMENTSET>
Defines a container for grouping
building blocks
<ENABLED>
Defines an enabled or disabled state
for a menu item or toolbox item
<EXCLUDE>
Defines which template building
blocks are not permitted to be referenced from within the context of another
building block
<FEATURELINKS>
Defines which set of menu or toolbox
features may be associated to a specific template building block element
<FEATURES>
Defines the collection of menu and
toolbox items to be restricted via policy
<GUID>
Defines a globally unique identifier
for an IDE menu group
<ID>
Defines a mechanism for referencing
a node from other places in the policy file
<IDENTIFIER>
Defines locating, identifying and
configuration information about a specific policy file element
<IDENTIFIERDATA>
Defines a name/value pair for
processing references to elements
<IDENTIFIERS>
Defines a collection of identifying
nodes containing location, identification and configuration information for
specific elements
<INCLUDE>
Defines the ID of an element to
include in another place in the policy file
<MAXVALUE>
Defines the maximum allowable value
a property or element may contain
<MEMBERCONSTRAINT>
Defines restrictions on specific
element based upon an ID.
<MEMBERCONSTRAINTS>
Defines a collection of restraints
applying to specific menu, toolbox, or properties based upon an ID
<MENU>
Defines a menu item for later
reference in the policy file
<MENUCONSTRAINT>
Defines the enabled or disabled
restraint for a menu item
<MENUCONSTRAINTS>
Defines a collection of
context-based restricted menu items
<MENULINK>
Defines a relationship where a menu
item is disabled if the associated item is defined elsewhere in the policy
file with an exclusion setting
<MENULINKS>
Defines a collection of menu items
to be disabled when the associated item has the exclusion property set
<MENUS>
Defines a collection of menus to be
included in the policy file
<MINVALUE>
Defines a minimum allowable value
for an element
<NAME>
Defines a reference identifier for
accessing the node containing the value
<ORDER>
Defines the order in which
include/exclude settings are evaluated within a policy file element
<POLICYMODE>
Defines the mechanism for handling
undefined or unrecognized items
<PROPERTYCONSTRAINT>
Defines scope-restricted settings
for properties displayed within the IDE properties browser window
<PROPERTYCONSTRAINTS>
Defines a collection of
scope-restricted settings for properties displayed within the IDE properties
browser window
<PROTOTYPE>
Defines the location of a project,
item or enterprise template project from which a specific type of project can
be created
<PROTOTYPES>
Defines a collection of location
information for finding and creating specific types of enterprise template
projects
<READONLY>
Defines if a property is allowed to
be edited
<TDL>
Defines the root node of a policy
file, which contains all other policy file elements
<TOOLBOXCONSTRAINT>
Defines if a specific toolbox item
should be contextually enabled or disabled
<TOOLBOXCONSTRAINTS>
Defines a collection of toolbox
items that should be contextually enabled or disabled
<TOOLBOXITEM>
Defines an item to display within
the toolbox
<TOOLBOXITEMS>
Defines a collection of items to
display within the toolbox
<TOOLBOXLINK>
Defines a relationship where a
toolbox item is disabled if the associated item is defined elsewhere in the
policy file with an exclusion setting
<TOOLBOXLINKS>
Defines a collection of toolbox
items to be disabled when the associated item has the exclusion property set
<TYPE>
Defines a label identifying the type
of the logical element
<VALUE>
Defines the data portion of a name/value
pair
( figure 1.0 )
Section 3: TDL Grammar Element Explanations
<CATEGORIES> Defines a container for grouping logically similar
elements defined elsewhere in the policy file
Example:
You want to create a list of
artifacts developers are allowed to add to ASP.NET Web applications.
Explanation:
To enforce this restriction, first
define the allowable set of artifacts your developers can add to an ASP.NET
Web application.You decide
developers should add only CSS, HTML, XML and XSL items to ASP.NET Web
applications.These items are defined
elsewhere in your policy file.To
create your <CATEGORIES> node, you assigned it an identifier named
“catASPProjectItems.”You can see
this in line #4.Next, add each type
of Web item grouping to your <CATEGORIES> node by referencing its
existing unique ID value.This
process is shown in lines #5 - #8.Each web item grouping is listed inside a <CATEGORYMEMBER>
definition.
1:<TDL>
2:<CATEGORIES>
3:<CATEGORY> <!—ASP.NET Related Project
Items -->
4:<ID>catASPProjectItems</ID>
5:<CATEGORYMEMBER>projCSSItems</CATEGORYMEMBER>
6:<CATEGORYMEMBER>projHTMLItems</CATEGORYMEMBER>
7:<CATEGORYMEMBER>projXMLItems</CATEGORYMEMBER>
8:<CATEGORYMEMBER>projXSLItems</CATEGORYMEMBER>
9:</CATEGORY>
10:</CATEGORIES>
11: </TDL>
<CATEGORY>
Defines a reusable grouping of
logically similar elements
Example:
You want to group all technologies
available to your ASP.NET developers.
Explanation:
You determined your developers work
primarily with these Web technologies: ASP, HTML, CSS, XML, and XSL.The categories for these Web technologies
are defined elsewhere in the policy file.To include these groups in your own grouping, you need to reference
the existing groups by their names or IDs.Finally, to create your own category, implement line #3-9 below.These lines define a custom category of
pre-existing element groupings.Label
your new group by assigning a value to the <ID> node.This is done in line #4.
1:<TDL>
2:<CATEGORIES>
3:<CATEGORY> <!—ASP.NET Related Project
Items -->
4:<ID>catASPProjectItems</ID>
5:<CATEGORYMEMBER>projCSSItems</CATEGORYMEMBER>
6:<CATEGORYMEMBER>projHTMLItems</CATEGORYMEMBER>
7:<CATEGORYMEMBER>projXMLItems</CATEGORYMEMBER>
8:<CATEGORYMEMBER>projXSLItems</CATEGORYMEMBER>
9:</CATEGORY>
10:</CATEGORIES>
11: </TDL>
<CATEGORYMEMBER>
Defines a reference to a predefined
policy file element
Example:
You are designing template category
nodes referencing predefined policy categories.You want to create four nodes, each node referencing a unique,
preexisting category of items.
Explanation:
First, identify the preexisting
categories you want to add to your policy file.You decide to add these preexisting categories: CSS, HTML, XML,
and XSL technologies.Your new
category node is placed within its own grouping, by adding line #3
below.Your new category node should
apply to only ASP programming projects; therefore, locate the ID of the
existing group which is shown in line #4.Next, create a <CATEGORYMEMBER> node for each preexisting
category you want to reference (CSS, HTML, XML, XSL).Finally, give each grouping a unique ID
corresponding to its definition elsewhere in the policy file.This can be seen in lines #5-8 below.