Recherche de nom dans les points d'ancrage Perl

Le langage Perl comporte plusieurs types de variable. Les types courants sont les suivants :

Vous devez spécifier des variables globales avec des noms uniques. Vous pouvez également utiliser des variables locales, à l'aide de la convention my. Exemple :

my ($uvComponent);
Remarque : Lorsque vous définissez une variable en tant que variable locale dans un point d'ancrage Perl, utilisez la déclaration my.

Des incidents liés à la recherche de nom peuvent se produire sur les points d'ancrage Perl existants. Une action Rational ClearQuest, telle que Submit, utilise un interpréteur Perl unique pour exécuter tous les points d'ancrage d'action, comme Action Initialization, et tous les points d'ancrage de zone, comme Field Value Changed, qui sont écrits en Perl. Si le code de point d'ancrage ne déclare pas les variables locales avec le mot clé my avant de les utiliser, la variable peut être partagée entre les points d'ancrage accidentellement.

Dans les versions antérieures à 2003.06.00, lorsqu'un point d'ancrage Perl en appelle un autre, le second point d'ancrage est compilé dans un espace de noms Perl différent. Dans la version 2003.06.00 et ultérieures, tous les points d'ancrage sont compilés dans le même espace de noms Perl. Cela peut modifier le comportement des points d'ancrage les uns par rapport aux autres, si des variables globales sont utilisées. Exemple :

sub defect_Initialization

{

 $variable = "1";

 $entity->SetFieldValue("A", $variable);

}

sub a_ValueChanged

{

 $entity->SetFieldValue("B", $variable);

 $entity->SetFieldValue("C", $variable);

}

sub b_ValueChanged

{

 $variable = "3";

} 

La variable $variable, dans ces sous-programmes de point d'ancrage, est une variable au niveau des packages. Cela signifie que les sous-programmes d'un même package partagent la même variable.

Dans les versions antérieures à 2003.06.00, les points d'ancrage imbriqués se trouvent dans un package Perl différent de celui du point d'ancrage initial et ne partagent donc pas leurs variables globales avec ce dernier. Cela signifie que l'exemple précédent est interprété comme si les qualificateurs d'espace de noms suivants étaient indiqués :

package main;

sub defect_Initialization

{

 $main::variable = "1";

 $entity->SetFieldValue("A", $main::variable);

}

package CQEntity;

sub a_ValueChanged

{

 # $CQEntity::variable n'est pas défini, il s'agit donc d'une chaîne vide par défaut.

 $entity->SetFieldValue("B", $CQEntity::variable);

 $entity->SetFieldValue("C", $CQEntity::variable);

}

sub b_ValueChanged

{

 $CQEntity::variable = "3";

} 

Un point d'ancrage Field Value Changed est appelé immédiatement après le changement de la zone associée (c'est-à-dire avant le renvoi depuis SetFieldValue) ; le code précédent s'exécute donc dans l'ordre suivant :

 $main::variable = "1";    # From defect_Initialization;

       # $main::variable is set to "1"

 $entity->SetFieldValue("A", $main::variable); # From defect_Initialization

       # Sets A to "1"

       # Rational ClearQuest calls a_ValueChanged before returning

 $entity->SetFieldValue("B", $CQEntity::variable); # From a_ValueChanged

       # $CQEntity::variable is uninitialized

       # Sets B to ""

       # Rational ClearQuest calls b_ValueChanged before returning

 $CQEntity::variable = "3";   # From b_ValueChanged

       # $CQEntity::variable changes from "" to "3"

 $entity->SetFieldValue("C", $CQEntity::variable); # From a_ValueChanged

       # Sets C to "3" 

Par conséquent, les zones A, B et C sont définies respectivement sur "1", "" et "3".

Depuis la version 2003.06.00, les points d'ancrage Perl sont compilés dans le même espace de noms. L'exemple précédent est à présent interprété comme si les qualificateurs d'espace de noms suivants étaient indiqués :

package main;

sub defect_Initialization

{

 $main::variable = "1";

 $entity->SetFieldValue("A", $main::variable);

}

sub a_ValueChanged

{

 $entity->SetFieldValue("B", $main::variable);

 $entity->SetFieldValue("C", $main::variable);

}

sub b_ValueChanged

{

 $main::variable = "3";

} 

Ce code s'exécute dans l'ordre suivant :

 $main::variable = "1";    # From defect_Initialization;

       # $main::variable is set to "1"

 $entity->SetFieldValue("A", $main::variable); # From defect_Initialization

       # Sets A to "1"

       # Rational ClearQuest calls a_ValueChanged before returning

 $entity->SetFieldValue("B", $main::variable); # From a_ValueChanged

       # Sets B to "1"

       # Rational ClearQuest calls b_ValueChanged before returning

 $main::variable = "3";    # From b_ValueChanged

       # $main::variable changes from "1" to "3"

 $entity->SetFieldValue("C", $main::variable); # From a_ValueChanged

       # Sets C to "3" 

Par conséquent, les zones A, B et C sont définies respectivement sur "1", "1" et "3".

Pour éviter un partage involontaire de valeurs de variable, vous devez déclarer ces variables devant être locales à une fonction de point d'ancrage en utilisant la syntaxe suivante :

sub d_ValueChanged

{

 my $temp = $entity->GetFieldValue("d")->GetValue();

 $session->OutputDebugString("d now set to $temp\n");

} 

où la variable $temp est déclarée comme étant locale à la fonction d_ValueChanged et cette affectation à $temp ne modifie pas la valeur d'une autre variable du même nom. La syntaxe my permet de rendre cette variable visible uniquement dans un bloc de code spécifié.

Remarque : $entity et $session sont des variables globales définies par le modèle de base Rational ClearQuest.

Commentaire