Utiliser la plateforme Office 2007 comme support de développement, une utopie?

Auteur : Didier Danse, consultant .NET (http://didierdanse.net)

Cet article a été originellement publié dans le numéro d’Octobre de ITPro Magazine (www.itpro.fr).

Alors qu’il y a quelques années, les développeurs devaient être de purs spécialistes techniques, il est  maintenant nécessaire à ces mêmes développeurs d’avoir une bonne, voire excellente, compréhension du métier et des pratiques du domaine de l’entreprise dans laquelle ils se trouvent.

Désormais, le développeur est en relation directe avec l’utilisateur et doit faire en sorte que ses applications soient utilisables par celui-ci. Or il s’avère qu’un grand nombre d’utilisateurs est souvent réfractaire au changement ou ne souhaite pas se plonger dans l’apprentissage d’une nouvelle application. Il est donc important de respecter des normes qui, bien qu’elles ne soient pas officielles, permettent aux utilisateurs de retrouver leurs habitudes.

Mais dès lors, pourquoi ne pas faire en sorte de s’approcher de l’interface et des fonctionnalités des logiciels les plus répandus et les plus utilisés ? Ou mieux encore : Pourquoi ne pas ajouter des fonctionnalités à ceux-ci ? C’est ce que Microsoft propose au travers de la suite bureautique Office 2007 puisqu’il permet de récupérer des informations provenant de n’importe quel système afin de les mettre en forme dans un tableau Excel ou un document Word. Mais cela ne s’arrête pas là et les seules limites sont celles de notre imagination.

Office 2007 a ainsi dépassé la notion de suite logicielle pour devenir une véritable plateforme capable d’intégrer des fonctionnalités personnalisées et d’interagir avec les différents produits.

Au travers de ces quelques lignes, nous verrons ce qu’il est possible de réaliser au sein de la plateforme Office et avec quelle facilité, tout cela grâce au système d’addins de Office et à Open XML…

Open XML ? Kesako ?

Avant toute autre chose, il est important de rappeler que les documents réalisés à l’aide de la dernière version d’Office possèdent une nouvelle extension (.xlsx ou .xlsm pour les fichiers Excel, .docx ou .docm pour Word, …).

Ces fichiers respectent un nouveau format basé sur XML et sur le format ZIP. Une norme ISO reprend l’ensemble des spécifications de ce format. Cependant, Open XML est cependant légèrement différent de celle-ci, la norme ayant été discutée après l’implémentation d’Open XML. Ainsi, tout fichier (ou presque… mais là n’est pas le sujet) généré par Office 2007 (ou Office 2008 sur Mac) est en fait un ensemble de fichiers XML rassemblés au sein d’un seul fichier qui, lui, est zippé. Pour vous en convaincre, renommez l’extension d’un fichier Office 2007 en .zip et regardez le contenu de celui-ci.

XML et ZIP n’étant pas des formats propriétaires (enfin… Certaines implémentations semblent faire abstraction des normes mais à nouveau, ce n’est pas le sujet), il est dès lors possible de générer des fichiers utilisables par la suite Office quelque soit la technologie, le produit ou la solution. Dans la même lignée, un produit tiers peut aisément manipuler ces fichiers pour effectuer un traitement sur les données, extraire des données afin de les afficher ou toute autre opération.

Mais fermons cette parenthèse et revenons à notre sujet…

Comment étendre les fonctionnalités de la suite Office ?

Si vous avez suivi les débats et annonces autour d’Office 2007, vous êtes certainement déjà au courant qu’Office 2007 propose une interface quelque peu modifiée par rapport à ce que l’on connaissait précédemment. Les retours à ce sujet sont contradictoires, les uns pensant qu’il s’agit d’un grand pas en terme d’ergonomie, les autres indiquant qu’ils ne retrouvaient guère leurs fonctionnalités, ce qui prouve que le changement n’est pas toujours simple à accepter.

Ajouter des boutons dans le ruban

Le ruban, voilà un terme qui vous est peut-être inconnu. De quoi s’agit-il ? Le ruban a pour but d’organiser de manière plus efficace les commandes disséminées précédemment dans les différents menus. Ces commandes sont regroupées au sein d’onglets dans un panneau de taille plus importante, ce qui permet de réaliser des menus plus simples à utiliser. On y retrouve plusieurs types de contrôles : la case à cocher, la liste déroulante ou encore le bouton.

Il est possible d’étendre l’utilisation de ce ruban à des fins propres et d’y ajouter de nouveaux onglets et de nouveaux composants auxquels peut être associé notre propre code.

Certains produits de la suite Office ont des fenêtres qui leur sont propres. Par exemple, dans Outlook, il existe plusieurs fenêtres de types différents : tâches, contacts, messages électroniques, … Chacune de ces fenêtres répond à des fonctionnalités différentes. C’est pourquoi les rubans sont adaptés à la fonctionnalité à laquelle ils sont liés.

C’est également le cas pour Access qui permet de personnaliser le ruban pour un formulaire ou un rapport, ce qui permet d’ajouter de nouvelles fonctionnalités tout en utilisant un espace disponible et habituel.

La personnalisation du ruban repose sur un fichier XML qui a pour avantage de ne nécessiter pour la réalisation que d’un simple éditeur de texte. Bien que le contenu de ce fichier soit relativement simple, des outils supportant les schémas XML (ces schémas contiennent la liste des informations pouvant être utilisés) ou l’utilisation d’un designer s’avère toujours être d’une grande aide afin d’éviter toute erreur et augmenter la productivité. C’est ce que nous propose Visual Studio 2008.

La définition des personnalisations du ruban peut se trouver à deux niveaux différents :

• Au niveau d’un document, en ajoutant des informations sous la forme XML au sein de ce document (rappelez-vous qu’il s’agit d’un simple fichier zippé contenant plusieurs fichiers XML) ;
• Au niveau applicatif en ajoutant un addin qui contient les informations XML.

La personnalisation du ruban au niveau du document est plus simple qu’il n’y paraît. Effectivement, nous pouvons utiliser l’outil Custom Fluent UI Editor capable de générer le fichier XML à ajouter et de l’insérer dans notre document. Il est par ailleurs possible d’utiliser cet outil pour insérer des icones personnalisés pour les boutons que nous ajoutons au ruban. Une fois l’opération effectuée, ce fichier peut-être partagé en bénéficiant de fonctions entre les utilisateurs sans pour autant installer notre addin au niveau applicatif.

On notera le cas un peu particulier d’Access 2007 puisque les fichiers qu’il génère ne sont pas basés sur des fichiers XML mais sont des fichiers binaires, c'est-à-dire incompréhensible par le commun des mortels. Mais les choses ne sont pas si mal faites que cela puisqu’il est possible de stocker les informations XML pour la personnalisation du ruban au sein d’une table Access, d’une table Access distante, d’un logiciel tiers comme SAP ou même d’une feuille de classeur Excel.

Les rubans peuvent être réalisés « from scratch », ce qui sous-entend qu’il est possible de remplacer tous les boutons du ruban par ce que bon nous semble ou n’en afficher que certains, évitant ainsi aux utilisateurs d’avoir accès à des fonctionnalités non souhaitées. Cela peut aller encore plus loin puisque l’affichage d’onglets ou boutons peut se faire sur base de critères divers tels que le groupe de sécurité dans lequel l’utilisateur se trouve, l’heure à laquelle le document est ouvert et bien d’autres choses encore.

Nous l’avons vu, il est possible d’ajouter plusieurs types de contrôles dans notre ruban dont des listes déroulantes. Il peut être souhaitable de remplir ces listes à l’aide de données stockées dans un système quelconque, le tout de manière dynamique et cela est effectivement possible sans trop d’efforts. Les données peuvent provenir d’une liste SharePoint, une table Access ou toute autre source de données renvoyant un tableau d’informations. Les informations peuvent également provenir du document de travail lui-même ce qui permet par exemple de lister tous les paragraphes d’un fichier Word ayant comme style Titre 2 de manière dynamique.

Notre ruban, moyennant un peu de code de notre part, peut donc s’adapter au document ou à la situation dans laquelle nous nous trouvons.

Les panneaux personnalisés

Il s’agit du deuxième ensemble de composants entièrement personnalisables. Ces panneaux, qui peuvent être placés aux quatre coins du document ou dans une fenêtre flottante, sont présents dans Office depuis plusieurs années. Il n’y a guère de grandes nouveautés du point de vue de l’utilisateur. Par contre, du côté du développeur, il en va autrement.

Au sein de ces panneaux, nous pouvons placer tous les contrôles que l’on souhaite, y compris des contrôles issus de WPF (Windows Presentation Foundation) : Grilles de données, listes déroulantes etc. Comme pour le ruban, les données qui serviront à remplir ces contrôles peuvent provenir de n’importe quelle source et la technique pour remplir ces contrôles est classique.

Notons que, selon l’endroit où le panneau se situe, il peut être utile de modifier la disposition du formulaire présent dans ce panneau. C’est généralement le cas lorsque l’on passe d’un panneau horizontal à un panneau vertical ou inversement.

A la lecture de cette dernière phrase, nous pourrions penser que nous sommes à nouveau face à certaines complications mais il n’en est rien et ceci est simple à mettre en place et permet à l’utilisateur final de choisir la position du volet comme il le souhaite. Le client, en l’occurrence l’utilisateur, est roi !

Quelles connaissances faut-il pour développer des addins Office ?

La plateforme .NET

La plateforme .NET est adoptée comme technologie au sein de la plupart des logiciels édités par Microsoft, ce qui permet une uniformisation des techniques de développement et ainsi de permettre aux développeurs de dépasser les limites qu’ils pouvaient rencontrer auparavant, lorsqu’il était nécessaire d’apprendre les rudiments d’une nouvelle technologie, propriétaire ou non.

Office ne déroge pas à cette règle et le développeur .NET se retrouve ainsi dans un environnement connu.

L’environnement de développement Visual Studio

Le développement de fonctionnalités précédemment citées, qu’il s’agisse des volets, du ruban ou encore des menus, est aisé. Effectivement, Visual Studio crée pour nous les fichiers qui sont nécessaires et un squelette de code permettant de se concentrer sur ce qui importe l’utilisateur final : le fonctionnel et l’ergonomie générale.

Les designers intégrés à Visual Studio permettent de visualiser ce que l’utilisateur verra au final, ce qui facilite le développement.

On notera également que, comme pour tous les développements .NET, le débogage en utilisant les techniques habituelles (fenêtre Espions…) est possible et est même conseillé.

Et le déploiement là dedans ?

Nous l’avons vu dans les paragraphes précédents, il est possible d’intégrer les nouvelles fonctionnalités au sein d’un document, ce qui sous-entend que ces fonctionnalités ne sont disponibles que pour ce document, ce qui peut s’avérer peu pratique. Il existe bien entendu d’autres techniques permettant le déploiement des addins au niveau applicatif. Chacune d’entre elles a ses avantages et ses inconvénients.

Déploiement via un installeur

Classique mais efficace, il s’agit de l’installeur « Next – Next – Next » connu de tous. Il est distribuable sur tout support.

Déploiement via ClickOnce

La deuxième technique consiste à utiliser ClickOnce commence à se répandre, ce qui est d’ailleurs une bonne chose. Effectivement, au-delà de la simple installation, ClickOnce a pour but de comparer la version disponible avec la version installée sur le PC, réaliser les mises à jour nécessaires avant de lancer le logiciel le tout en un clic. Ceci est applicable aux addins pour Microsoft Office 2007.

En conclusion

A la vue de ces quelques pages, il est aisé de se rendre compte que le développement Office ne s’avère pas plus compliqué que le développement d’applications d’autre type, et inversement. Et si vous n’êtes pas encore convaincu, faites le test par vous-même…

Didier Danse est Microsoft Most Valuable Professional ASP.NET et travaille pour la société Acane Consulting, basée au Luxembourg, en Belgique et en France, en tant que consultant sur les technologies .NET et SharePoint.

Retrouvez d’autres informations sur .NET, Visual Studio, Team Foundation Server, SharePoint et les technologies et solutions Microsoft sur son site personnel : http://didierdanse.net. Une série de webcasts sur le développement Office y sera publiée dans le courant du mois de novembre, alors restez connectés !