Benennungskonventionen für Arbeitsaufgabenverfolgungs-Objekte

Allen Arbeitsaufgabenverfolgungs-Objekten sind ein oder mehrere Namen zugeordnet. Die meisten verfügen über benutzerfreundliche Anzeigenamen, und allen Objekten außer Arbeitsaufgabentypen und globalen Listen sind Verweisnamen zugeordnet. Ein Anzeigename ist ein eindeutiger, für Benutzer sichtbarer Bezeichner für ein Feld, mit dem die Konsistenz für alle Teamprojekte und Arbeitsaufgabentypen in einer Projektauflistung sichergestellt wird. Der Verweisname wird von Team Foundation Server intern verwendet und kann nicht geändert werden, nachdem er definiert wurde.

In der folgenden Tabelle werden die Benennungsanforderungen zusammengefasst, die für jedes Arbeitsaufgabenverfolgungs-Objekt erfüllt werden müssen.

Themeninhalt

• Anforderungen an Anzeigenamen

• Anforderungen an Verweisnamen

• Anforderungen an Feldverweisnamen und Portabilität

• Beispiele für Feldverweisnamen

Anforderungen an Anzeigenamen

Zusätzlich zu den in der obigen Tabelle aufgeführten Anforderungen müssen die definierten Anzeigenamen folgende Anforderungen erfüllen:

• Namen dürfen nicht leer sein.

• Namen dürfen keine vorangestellten oder nachgestellten Leerzeichen enthalten.

• Namen dürfen keine umgekehrten Schrägstriche (\) enthalten.

• Die folgenden Zeichen dürfen in Feldnamen nicht enthalten sein: umgekehrter Schrägstrich (\), Punkt (.) sowie öffnende und schließende eckige Klammern ([]).

• Namen dürfen keine zwei aufeinander folgenden Leerzeichen enthalten.

Anforderungen an Verweisnamen

Beim Hinzufügen oder Erstellen eines Arbeitsaufgabenfelds, eines Linktyps oder einer Kategorie muss immer ein Verweisnamen definiert werden. Verweisnamen können eine maximale Länge von 70 Unicode-Zeichen aufweisen.

Sie können Feldverweisnamen definieren, in denen alphanumerische Zeichen, Unterstriche und Bindestriche vorkommen. Jeder Feldverweisname muss mindestens einen Punkt (.) enthalten, am Anfang oder Ende eines Namens darf jedoch kein Punkt stehen. Ein Verweisname darf nicht mit einer Zahl oder einem Unterstrich beginnen, und er darf keine aufeinander folgenden Bindestriche (--) enthalten.

Feldverweisnamen und Portabilität

Die Definitionssprache für Arbeitsaufgabentypen basiert u. a. auf dem Konzept der Feldverweisnamen. Feldverweisnamen unterstützen Sie beim Portieren von Definitionen zwischen Team Foundation-Projektauflistungen und ermöglichen zudem das Suchen von und Verweisen auf bestimmte Felder durch Drittanbieterintegrationen. Diese Namen sind global eindeutig, ebenso wie ein Namespace in der .NET Framework-Anwendung global eindeutig ist.

Feldverweisnamen können nicht geändert werden. Wenn Sie den Feldnamen beispielsweise von "Titel" in "Header" ändern, bleibt der Feldverweisname dieses Felds unverändert. Bei Integrationen und internen Darstellungen von Feldern muss der Feldverweisname verwendet werden, sodass sie nicht vom Feldnamen selbst abhängig sind.

Mit dem System-Namespace werden lediglich alle Kernsystemfelder definiert, die für die Team Foundation-Systemfunktionen erforderlich sind. Von Team Foundation Server wird verhindert, dass Sie ein eigenes System.X-Feld erstellen, da dies die Funktionalität von Team Foundation Server beeinträchtigen könnte.

Mit dem Microsoft-Namespace werden Felder definiert, die in einer Arbeitsaufgabentyp-Definition einer Microsoft Solutions Framework (MSF)-Prozessvorlage definiert werden. Sie können mit Team Foundation Server jedoch ein eigenes Microsoft.X-Feld erstellen. Davon wird jedoch dringend abgeraten, da dies die Funktionalität von Team Foundation Server beeinträchtigen könnte.

Kunden und Partner können ihre eigenen Feldnamespaces für benutzerdefinierte Arbeitsaufgabentypen erstellen.

Beschreibungen von Systemfeldern und Feldern, die von MSF for Agile Software Development - v5.0 definiert wurden, finden Sie unter Verwenden von Systemfeldern und von den MSF-Prozessvorlagen definierten Feldern.

Beispiele für Feldverweisnamen

In den folgenden Beispielen werden gültige Feldverweisnamen in verschiedenen Namespaces veranschaulicht.

Systemnamespace-Beispiele

System.Id

System.Title

System.CreatedBy

System.CreationDate

System.ChangedBy

System.ChangedDate

System.State

System.Reason

Microsoft-Namespace-Beispiele

Microsoft.Common.Status

Microsoft.Common.Priority

Microsoft.Scheduling.Duration

Microsoft.Scheduling.PercentComplete

Microsoft.Testing.TestCaseName

Beispiele in anderen Namespaces

Kunden und Partner können auch ihre eigenen Namespaces für benutzerdefinierte Arbeitsaufgabentypen definieren. Beispielsweise könnte die fiktive Gesellschaft Trey Research die folgenden benutzerdefinierten Arbeitsaufgabentypen definieren:

TreyResearch.Common.Severity

TreyResearch.Common.Phase

TreyResearch.RiskManagement.RiskType

TreyResearch.RiskManagement.Resolution

Das fiktive Softwarehaus A. Datum Corporation kann die folgenden Arbeitsaufgabentypen definieren:

A_Datum.Common.BusinessPriority

A_Datum.Bug.FoundInPhase

A_Datum.Bug.FixInPhase

Siehe auch

Referenz

FIELD (Definition)-Element

Konzepte

Anpassen von Projektnachverfolgungsdaten, Formularen, Workflow und anderen Objekten