asp tutorials, asp.net tutorials, sample code, and Microsoft news from 15Seconds
Data Access  |   Troubleshooting  |   Security  |   Performance  |   ADSI  |   Upload  |   Email  |   Control Building  |   Component Building  |   Forms  |   XML  |   Web Services  |   ASP.NET  |   .NET Features  |   .NET 2.0  |   App Development  |   App Architecture  |   IIS  |   Wireless
 
Pioneering Active Server
 Power Search








Active News
15 Seconds Weekly Newsletter
• Complete Coverage
• Site Updates
• Upcoming Features

More Free Newsletters
Reference
News
Articles
Archive
Writers
Code Samples
Components
Tools
FAQ
Feedback
Books
Links
DL Archives
Community
Messageboard
List Servers
Mailing List
WebHosts
Consultants
Tech Jobs
15 Seconds
Home
Site Map
Press
Legal
Privacy Policy
internet.commerce














internet.com
IT
Developer
Internet News
Small Business
Personal Technology
International

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers

HardwareCentral
Compare products, prices, and stores at Hardware Central!

The .NET Architect: Enterprise Template TDL Language
By Brian J. Korzeniowski
Rating: 4.7 out of 5
Rate this article


  • email this article to a colleague
  • suggest an article

    Summary

    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

    1. Visual Studio.NET Enterprise Developer, or Enterprise Architect Edition
    2. VB.NET or C#.NET Programming Knowledge
    3. Read "The .NET Architect: Enterprise Template Overview"
    4. Read "The .NET Architect: Enterprise Template Policy Files"

    Contents

    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 1: Enterprise Template Overview
    • Article 2: Enterprise Template Policy Files
    • 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 the  Visual 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 template  policy 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.

     

    1:  <TDL>

    2:       <CATEGORIES>

    3:            <CATEGORY> <!—ASP.NET Related Project Items -->

    4:                 <ID>catASPProjectItems</ID>

    5:                 <CATEGORYMEMBER>projCSSItems</CATEGORYMEMBER