Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Importante
Este artigo aplica-se apenas ao SharePoint Clássico (Servidor do SharePoint 2013/2016/2019 Experiência Clássica). Não é aplicável às experiências modernas do SharePoint Online, em que a MDS (Estratégia de Download Mínimo), as páginas de master e a personalização de renderização de página do lado do servidor não são usadas.
O desenvolvimento moderno do SharePoint usa a SPFx (Estrutura do SharePoint) em vez de técnicas de otimização de página baseadas em MDS.
Saiba como modificar os componentes em seu projeto do SharePoint para aproveitar a Estratégia de Download Mínimo (MDS) no SharePoint. Estratégia de baixar mínimo (MDS) melhora a experiência do usuário por meio do retorno do servidor apenas as partes de uma página necessária para renderizá-lo corretamente no navegador. Como a página totalmente renderizada não é retornada ao cliente, o servidor deve identificar com precisão as partes necessárias para renderizar a página. Talvez seja necessário modificar os componentes em seu projeto do SharePoint para que eles sejam identificados como compatíveis com MDS e possam trabalhar com o mecanismo MDS. Saiba mais sobre o MDS em Visão geral da estratégia de download mínimo.
Por que modificar SharePoint components?
Conforme explicado na visão geral da Estratégia de Download Mínimo, os controles do SharePoint funcionam independentemente de você modificá-los ou não para aproveitar ao máximo o MDS. No entanto, quando seus componentes não estão em conformidade com o MDS, o mecanismo do MDS emite um failover. Em um failover, o mecanismo do MDS leva um processamento extra para redirecionar o navegador para a versão completa da nova página, o que leva tempo. Os usuários têm a melhor experiência ao modificar componentes para funcionar com o MDS e evitar um failover sempre que navegam para uma nova página em SharePoint. Geralmente, você precisa modificar master páginas, ASP.NET páginas, controles e Web Parts.
Página mestras
A página mestra fornece um modelo que permite que o MDS identifique as áreas de conteúdo que talvez precisem ser atualizadas quando alguém navega para uma nova página. Otimizar sua página de master é uma das etapas mais importantes a serem executadas ao otimizar o desempenho, pois master páginas identificam seções que exigem conteúdo atualizado. O Seattle. master página incluída no SharePoint é um bom exemplo de uma página de master otimizada. A Figura 1 mostra exemplos de componentes na página mestra Seattle.master alterar de uma página para outra, como a área de conteúdo principal (1), a barra de navegação (2) à esquerda e o título da página (3).
Figura 1. Componentes que exigem atualizações em uma página master
Observação
[!OBSERVAçãO] Há muitos mais componentes na página mestra Seattle.master que mudar de uma página para outra, como folhas de estilo e JavaScript arquivos. A Figura 1 mostra alguns exemplos.
Existem diferentes padrões para otimizar os componentes em uma página mestra. Você pode usar um padrão para os seguintes componentes:
- Regiões HTML e controles
- Folhas de estilo
- arquivos de JavaScript
- Título da página
As regiões e controles HTML são compatíveis com MDS se estiverem envolvidos em <SharePoint:AjaxDelta> marcas. Ao encapsular o conteúdo em <SharePoint:AjaxDelta> marcas, você está sinalizando que o mecanismo MDS deve atualizar os controles inclusos e o HTML. Se um controle ou seção HTML não for alterado de uma página para outra, ela não deverá ser enviada ao cliente. Portanto, você deve manter esses controles fora das <AjaxDelta> marcas. No Seattle. master master página mostrada na Figura 1, a (1) área de conteúdo principal é encapsulada em <AjaxDelta> tags, conforme mostrado aqui.
<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>
Outro exemplo do <AjaxDelta> padrão é a barra de navegação esquerda (2) na Figura 1. O código a seguir mostra como o controle é encapsulado em <AjaxDelta> marcas, juntamente com muitos outros controles e 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>
Uma última coisa a lembrar sobre <AjaxDelta> as marcas é que você não pode aninhá-las. Você deve especificar <AjaxDelta> as tags no nível mais alto necessário na estrutura da página master.
O último exemplo na Figura 1 é o título da página (3), que requer um padrão especial que usa a <SharePoint:PageTitle> tag. O código a seguir mostra a <PageTitle> marca usada no Seattle.master página master.
<SharePoint:PageTitle runat="server">
<asp:ContentPlaceHolder id="PlaceHolderPageTitle" runat="server">
<SharePoint:ProjectProperty Property="Title" runat="server" />
</asp:ContentPlaceHolder>
</SharePoint:PageTitle>
A página mestra também pode incluir arquivos de JavaScript e folhas de estilo. O mecanismo do servidor precisa identificar arquivos CSS e JavaScript conforme necessário. Para identificar os recursos de arquivos CSS conforme necessário, use o seguinte padrão.
<SharePoint:CssLink runat="server" Version="15"/>
<SharePoint:CssRegistration Name="my_styles.css" runat="server" />
Você pode ter apenas uma <CssLink> tag por master página, mas pode ter muitas <CssRegistration> tags, portanto, pode adicionar muitos arquivos CSS. Use o seguinte padrão para arquivos de JavaScript .
<SharePoint:ScriptLink language="javascript" name="my_javascript.js" runat="server" />
Não há suporte para a inclusão de arquivos CSS e JavaScript usando HTML <style> e <script> marcas no MDS.
Páginas do ASP.NET
Se seu projeto inclui páginas de ASP.NET , você provavelmente precisa fazer referência a arquivos CSS e JavaScript . O HTML <style> e <script> as marcas não são compatíveis com o MDS. Em vez disso, use os <CssRegistration> padrões e <ScriptLink> explicados na seção anterior.
Suas páginas ASP.NET também podem usar o método para gravar conteúdo na página, o Response.Output que não é permitido no MDS. Em vez disso, você pode usar os seguintes métodos da classe SPHttpUtility compatível com MDS:
- WriteNoEncode()
- WriteHtmlEncode()
- WriteEcmaScriptStringLiteralEncode()
- WriteHtmlEncodeAllowSimpleTextFormatting()
- WriteHtmlUrlAttributeEncode()
- WriteUrlKeyValueEncode()
- WriteUrlPathEncode()
Além de fazer referência a arquivos de JavaScript , suas ASP.NET páginas podem ter JavaScript o código embutido. Use o padrão a seguir para tornar o script bloqueia MDS compatível.
<SharePoint:ScriptBlock runat="server" >
// Your JavaScript code here.
</SharePoint:ScriptBlock>
Controles e Web Parts
Você também precisa marcar seus controles e web parts como compatíveis com MDS. O código a seguir mostra o padrão a ser usado.
[assembly: Microsoft.SharePoint.WebControls.MdsCompliantAttribute(IsCompliant = true)]
namespace VisualWebPartProject2.VisualWebPart1
{
// Rest of your control logic
Além disso, seus controles e web parts precisam registrar seus recursos usando os métodos da classe SPPageContentManager . Os recursos mais comuns são trechos de JavaScript e arquivos ocultos, que podem ser registrados usando o <RegisterClientScriptBlock> e <RegisterHiddenField>, respectivamente.
Seus controles e web parts também podem usar arquivos XSLT para controlar o processo de renderização. Os arquivos XSLT podem ter incorporado código JavaScript ou arquivos. O mecanismo do MDS precisa saber sobre esses recursos. Você pode registrar os recursos JavaScript usando um objeto de extensão XSLT chamado pcm. Um ótimo exemplo de como usar o pcm objeto está no arquivo %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\15\TEMPLATE\LAYOUTS\XSL\fldtypes.xsl. O código a seguir mostra como o arquivo fldtypes.xsl usa o pcm objeto para registrar recursos JavaScript.
<xsl:value-of select="pcm:RegisterScriptBlock(concat('block1',$ViewCounter), string($scriptbody1))"/>
<xsl:value-of select="pcm:RegisterScriptLink('/_layouts/15/wssactionmenu.js')"/>