Type de page de contenu

Windows SharePoint Services 3

Les pages de contenu peuvent être modifiées par les utilisateurs finaux à l’aide d’outils tels qu'Microsoft Office SharePoint Designer 2007, ou téléchargées à l’aide de protocoles, tels que WebDAV. Lorsque vous créez un site SharePoint, de nombreuses pages de contenu sont créées automatiquement, par exemple, default.aspx, allitems.aspx pour votre galerie de composants WebPart, editform.aspx en tant que formulaire de modification de votre liste d’annonces, entre autres.

Les pages de contenu sont stockées de manière logique dans leurs sites SharePoint et la plupart des fichiers sont également stockés physiquement dans leur base de données de contenu SharePoint associée. Toutefois, toutes les pages de contenu sont en réalité stockées dans la base de données de contenu.

Pages de contenu personnalisées

Windows SharePoint Services 3.0 prend en charge la personnalisation des pages (également appelée « dédoublement »). Toutefois, Windows SharePoint Services stocke les pages personnalisées différemment des pages de modèle non modifiées.

Les fichiers des modèles de pages non modifiées sont stockés sur le disque du serveur Web frontal, pas dans la base de données de contenu. Les pages personnalisées (les pages de modèle qu’un utilisateur a modifiées), sont stockées dans la base de données de contenu.

Dans les cas où Windows SharePoint Services met en service une page à partir d’un modèle SharePoint, au lieu de récupérer une page de la base de données de contenu, le système crée un pointeur vers l’instance du fichier de modèle de page sur le serveur Web frontal. Par conséquent, Windows SharePoint Services évite à plusieurs reprises la création de copies de ses pages de contenu, qui sont mises en service chaque fois qu’un site est créé.

Ce pointeur vers une instance de la page de modèle sur le serveur Web frontal est créé uniquement si l’utilisateur n’a pas personnalisé la page. Une fois qu’une page est personnalisée (à l’aide d'Office SharePoint Designer 2007, par exemple), le pointeur est annulé et la page proprement dite est stockée dans la base de données de contenu.

Aa979501.Caution(fr-fr,office.12).gif Attention :

Ne supposez pas que parce que le contenu d’une page ou d’un fichier n’est pas personnalisé (à l’aide d’outils tels qu'Office SharePoint Designer 2007), vous pouvez librement modifier la copie serveur pour apporter des modifications à toutes les instances existantes. Il existe plusieurs modifications (comme le fait de modifier des valeurs de propriétés pour un fichier dans une liste) qui amènent Windows SharePoint Services à considérer la page ou le fichier comme étant « personnalisé ». En outre, la modification des copies serveur des fichiers mis en service peut entraîner des effets secondaires indésirables, tels que le calcul erroné de quotas sur la taille des fichiers.

Personnalisez not les copies serveur des fichiers après la mise en service. Envisagez plutôt l’utilisation de pages maîtres pour appliquer les modifications à l’échelle du site. Pour plus d’informations sur l’utilisation des pages maîtres, voir Master Pages.

Utilisation de code côté serveur dans les pages de contenu

Les règles qui régissent l’utilisation de code côté serveur dans les pages de contenu n’ont pas changé depuis Windows SharePoint Services 2.0. Autrement dit, la logique serveur incorporée déclarée dans les pages de contenu SharePoint n’est généralement pas prise en charge. Cela s’applique uniquement à la logique incorporée dans la page et n’inclut pas le code sous-jacent aux contrôles Microsoft ASP.NET dans la page. Le jeu de contrôles qui sont autorisés à s’exécuter est régi séparément par la liste des contrôles fiables.

Voici une série de règles générales qui régissent l’utilisation de code côté serveur dans une page de contenu :

  • Si le contenu d’une page n’est pas personnalisé, le code côté serveur est pris en charge dans la page.

  • Si le contenu d’une page est personnalisé, le code côté serveur ne s’exécute pas dans la page, et la page ne restitue rien.

  • Il est recommandé de ne pas utiliser de code côté serveur dans les pages de contenu lors du développement des définitions de site, car si un utilisateur modifie cette page ultérieurement, le code ne s’exécutera plus.

Un administrateur peut remplacer les paramètres qui prennent en charge les règles générales. Autrement dit, l’administrateur peut ajouter un paramètre PageParserPath dans le fichier web.config qui permet l’exécution du code côté serveur dans les pages stockées dans un chemin d’accès spécifié.

Voici un exemple d’un paramètre de ce type.

<SharePoint>
   <SafeMode ...>
   <PageParserPaths>
      <PageParserPath VirtualPath="/_mpg/*" CompilationMode="Always"
         AllowServerSideScript="true" IncludeSubFolders="true"/>
   </PageParserPaths>

Pour spécifier tous les fichiers d’un dossier à la fin d’un chemin d’accès virtuel, utilisez le caractère générique (*), comme illustré dans l’exemple ci-dessus ; sinon, utilisez le nom du fichier lui-même pour activer uniquement un fichier unique spécifique. Vous ne pouvez pas utiliser de caractères génériques dans les noms de fichiers situés dans le chemin d’accès virtuel (par exemple, ../_mpg/my*.aspx).

Aa979501.Caution(fr-fr,office.12).gif Attention :

   Security Alert : l’ajout de paramètres PageParserPath permet à toute personne à même de télécharger des pages vers ces dossiers d’écrire du code approuvé arbitraire sur le serveur. Normalement, les administrateurs ne doivent pas fournir ces paramètres PageParserPath  ; toutefois, si les circonstances l’imposent, soyez très prudent.

Voir aussi

Afficher: