Monikers composites
L’une des fonctionnalités les plus utiles des monikers est que vous pouvez concaténer ou composer des monikers ensemble. Un moniker composite est un moniker qui est une composition d’autres monikers et peut déterminer la relation entre les parties. Cela vous permet d’assembler le chemin d’accès complet à un objet en fonction de deux monikers ou plus qui sont l’équivalent de chemins d’accès partiels. Vous pouvez composer des monikers de la même classe (par exemple, deux monikers de fichier) ou de classes différentes (par exemple, un moniker de fichier et un moniker d’élément). Si vous écriviez votre propre classe de moniker, vous pouvez également composer vos monikers avec des monikers de fichier ou d’élément. L’avantage de base d’un composite est qu’il vous donne un seul élément de code pour implémenter chaque moniker possible qui est une combinaison de monikers plus simples. Cela réduit considérablement le besoin de classes moniker personnalisées spécifiques.
Étant donné que les monikers de différentes classes peuvent être composés les uns avec les autres, les monikers offrent la possibilité de joindre plusieurs espaces de noms. Le système de fichiers définit un espace de noms commun pour les objets stockés en tant que fichiers, car toutes les applications comprennent un nom de chemin d’accès au système de fichiers. De même, un objet conteneur définit également un espace de noms privé pour les objets qu’il contient, car aucun conteneur ne comprend les noms générés par un autre conteneur. Les monikers autorisent la jointure de ces espaces de noms, car les monikers de fichier et les monikers d’élément peuvent être composés. Un client moniker peut rechercher tous les objets dans l’espace de noms à l’aide d’un mécanisme unique. Le client appelle simplement IMoniker::BindToObject sur le moniker, et le code moniker gère le reste. Un appel à IMoniker::GetDisplayName sur un composite crée un nom à l’aide de la concaténation de tous les noms d’affichage de tous les monikers individuels.
En outre, étant donné que vous pouvez écrire votre propre classe moniker, la composition moniker vous permet d’ajouter des extensions personnalisées à l’espace de noms pour les objets.
Parfois, deux monikers de classes spécifiques peuvent être combinés d’une manière spéciale. Par exemple, un moniker de fichier représentant un chemin d’accès incomplet et un autre moniker de fichier représentant un chemin relatif peuvent être combinés pour former un moniker de fichier unique représentant le chemin d’accès complet. Par exemple, les monikers de fichier « c:\work\art » peuvent être composés avec le moniker de fichier relatif .. \backup\myfile.doc » à « c:\work\backup\myfile.doc ». Il s’agit d’un exemple de composition non générique.
La composition générique, en revanche, permet la connexion de n’importe quel monikers, quelles que soient leurs classes. Par exemple, vous pouvez composer un moniker d’élément sur un moniker de fichier, mais pas, bien sûr, l’inverse.
Étant donné qu’une composition non générique dépend de la classe des monikers impliqués, ses détails sont définis par l’implémentation d’une classe de moniker particulière. Vous pouvez définir de nouveaux types de compositions non génériques si vous écrivez une nouvelle classe moniker. En revanche, les compositions génériques sont définies par OLE. Les monikers créés à la suite d’une composition générique sont appelés monikers composites génériques.
Ces trois classes, les monikers de fichiers, les monikers d’éléments et les monikers composites génériques, fonctionnent toutes ensemble, et ce sont les classes de monikers les plus couramment utilisées.
Les clients Moniker doivent appeler IMoniker::ComposeWith pour créer un composite sur moniker avec un autre. Le moniker sur lequel il est appelé détermine en interne s’il peut faire une composition générique ou non générique. Si l’implémentation du moniker détermine qu’une composition générique est utilisable, OLE fournit la fonction CreateGenericComposite pour faciliter cette opération.
Rubriques connexes