Guide de programmation de Apache OpenOffice BASIC
Le cadre (framework)[1] dispatch décrit dans le dernier chapitre (cf. le DevGuide en VO, à lire depuis le début, c-à-d : http://wiki.openoffice.org/wiki/Documentation/DevGuide/OfficeDev/Using_the_Dispatch_Framework) établit une communication entre une interface utilisateur et un composant de bureau. Les deux peuvent être des composants par défaut OpenOffice.org ou des composants personnalisés. Parfois, il n'est pas nécessaire de remplacer un élément d'interface par une nouvelle implémentation. Il peut être suffisant d'influer sur son état visuel ou de réorienter les interactions des utilisateurs vers un code externe. C'est l'utilisation typique du (dispatch framework).
La communication (répartition ou dispatch) fonctionne dans les deux sens: les informations d'état sont transférées à partir du composant de bureau vers les éléments de l'interface utilisateur et les requêtes des utilisateurs voyagent de l'élément d'interface vers la composante de bureau. Les deux passent par le même centre de commutation, c'est-à-dire, un objet implémentant com.sun.star.frame.XDispatch. L'élément d'interface utilisateur obtient cet objet en appelant queryDispatch()du framework contenant le composant de bureau, et reçoit habituellement un objet qui se connecte à un code interne au cadre, au composant de bureau ou à des services globaux dans OpenOffice.org. Le cadre offre une interface qui est utilisée pour retourner des objets (dispatch) tiers qui fournissent l'élément d'interface avec les mises à jour de statut. Par exemple, il est possible de désactiver un élément d'interface qui ne seraient pas désactivé autrement. Une autre possibilité est d'écrire du code de remplacement qui est appelé par l'élément d'interface utilisateur si l'utilisateur effectue une action appropriée.
Les objets (dispatch) sont fournis par des objets implémentant l'interface com.sun.star.frame.XDispatchProvider, et c'est l'interface que vous êtes tenus de mettre en œuvre. Il s'agit d'une étape supplémentaire, où le fournisseur (provider) dispatch doit être lié au framework afin d'intercepter la communication, donc le fournisseur dispatch devient une partie de la chaîne de charge décrite dans le paragraphe précédent. Ceci est accompli par la mise en œuvre de com.sun.star.frame.XDispatchProviderInterceptor.
Cette chaîne se compose généralement seulement du framework et du dispositif de commande de l'élément de bureau qu'il contient, mais le framework offre l'interface com.sun.star.frame.XDispatchProviderInterception où d'autres fournisseurs sont insérés. On les appelle avant que le frame tente de trouver un objet dispatch pour une URL de commande, de sorte qu'il soit possible de mettre la communication complète de dispatch dans un frame, sous un contrôle externe. Plus d'un intercepteur peut être enregistré, créant ainsi une plus grande chaîne.
Le routage de chaque dispatch à travers toute la chaîne devient un problème de performance, car il pourrait y avoir des dizaines de clients possibles demandant un objet dispatch. Pour cette raison, il y a aussi une API qui limite la procédure de routage de certaines commandes ou de groupes de commande. Cette procédure est décrite ci-dessous.
Une fois la connexion établie, l'intercepteur de dispatch décide comment les demandes d'un objet dispatch sont traitées. Lorsqu'il est demandé un objet dispatch pour une URL de commande, il peut :
Renvoyer une interface vide qui désactive la fonctionnalité correspondante. Il y a un bug dans Ooo1.0/SO6.0 qui fait que cela ne fonctionne pas, alors la désactivation doit être fait explicitement (voir ci-dessous). Il sera fixé dans Ooo 1.02/SO6.02 [2].
Transmettre la demande au membre suivant de la chaîne, appelé fournisseur de dispatch esclave s'il n'est pas intéressé par cette fonctionnalité. (décrit ci-dessous)
Gérer la demande et retourner un objet implémentant com.sun.star.frame.XDispatch. Comme décrit dans le chapitre précédent, les objets clients peuvent s'inscrire à cet objet comme les écouteurs d'événements d'état. L'objet de dispatch retourne des informations d'état possibles tant que le type du membre d'état dans la structure com.sun.star.frame.FeatureStateEvent possède l'un des types attendus, sinon le client demandant les informations d'état ne peut pas le gérer correctement. Les types attendus doivent être documentées avec des commandes existantes. Par exemple, si une entrée de menu veut des informations d'état, il gère un void, ce qui signifie que rien de spécial ne devrait être fait ou l'état boolean d'un affichage de case coché, mais rien d'autre. Les informations d'état pourrait contenir une directive désactiver (disable). Notez qu'un objet dispatch renvoie des informations d'état immédiatement quand un listener enregistre. Tous les événements de changement peuvent être diffusées arbitrairement dans le temps.
L'objet dispatch retourné est également utilisé par des objets clients pour envoyer la commande correspondante à l'URL de commande. L'objet dispatch de réception de cette demande vérifie si le code qu'il veut exécuter est valide dans les conditions actuelles. Il ne suffit pas de s'appuyer sur des demandes de désactivation, car un client n'est pas obligé de s'inscrire comme listener d'état s'il veut envoyer une demande.
Le fournisseur (provider) esclave de dispatch et le fournisseur (provider) maître de dispatch dans l'interface com.sun.star.frame.XDispatchProviderInterceptor sont un peu obscurs [3] au premier abord. Ce sont deux pointeurs vers les membres de la chaîne dans les deux sens, suivant et précédent, où le premier et le dernier membre de la chaîne ont des significations et des responsabilités spéciales.
La commande dispatching passe à travers une chaîne de fournisseurs de dispatch, à partir du frame. Si le cadre doit inclure un intercepteur de cette chaîne, le frame insère les intercepteurs dans la chaîne et passe le membre de la chaîne suivante au nouveau membre de la chaîne, de sorte que les appels sont passés le long de la chaîne si elle ne veut pas de les manipuler.
Si un intercepteur est retiré, le frame met à jour les pointeurs maître et esclave du successeur et prédécesseur de la chaîne de l'élément qui va être retiré de la chaîne. Tous sont des intercepteurs, de sorte que le dernier esclave est un fournisseur de dispatch.
Le cadre prend soin de l'ensemble de la chaîne dans l'enregistrement ou la suppresion des appels dans le fournisseur intercepteur de dispatch, de sorte que l'opérateur d'un intercepteur n'a pas à se préoccuper de la construction de la chaîne.
 |
Exemple d'utilisation : http://forum.openoffice.org/fr/forum/ftopic39062.html |
NDT :
- ↑ Le Guide développeur s'adressant, a-priori, à un public codeur, les termes comme void, boolean, frame, framework, dispatch, dispatcher, listerner, etc, ne seront pas nécessairement traduits : la dénomination originale m'étant plus parlante, c'est fonction fonction de mon humeur. ;)
- ↑ L'article source date un peu...
- ↑ si tu le dis mon ami.... lolllll
