Développement d'applications sur MOSS 2007 et WSS V3

Paru le 2006 03 05

Tiré du blog de Chris Johnson, Microsoft Consulting Services NZ.

J'ai eu la chance d'être profondément impliqué dans l'un des premiers projets de nos clients TAP (Technical Adopter Program) pour Office. Les clients TAP reçoivent les premières versions et les versions bêta, en plus du support technique de Microsoft, pour élaborer un projet sur la base de ces produits. L'objectif de cette initiative est double : il consiste à leur permettre d'effectuer un déploiement précoce des technologies les plus récentes et de favoriser ainsi la mise sur le marché d'un produit de qualité par Microsoft. Nos clients TAP nous sont indispensables dans le sens où ils nous font part de leurs commentaires tout au long de la construction du produit.

Dans le projet spécifique dans lequel je suis actuellement impliqué, nous développons une solution très élaborée, créée à l'aide d'un grand nombre de nouvelles fonctionnalités de Microsoft Office System 2007. Parmi ces fonctionnalités, citons notamment InfoPath incorporé dans un contrôle WinForms et Microsoft Office SharePoint Server 2007 (MOSS 2007).

Voici la liste non exhaustive de ce que nous réalisons :

• création d'une application WinForms .NET et incorporation d'InfoPath pour réaliser des captures de formulaires enrichis hors connexion dans une application personnalisée ;

• Workflows Visual Studio personnalisés reposant sur Windows Workflow Foundation ;

• Définitions de sites personnalisées, Définitions de listes, ///Tâches d'horloge déployées en tant que fonctionnalités via l'infrastructure de déploiement de solutions.

• ...

L'objet principal de cet article consiste surtout à présenter les différentes options que nous avons envisagées pour créer une interface utilisateur personnalisée exécutée dans MOSS, ainsi que les avantages et inconvénients de chacune d'entre elles.

Voici les différentes options que nous avons envisagées :

• Composants WebPart personnalisés

• Application « _layouts » (voir plus loin la définition)

• Application créée à l'aide de contrôles utilisateurs (User Controls) et de Son of SmartPart

Le composant particulier de l'application qui m'intéresse est le « moteur » de présentation de l'interface utilisateur qui contient tous les mécanismes pour la mise en œuvre de cette dernière.

Sur cette page

Option 1 : Composants WebPart personnalisés
Option 2 : Application _layouts
Option 3 : Contrôles utilisateurs et Son of SmartPart

Option 1 : Composants WebPart personnalisés

Cette option permet de créer la totalité de l'interface utilisateur à l'aide de l'infrastructure de composants WebPart. La logique, etc…. peut être dans d'autres assemblys .NET; un service Web, ou ailleurs, exactement comme pour une autre application .NET.

Avantages :

• création à l'aide de l'infrastructure de composants WebPart ASP.NET ;

• déploiement via un package d'installation de composants WebPart ou par le biais du nouveau mécanisme de déploiement de fonctionnalités ou de solutions ;

• l'application SharePoint offre une infrastructure d'hébergement pour « placer » ces composants WebPart sur des pages WebPart ;

• infrastructure de communication pour l'échange entre les composants WebPart ;

• conception totalement réutilisable à travers plusieurs sites, à moindre effort.

Inconvénients :

• pas de glisser-déplacer pour disposer votre l'interface utilisateur, c'est-à-dire qu'il n'y a pas de surface au moment de la conception ;

• C'est une infrastructure dans laquelle les développeurs doivent apprendre à travailler.

Conclusion : une utilisation appropriée des composants WebPart consisterait donc à créer une mini application/gadget à appliquer à de nombreuses pages WebPart à travers un grand nombre de sites.

Option 2 : Application _layouts

Lorsque vous développez une application Web ASP.NET et que vous la déployez sur le répertoire c:\program files\common files\microsoft shared\web server extensions\12\template\layouts (ouf !), elle est qualifiée d'application _layouts. Ce répertoire spécial est « virtualisé » dans chaque site SharePoint, c'est-à-dire que chaque site SharePoint possède un chemin /_layouts provenant de la racine du Web. Ainsi, par exemple, http://nomserveur/sites/nomsite/_layouts.

Cela signifie que vous pouvez rendre votre application disponible sous chaque site SharePoint, par ex., http://nomserveur/sites/nomsite/_layouts/MyApp/SomePage.aspx.

