La Properties Page de 3U

Application), je ne
peux pas utiliser l’événement Window_
Onload pour charger initialement
la page. C’est pourquoi j’attribue
la sous-routine LoadPage à  l’événement
onLoad de l’élément body.
LoadPage construit la User Account
Properties Page de la même manière
que la sous-routine Window_Onload le
fait pour UserUpdate.hta.
SetIndividualElement est un appel
de sous-routine qui n’est pas présent
dans la séquence de chargement de
UserUpdate.hta, mais est présent dans
PropPage.htm. La sous-routine SetIndividualElement
définit les attributs
pour la zone de texte Street de la page
et la boîte de liste déroulante Country.
Si l’on excepte quelques ajustements
mineurs apportés aux attributs de l’élément
textArea, cet élément fonctionne
de la même manière que les éléments
input de la page. En revanche, l’élément
CountryNameSelect (qui est une
liste déroulante) fonctionne de manière
très différente du reste de la
page.
En utilisant la méthode SelectNode
de l’objet XMLDOMDocument, la
sous-routine SetIndividualElements
peuple la liste déroulante Country avec
les noms de pays que le fichier
iso3166.xml contient. Comme nous
l’avons vu dans la 1ère partie, à  cause
des restrictions de copyright, la version
d’iso3166.xml incluse avec 3U
n’est qu’un échantillon de la liste complète
des noms et des codes de pays
que fournit l’ISO (International
Organizational for Standardization).
L’élément xml suivant dans le corps
principal de PropertiesPage.htm spécifie
le fichier iso3166.xml exemple
comme le fichier source de données :

<xml id="CountryXML"
src="iso3166.xml"></xml>

La sous-routine SetIndividualElement
utilise la méthode createElement
de l’objet document DHTML pour
créer des éléments option pour
chaque nom de pays. Ensuite, elle utilise
la méthode add de l’élément select
pour attribuer chaque élément option
à  la liste déroulante Country.
ADSISearch est la dernière sousroutine
que LoadPage appelle. Elle demande
un paramètre d’entrée : le DN
(distinguished name) du compte utilisateur
à  rechercher. La ligne de code
suivante passe le DN du compte utilisateur
sélectionné à  ADSISearch :

Call ADSISearch
  (Window.dialogArguments)

La propriété WindowdialogArguments
contient le DN du compte utilisateur,
que la sous-routine EditScript
dans UserUpdate.hta a fourni à  la propriété
dialogArguments. Dans le listing
3, on voit que EditScript attribue la variable
strDN au deuxième paramètre
de la méthode Window.showModelessDialog.
La variable strDN est initialisée
avec la valeur de l’attribut
distinguishedName précédemment
stockée dans l’attribut nom du bouton
Edit.
En utilisant le DN du compte utilisateur,
la sous-routine ADSISearch interroge
le compte utilisateur pour les
attributs qui apparaissent finalement
dans les champs de PropPage.htm.
L’un des attributs, mailNickname, n’est
présent que si une installation
Exchange 2003 ou Exchange 2000 a
étendu le schéma AD. Pour justifier 3U
dans des organisations qui n’utilisent
pas Exchange 2003 ou Exchange 2000,
j’ai ajouté un mécanisme de vérification
d’erreurs à  ADSISearch, comme le
montre le code du renvoi A dans le listing
Web 2. Si la première requête
LDAP (Lightweight Directory Access
Protocol) échoue à  cause d’un attribut
manquant, la sous-routine retente la
requête mais substitue l’attribut cn à 
l’attribut mailNickName dans le dialecte
de requête LDAP. L’attribut cn sert
simplement d’emplacement de requête
LDAP et n’apparaît pas dans la
User Account Properties Page. ADSISearch
affiche aussi un message dans
PropPage.htm pour vous informer
que, parce que Exchange 2003 ou
Exchange 2000 n’est pas installé, le
champ EMail Alias a été désactivé. Ce
champ contient la valeur de l’attribut
mailNickName.
Après une requête d’AD fructueuse,
ADSISearch attribue une valeur
à  chaque champ dans PropPage.
htm, y compris la liste déroulante
Country. Deux facteurs viennent compliquer
le code de cette tâche.
Premièrement, les attributs multivaleurs
– particulièrement description et
postOfficeBox – sont renvoyés à  la
sous-routine en tant que matrices.
Deuxièmement, pour la liste déroulante
Country, la sous-routine attribue
un nom de pays en sélectionnant un
élément option que l’élément sélectionné
contient.
Le code du renvoi B dans le listing
Web 2 montre comment ADSISearch
traite les attributs multivaleurs. La
sous-routine utilise la fonction
VBScript ISArray pour identifier les valeurs
de matrice, puis la fonction
VBScript LBound pour attribuer la première
valeur de la matrice au champ.
Pour plusieurs raisons, la sous-routine
n’attribue qu’une valeur dans ces attributs
multivaleurs. Premièrement, l’attribut
description est défini comme
multivaleurs mais se comporte comme
un attribut monovaleur. Microsoft a défini
cet attribut comme multivaleurs
pour des raisons de rétrocompatibilité.
L’attribut postOfficeBox fonctionne
comme un attribut multivaleurs et accepte
donc des entrées multiples ; cependant,
si vous visualisez le champ
P.O. Box dans le snap-in Microsoft
Management Console (MMC) Active
Directory Users and Computers, vous
voyez qu’il ne prend qu’une valeur. Si
vous attribuez une valeur au champ
P.O. Box dans le snap-in Active
Directory Users and Computers, la
sous-routine efface les éventuelles entrées
contenues dans l’attribut
postOfficeBox et ajoute votre entrée.
Par conséquent, bien que les deux attributs
soient définis comme multivaleurs
et renvoient une matrice à  partir
d’une requête LDAP, vous pouvez travailler
avec les attributs comme s’ils
étaient monovaleurs.
Le code du renvoi C dans le listing
2 montre comment ADSISearch utilise
l’attribut co du compte utilisateur et la
propriété SelectedIndex de l’élément
select pour sélectionner le nom de
pays approprié. Si l’attribut co n’est pas
assigné au compte utilisateur dans AD,
SelectedIndex de l’élément select est mis à  zéro, ce qui ne définit d’aucune
manière la liste déroulante Country. Si
l’attribut co est assigné au compte utilisateur,
la valeur de l’attribut co est
comparée à  la propriété text de l’élément
option jusqu’à  ce qu’une correspondance
soit trouvée. Quand il y a
correspondance, la propriété selected-
Index de l’élément select, basée sur
zéro, est mise à  une valeur inférieure
de 1 à  l’index correspondant de la valeur
de l’élément option.
Tous les attributs existants et leurs
valeurs apparaissent désormais dans la
User Account Properties Page. L’action
suivante de 3U consiste à  déterminer si
vous avez modifié certaines des valeurs
qui apparaissent dans PropPage.htm.
Dans la sous-routine ADSISearch,
chaque élément de formulaire que
vous pouvez changer a la sous-routine
DetectChange attribuée à  son événement
onChange. La sous-routine
DetectChange ajoute un symbole pipe
à  la valeur id de chaque élément
changé et stocke la valeur entière dans
un élément input caché appelé
ChangedFieldsInput.