Les règles définies pour un type d'objet et ses sous-types dans un contexte ne remplacent pas d'autres règles définies dans le contexte parent. Mais toutes les règles sont fusionnées pour créer une règle composite. Cette fusion combine des définitions de règles utilisant les hiérarchies de types d'objet et de contextes qui sont en place. Une définition de règle située au plus bas niveau dans la hiérarchie a priorité sur les définitions dans les types et contextes parents. Le type d'objet spécifié lors de la création de la règle et le contexte dans lequel la règle a été créée sont pris en compte.

Lorsqu'aucune valeur par défaut n'est définie pour un attribut d'objet dans la règle composite et que l'utilisateur qui crée l'objet n'attribue pas de valeur à l'attribut, l'un des constats suivants est vrai :

La gestion de la création des articles et des documents CAO par l'intermédiaire des gestionnaires de groupes de travail Windchill peut affecter l'utilisation des règles d'initialisation d'objet qui sont établies pour les attributs de nom et de numéro des articles et des documents CAO. Pour plus d'informations sur les options de gestion disponibles dans les gestionnaires de groupes de travail, consultez la section Utilisation des règles d'initialisation d'un objet pour la dénomination et la numérotation.

Si aucune contrainte n'est appliquée ou si des contraintes vides sont appliquées à un attribut d'objet dans la règle composite en vigueur, aucune modification supplémentaire n'est apportée à l'apparence du champ de valeur lorsque l'interface utilisateur est affichée. Par exemple, le champ présenté est vide et peut être modifié.

Les exemples décrits dans cette rubrique utilisent le contenu des règles qui définit des valeurs par défaut. La fusion des règles incluant des contraintes d'affichage s'effectue de la même manière que pour les règles qui définissent des valeurs par défaut. Les hiérarchies des types et des contextes en place sont utilisées pour fusionner les règles et créer la règle composite.

Lorsque toutes les règles sont définies pour le même type d'objet, la fusion des règles n'utilise que la hiérarchie des contextes établie. Prenons l'exemple suivant :

La règle composite des objets wt.doc.WTDocument créés sous le produit ou l'organisation comprend le paramétrage de la numérotation et de la création des versions, ainsi que le paramétrage des dossiers. Si la règle de produit pour le type d'objet wt.doc.WTDocument avait inclus la configuration du schéma de numérotation, ce paramètre de règle aurait le plus souvent eu priorité sur celui défini dans le contexte de site.

Lorsque toutes les règles sont définies dans le même contexte, la fusion des règles n'utilise que la hiérarchie des types établie. Prenons l'exemple suivant :

La plupart du temps, la règle fusionnée pour com.ptc.General dans le contexte de site comprendrait la définition de la numérotation et de la création de versions issue du type parent (wt.doc.WTDocument) et la définition des dossiers issue de com.ptc.General. La règle composite des objets wt.doc.WTDocument dans le contexte de site n'inclurait pas la définition des dossiers car celle-ci ne figure que dans la règle définie pour le sous-type.

Pour modifier la transmission du parent à l'enfant dans les deux types ou contextes, déclarez les attributs facultatifs final ou ignore dans l'élément AttrValue, AttrConstraint ou VarDef d'un attribut d'objet spécifique. L'utilisation de ces attributs est décrite dans Attributs AttrValue, AttrConstraint et VarDef facultatifs.

Lorsque les règles définies pour un type d'objet spécifique incluent des règles pour un type parent et un type enfant ainsi que des règles dans plusieurs contextes, la fusion s'applique à la fois à la hiérarchie des types et à celle des contextes. Prenons l'exemple suivant :

Avec ces règles, supposons qu'un utilisateur crée un document utilisant le type wt.doc.WTDocument dans le contexte de produit. Alors, les propositions suivantes sont vraies :

La règle composite en vigueur dans ce cas reprend le contenu des deux règles définies dans le contexte de site, mais pas celui de la règle définie dans le contexte de produit pour le dossier par défaut (car le type d'objet spécifié est le type parent wt.doc.WTDocument).

Si un utilisateur crée un document utilisant le sous-type com.ptc.General dans le contexte de produit, alors les propositions suivantes sont vraies :

Dans la règle composite en vigueur, la règle du dossier par défaut définie dans le produit pour le sous-type com.ptc.General est utilisée car elle a priorité sur celle définie dans le contexte de site pour le type parent wt.doc.WTDocument.

Si les hiérarchies de types d'objet et de contextes sont toutes deux impliquées, la hiérarchie de types d'objet du contexte en cours a priorité sur la hiérarchie de contextes. Une règle d'initialisation d'objet pour un sous-type est ignorée lorsque la règle de type de parent existe dans le contexte en cours. Prenons l'exemple suivant :

Si un utilisateur crée un document utilisant le sous-type com.ptc.General dans le contexte de produit, alors les propositions suivantes sont vraies :

Dans la règle composite en vigueur, la règle du dossier par défaut définie dans le produit pour le type wt.doc.WTDocument est utilisée car elle a priorité sur la configuration de dossier de la règle définie dans le contexte de site pour le type parent wt.doc.WTDocument ainsi que sur la configuration de dossier de la règle définie dans le contexte de site pour le sous-type com.ptc.General. Bien que la règle de niveau site définie pour le sous-type com.ptc.General soit du même type que l'objet créé, elle est ignorée par la règle de niveau produit du fait de la hiérarchie des types d'objet.