Après plusieurs discussions entre collègues et lectures sur le net sur les cas pratiques d'utilisation des HttpModules, je me lance dans l'écriture d'une petite série de 3 billets sur le sujet.
La première partie tiendra plus d'un récapitulatif de différents articles déjà publiés (désolé pour le côté agrégation de blogs) mais vous permettra ainsi de retrouver les bonnes références pour vous mettre dans le bain.
La 2eme partie sera déjà plus inédite avec une utilisation pratique des HttpModules pour la gestion des pages d'administration (et les retouches qu'on ne doit pas faire directement sur elles, même si on en rêve !).
Enfin, la dernière partie sera un petit utilitaire complet reprenant les bases de la 2eme partie en les développant et qui vous permettra, je l'espère, d'exploiter cette fonctionnalité au mieux dans vos applications.
Nous commençons donc :
- Tout d'abord, rendons à César ce qui est à César (enfin, Renaud !) puisque Renaud Comte avait déjà évoqué l'utilisation des HttpModules il y a bien longtemps sur son blog. Le contexte était différent, mais les pointeurs sont les bons : vous y trouverez le nécessaire pour comprendre et vous lancer dans les HttpModules
- Il vous faudra aussi vous renseigner sur ce qu'il est possible de faire avec l'objet HttpApplication et tout particulièrement ses événements.
De manière générale, il faut savoir qu'un HttpModule se place entre l'appel à une page et son traitement.
Vous pouvez alors vous abonner à différents événements qui interviennent tout au long du cycle : en avance de phase lors de la requête entrante, ou bien tout à la fin lors du rendu de la réponse.
SharePoint, comme pas mal d'applications ASP.Net, utilise de base plusieurs modules (ici tirés d'un Web.config d'application MOSS) :
<httpModules>
<clear />
<add name="SPRequest" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add name="OutputCache" type="System.Web.Caching.OutputCacheModule" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" />
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule" />
<add name="RoleManager" type="System.Web.Security.RoleManagerModule" />
<!-- <add name="Session" type="System.Web.SessionState.SessionStateModule"/> -->
<add name="PublishingHttpModule" type="Microsoft.SharePoint.Publishing.PublishingHttpModule, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add name="Session" type="System.Web.SessionState.SessionStateModule" />
</httpModules>
Pour cette première partie, je vais donc vous parler d'un cas pratique souvent évoqué lorsqu'on parle de l'apparence des pages (ce qui glisse de suite sur le terrain des master pages).
Vous le savez sans doute, les master pages permettent d'avoir un look global pour tout votre site :
- menus,
- logo,
- références à des feuilles de styles, des fichiers javascripts,
- entête et pied de page,
- ...
Bref, c'est ce qui fait l'identité de votre site. Ce n'est pas une partie qui possède le contenu à proprement parler, mais uniquement la structure d'une page.
Cette master page (ou page maître en français, mais je ne m'y ferai sans doute jamais) permet aussi de définir des emplacements (placeholders) qui hébergeront les parties plus "dynamiques" qui pourront changer selon le type de page. Ce sera alors au rôle des "Page layouts", ou mise en page (j'aime bien parler de gabarit) de définir le look plus particulier de telle ou telle page. Mieux qu'un long discours, une image et un bon pointeur :
Master Pages and Pages Layouts (MSDN / SDK SharePoint)
Tout ça pour vous amener sur une problématique propre à SharePoint : les pages d'administration. En effet, ces pages utilisent bien des master pages, mais pas celles du site ! Or, bien que ces pages soient limitées aux administrateurs, ceux-ci peuvent espérer des pages un peu plus sexy.
L'alternative à cette contrainte provient justement des HttpModules. L'idée est au final assez simple, la mise en oeuvre elle étant astucieuse ;) Il "suffit" de modifier à la volée la master page de la page incriminée en récupérant celle définie au niveau du site, ceci en se rajoutant un petit événement sur le PreInit de la page. Pour tout le détail de l'opération, faîtes donc un tour sur ce billet de David Wise : One .Master to Rule Them All (Two actually) (on sent une bonne dose de Tolkien - et de bière ! - derrière tout ça). L'opération n'est pas aussi évidente qu'elle peut paraître, en effet il faudra aussi que la master page utilisée comporte bien tous les placeholders requis par toutes les pages d'administration (et il y en a). Profitez en pour potasser le sujet grâce à l'article de Fabrice Romelard : Modifier la Master Page de SharePoint.
J'espère que vous commencez ainsi à entrevoir les possibilités de ces modules HTTP et à réfléchir à des applications pratico-pratiques !
Gat, fan du SharePoint modulaire