En réalité c'est ainsi que toutes les pages d'administration de SharePoint sont exécutées sur chaque site.

Avantages :

• excellente méthode pour rendre votre fonctionnalité disponible dans chaque site ;

• facilité de développement ; identique au développement d'un site WebASP .NET normal ;

• accès contextuel au modèle d'objet SharePoint ; parfait pour travailler sur le site auquel il se trouve que l'utilisateur est justement connecté au même moment.

Inconvénients :

• déploiement non géré via le mécanisme de déploiement de solutions ;

• impossibilité d'utiliser la page maître ASP.NET du contexte du site étant donné que l'application _layouts est une application ASP.NET séparée.

Conclusion : il est préférable d'utiliser une application _layouts lorsque vous souhaitez étendre tous les sites avec des fonctionnalités telles que des pages d'administration supplémentaires.

Option 3 : Contrôles utilisateurs et Son of SmartPart

La dernière option consiste à créer l'interface utilisateur de vos applications dans des contrôles utilisateurs ASP.NET comme dans n'importe quelle autre application Web ASP.NET, puis d'utiliser Son of SmartPart pour mettre en œuvre ces contrôles utilisateurs via un composant WebPart.

Son of SmartPart est un composant WebPart capable d'« héberger » un contrôle utilisateur ASP.NET 2.0 :). Pour plus d'informations, consultez : http://www.smartpart.info/default.aspx
(si vous voulez savoir qui est le père du Son of SmartPart (fils de SmartPart) ... c'est curieusement SmartPart ... qui est un composant WebPart destiné à l'hébergement des contrôles utilisateurs ASP.NET 1.1).

Avantages :

• facilité de développement ;

• vous disposez d'une surface de conception pour créer votre interface utilisateur ;

• déploiement relativement simple ;

• possibilité d'utiliser l'infrastructure de connexion des composants WebPart, si nécessaire ;

• il peut être possible de les développer d'abord en dehors de SharePoint (dans la mesure où ils possèdent des dépendances à SharePoint).

Inconvénients :

• déploiement non géré via un mécanisme de déploiement de solutions prêt à l'emploi (vous pourriez créer une solution pour déployer Son of Smart Part) ;

• déploiement légèrement différent des fichiers et assemblys User Controls (mais rien qu'un fichier .bat ne puisse résoudre) au cours du développement.

Conclusion : je pense que cette option est parfaite pour créer une interface utilisateur faisant appel à un navigateur enrichi, à utiliser dans un ou deux sites. En revanche, elle ne me semble pas idéale pour créer une mini application à inclure à de nombreux sites. Dans ce cas, il est préférable d'utiliser un composant WebPart.

Tableau d’aide à la décision

Dans le cas de figure de notre projet :

Pour le projet que j'ai mentionné au début de cet article, voici les points sur lesquels nous étions d'accord :

• nous souhaitions concevoir une interface utilisateur d'application dans un seul endroit dans SharePoint ;

• il n'y aurait toujours qu'une seule instance de l'application, c'est-à-dire que celle-ci ne se manifesterait que sur un seul site SharePoint ;

• l'interface utilisateur comporterait un grand nombre d'écrans différents.

D'après vous, quelle option avons-nous choisi ?

Et bien, nous avons véritablement hésité entre deux options pour créer l'interface utilisateur, à savoir les composants WebPart ou la méthode Smart Part.

Finalement, c'est la méthode User Controls et Smart Part qui fut utilisée pour sa construction car nous avons estimé que les développeurs seraient plus productifs dans la création des contrôles utilisateurs (n'ayant pas d'expérience préalable du développement de SharePoint), et dans la mesure où il n'était pas nécessaire de réutiliser les applications dans plusieurs sites.

C'est ainsi que nous nous sommes retrouvés avec une bibliothèque de documents pour héberger des pages WebPart pour chaque « écran » de l'interface utilisateur. Dans chacune des pages WebPart, nous avons fait appel à Son of SmartPart pour exécuter le contrôle utilisateur qui met en œuvre cette partie de l'application.

Je serais très intéressé de savoir si vous utilisez d'autres options pour développer vos applications exécutées dans SharePoint. N'hésitez pas à m'envoyer vos commentaires…

-Chris.

Mise à jour : modification du titre pour inclure WSS v3 suite à la remarque judicieuse de Patrick selon lequel ces propos s'appliquent également à WSS v3.