Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Importante
Cet article s’applique uniquement à SharePoint classique (Expérience classique SharePoint Server 2013/2016/2019). Il ne s’applique pas aux expériences sharePoint Online modernes, où la stratégie de téléchargement minimale (MDS), les pages master et la personnalisation du rendu de page côté serveur ne sont pas utilisées.
Le développement SharePoint moderne utilise la SharePoint Framework (SPFx) au lieu des techniques d’optimisation de page basées sur MDS.
Découvrez comment modifier les composants de votre projet SharePoint pour tirer parti de la stratégie de téléchargement minimal (MDS) dans SharePoint. Minimal Télécharger stratégie (DMS) améliore l'expérience utilisateur en renvoyant à partir du serveur uniquement les parties d'une page requis pour restituer correctement dans le navigateur. Étant donné que la page entièrement restituée n’est pas retournée au client, le serveur doit pouvoir identifier avec précision les parties nécessaires au rendu de la page. Vous devrez peut-être modifier les composants de votre projet SharePoint afin qu’ils soient identifiés comme conformes à MDS et puissent fonctionner avec le moteur MDS. Pour en savoir plus sur MDS, consultez Vue d’ensemble de la stratégie de téléchargement minimal.
Pourquoi modifier SharePoint components?
Comme expliqué dans Vue d’ensemble de la stratégie de téléchargement minimal, les contrôles SharePoint fonctionnent, que vous les modifiiez ou non pour tirer pleinement parti de MDS. Toutefois, lorsque vos composants ne sont pas conformes à MDS, le moteur MDS émet un basculement. Dans un basculement, le moteur de MDS prend un aller-retour supplémentaire pour rediriger le navigateur vers la version complète de la nouvelle page, qui prend le temps. Les utilisateurs ont la meilleure expérience lorsque vous modifiez des composants pour travailler avec MDS et éviter un basculement de chaque fois que leur navigation vers une nouvelle page dans SharePoint. Vous devez généralement modifier master pages, ASP.NET pages, contrôles et composants WebPart.
Pages maîtres
La page maître fournit un modèle qui vous permet de MDS identifier les régions de contenu qui peuvent doivent être mis à jour lorsqu'une personne accède à une nouvelle page. L’optimisation de votre page master est l’une des étapes les plus importantes à suivre lors de l’optimisation des performances, car master pages identifient les sections qui nécessitent un contenu mis à jour. Le Seattle. master page incluse dans SharePoint est un bon exemple de page master optimisée. La figure 1 présente des exemples de composants dans la page maître Seattle.master changer de page, tels que la zone de contenu (1) principale, la barre de navigation de gauche (2) et le titre de la page (3).
Figure 1. Composants qui nécessitent des mises à jour dans une page master
Remarque
[!REMARQUE] Il existe plusieurs stocké dans la page maître Seattle.master change de page, tels que des fichiers JavaScript et des feuilles de style. La figure 1 montre uniquement quelques exemples.
Il existe des modèles différents pour optimiser les composants dans une page maître. Vous pouvez utiliser un modèle pour les composants suivants :
- Contrôles et les régions HTML
- Feuilles de style
- fichiers JavaScript
- Titre de la page
Les régions et contrôles HTML sont compatibles MDS s’ils sont encapsulés dans <SharePoint:AjaxDelta> des balises. En encapsulant le contenu dans <SharePoint:AjaxDelta> des balises, vous signalez que le moteur MDS doit mettre à jour les contrôles et le code HTML placés entre parenthèses. Si un contrôle ou une section HTML ne change pas d’une page à l’autre, il ne doit pas être envoyé au client. Par conséquent, vous devez conserver ces contrôles en dehors des <AjaxDelta> balises. A Seattle. master master page illustrée dans la figure 1, la (1) zone de contenu principale est encapsulée dans <AjaxDelta> des balises, comme illustré ici.
<SharePoint:AjaxDelta
id="DeltaPlaceHolderMain"
BlockElement="true"
IsMainContent="true"
runat="server">
<a id="mainContent" name="mainContent" tabindex="-1"></a>
<asp:ContentPlaceHolder id="PlaceHolderMain" runat="server" />
</SharePoint:AjaxDelta>
Un autre exemple de modèle <AjaxDelta> est la barre de navigation gauche (2) dans la figure 1. Le code suivant montre comment le contrôle est encapsulé dans <AjaxDelta> des balises, ainsi que de nombreux autres contrôles et html.
<SharePoint:AjaxDelta
id="DeltaPlaceHolderLeftNavBar"
BlockElement="true"
CssClass="ms-core-navigation"
role="navigation"
runat="server">
<asp:ContentPlaceHolder id="PlaceHolderLeftNavBar" runat="server">
<a id="startNavigation" name="startNavigation" tabIndex="-1"></a>
<asp:ContentPlaceHolder id="PlaceHolderLeftNavBarTop" runat="server" />
<asp:ContentPlaceHolder id="PlaceHolderQuickLaunchTop" runat="server" />
<asp:ContentPlaceHolder id="PlaceHolderLeftNavBarDataSource" runat="server" />
<asp:ContentPlaceHolder id="PlaceHolderCalendarNavigator" runat="server" />
<asp:ContentPlaceHolder id="PlaceHolderLeftActions" runat="server" />
<!-- There are more controls and HTML in this placeholder in the Seattle master page -->
</asp:ContentPlaceHolder>
</SharePoint:AjaxDelta>
Une dernière chose à retenir à propos <AjaxDelta> des balises est que vous ne pouvez pas les imbriquer. Vous devez spécifier <AjaxDelta> des balises au niveau requis le plus élevé dans la structure de page master.
Le dernier exemple de la figure 1 est le titre (3) de la page, qui nécessite un modèle spécial qui utilise la <SharePoint:PageTitle> balise . Le code suivant montre la <PageTitle> balise telle qu’elle est utilisée dans seattle.master master page.
<SharePoint:PageTitle runat="server">
<asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server">
<SharePoint:ProjectProperty Property="Title" runat="server" />
</asp:ContentPlaceHolder>
</SharePoint:PageTitle>
Votre page maître peut également inclure des fichiers JavaScript et des feuilles de style. Le moteur de serveur doit identifier les fichiers CSS et JavaScript selon les besoins. Pour identifier les ressources de fichiers CSS selon les besoins, utilisez le modèle suivant.
<SharePoint:CssLink runat="server" Version="15"/>
<SharePoint:CssRegistration Name="my_styles.css" runat="server" />
Vous ne pouvez avoir qu’une <CssLink> seule balise par master page, mais vous pouvez en avoir plusieurs<CssRegistration>, ce qui vous permet d’ajouter de nombreux fichiers CSS. Utiliser le modèle suivant pour les fichiers JavaScript .
<SharePoint:ScriptLink language="javascript" name="my_javascript.js" runat="server" />
L’inclusion de fichiers CSS et JavaScript à l’aide de balises et <script> HTML <style> n’est pas prise en charge dans MDS.
Pages ASP.NET
Si votre projet comprend des pages ASP.NET , vous devrez probablement référencer des fichiers CSS et JavaScript . Le code HTML <style> et <script> les balises ne sont pas compatibles avec MDS. Utilisez plutôt les <CssRegistration> modèles et <ScriptLink> expliqués dans la section précédente.
Vos pages ASP.NET peuvent également utiliser la Response.Output méthode pour écrire du contenu dans la page, ce qui n’est pas autorisé dans MDS. Au lieu de cela, vous pouvez utiliser les méthodes MDS à la spécification CLS suivantes de la classe SPHttpUtility :
- WriteNoEncode()
- WriteHtmlEncode()
- WriteEcmaScriptStringLiteralEncode()
- WriteHtmlEncodeAllowSimpleTextFormatting()
- WriteHtmlUrlAttributeEncode()
- WriteUrlKeyValueEncode()
- WriteUrlPathEncode()
Outre référencement de fichiers JavaScript , vos pages ASP.NET peuvent avoir insérée JavaScript code. Utiliser le modèle suivant pour rendre votre script bloque MDS compatible.
<SharePoint:ScriptBlock runat="server" >
// Your JavaScript code here.
</SharePoint:ScriptBlock>
Contrôles et composants WebPart
Vous devez également marquer vos contrôles et composants WebPart comme conformes MDS. Le code suivant montre le modèle à utiliser.
[assembly: Microsoft.SharePoint.WebControls.MdsCompliantAttribute(IsCompliant = true)]
namespace VisualWebPartProject2.VisualWebPart1
{
// Rest of your control logic
En outre, vos contrôles et composants WebPart doivent inscrire leurs ressources à l’aide des méthodes de la classe SPPageContentManager . Les ressources les plus courantes sont les extraits de code JavaScript et les fichiers masqués, qui peuvent être inscrits à l’aide <RegisterClientScriptBlock> de et <RegisterHiddenField>, respectivement.
Vos contrôles et composants WebPart peuvent également utiliser des fichiers XSLT pour contrôler le processus de rendu. Vos fichiers de transformation XSLT peuvent avoir incorporés JavaScript code ou fichiers. Le moteur de MDS doit savoir à propos de ces ressources. Vous pouvez inscrire les ressources JavaScript à l’aide d’un objet d’extension XSLT nommé pcm. Un bon exemple d’utilisation de l’objet pcm est le fichier %ProgramFiles %\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\XSL\fldtypes.xsl. Le code suivant montre comment le fichier fldtypes.xsl utilise l’objet pcm pour inscrire des ressources JavaScript.
<xsl:value-of select="pcm:RegisterScriptBlock(concat('block1',$ViewCounter), string($scriptbody1))"/>
<xsl:value-of select="pcm:RegisterScriptLink('/_layouts/15/wssactionmenu.js')"/>