Traitement des espaces blancs en XAML

Mise à jour : novembre 2007

Le XAML (Extensible Application Markup Language) applique des règles de langage qui définissent la manière dont l'espace blanc significatif doit être traité par une implémentation du processeur XAML. Cette rubrique documente ces règles de langage, ainsi que la gestion des espaces blancs définie par l'implémentation Windows Presentation Foundation (WPF) du processeur XAML, et le writer XAML pour la sérialisation.

Traitement des espaces blancs

Définition d'espaces blancs

Conformément au XML, les caractères d'espace blanc en XAML sont l'espace, le saut de ligne et la tabulation. Ils correspondent respectivement aux valeurs Unicode 0020, 000A et 0009.

Normalisation des espaces blancs

Par défaut, la normalisation d'espace blanc suivante se produit lorsqu'un processeur XAML traite un fichier XAML :

  1. Les caractères de saut de ligne entre les caractères d'Extrême-Orient sont supprimés. Consultez la section sur les caractères d'Extrême-Orient ci-dessous pour une définition de ces caractères.

  2. Tous les caractères d'espace blanc (espace, saut de ligne, tabulation) sont convertis en espaces.

  3. Tous les espaces consécutifs sont supprimés et remplacés par un espace.

  4. Un espace qui suit immédiatement la balise de début est supprimé.

  5. Un espace qui précède immédiatement la balise de fin est supprimé.

La « valeur par défaut » correspond à l'état désigné par la valeur par défaut de l'attribut xml:space.

Espace blanc dans le texte interne et les valeurs de chaîne primitives

Les règles de normalisation précitées s'appliquent au texte interne qui se trouve dans des éléments XAML. Après la normalisation, un processeur XAML convertit tout texte interne dans un type approprié comme suit :

  • Si le type de la propriété n'est pas une collection, mais n'est pas directement un type Object, le processeur XAML tente de convertir vers ce type à l'aide de son convertisseur de type. L'échec de la conversion provoquera une erreur de compilation.

  • Si le type de la propriété est une collection et que le texte interne est contigu (aucune balise d'élément intermédiaire), le texte interne est analysé comme un String unique. Si le type collection ne peut pas accepter String, une erreur de compilation est également générée.

  • Si le type de la propriété est Object, le texte interne est analysé comme un String unique. En cas de balises d'élément intermédiaires, une erreur de compilation est générée, parce que le type Object implique un objet unique (String ou autre).

  • Si le type de la propriété est une collection et que le texte interne n'est pas contigu, la première sous-chaîne est convertie en String et ajoutée en tant qu'élément de collection, l'élément intermédiaire est ajouté en tant qu'élément de collection et la sous-chaîne de fin (le cas échéant) est ajoutée à la collection comme troisième élément String.

Espace blanc et modèles de contenu de texte

Dans la pratique, la conservation de l'espace blanc ne pose problème que pour un sous-ensemble de tous les modèles de contenu possibles. Ce sous-ensemble se compose des modèles de contenu qui peuvent prendre un type String singleton d'une certaine manière, une collection String dédiée ou un mélange de String et d'autres types dans une collection IList ou ICollection<T>.

Même pour les modèles de contenu qui peuvent prendre des chaînes, le comportement par défaut de ces modèles de contenu est le suivant : tout espace blanc restant n'est pas traité comme significatif. Par exemple, ListBox prend un IList, mais l'espace blanc (p. ex. : des sauts de ligne entre chaque ListBoxItem) n'est ni conservé ni rendu. En fait, il ne sert à rien d'essayer d'utiliser des sauts de ligne comme séparateurs entre des chaînes pour des éléments ListBoxItem. Les chaînes séparées par les sauts de ligne sont traitées comme une chaîne et un élément.

Ces collections qui traitent l'espace blanc comme significatif font en général partie du modèle de document dynamique. La principale collection qui prend en charge le comportement de conservation des espaces blancs est InlineCollection. Cette classe de collection est déclarée avec WhitespaceSignificantCollectionAttribute. Lorsque cet attribut est trouvé, le processeur XAML traitera l'espace blanc dans la collection comme significatif. La combinaison de xml:space="preserve" et d'espace blanc dans une collection WhitespaceSignificantCollectionAttribute dénotée engendre que TOUS les espaces blancs sont conservés et rendus. La combinaison de xml:space="default" et d'espace blanc dans un WhitespaceSignificantCollectionAttribute engendrera la normalisation d'espace blanc initiale décrite ci-dessus, ce qui laissera un espace blanc dans certaines positions et ces espaces blancs seront conservés et rendus. À vous de déterminer le comportement souhaité et d'utiliser xml:space de manière sélective pour activer le comportement de votre choix.

De même, certains éléments inclus qui correspondent à un saut de ligne dans un modèle de document dynamique ne doivent pas introduire délibérément un espace supplémentaire même dans une collection significative d'espaces blancs. Par exemple, l'élément LineBreak poursuit le même objectif que la balise <BR/> dans HTML. Pour des raisons de lisibilité des balises, un LineBreak est généralement séparé du texte qui suit par un saut de ligne créé. Ce saut de ligne ne doit pas être normalisé pour devenir un espace de début dans la ligne suivante. Pour activer ce comportement, la définition de classe pour l'élément LineBreak applique le TrimSurroundingWhitespaceAttribute, qui est ensuite interprété par le processeur XAML pour indiquer que l'espace blanc qui entoure LineBreak est toujours supprimé.

Conservation de l'espace blanc

Plusieurs techniques permettant de conserver l'espace blanc dans le code XAML source pour une présentation finale ne sont pas affectées par la normalisation des espaces blancs du processeur XAML.

xml:space="preserve" : Spécifiez cet attribut au niveau de l'élément où la conservation d'espace blanc est souhaitée. Notez que tous les espaces blancs seront conservés, y compris les espaces qui peuvent être ajoutés par les applications d'édition de code pour imprimer correctement des éléments alignés comme une imbrication visuellement intuitive. Cependant, ces espaces sont rendus en fonction du modèle de contenu de l'élément conteneur. Il n'est pas recommandé de spécifier xml:space="preserve" au niveau racine, car la majorité des modèles objet ne considère pas l'espace blanc comme significatif. Il est préférable de définir uniquement l'attribut spécifiquement au niveau des éléments qui rendent l'espace blanc dans des chaînes ou qui sont des collections significatives d'espaces blancs.

Entités et espaces insécables : le XAML prend en charge l'insertion d'une entité Unicode dans un modèle objet de texte. Vous pouvez utiliser des entités dédiées telles que des espaces insécables (&#160; dans le codage UTF-8). Vous pouvez également utiliser des contrôles de texte enrichi que prennent en charge des caractères d'espace insécable. Soyez prudent lorsque vous utilisez des entités pour simuler des caractéristiques de mise en page (telles que la mise en retrait), car la sortie à l'exécution des entités variera selon un plus grand nombre de facteurs que les fonctionnalités de mise en page générales (telle que l'utilisation appropriée de panneaux et de marges). Par exemple, les entités sont mappées aux polices et peuvent changer de taille en fonction de la police sélectionnée par l'utilisateur.

Caractères d'Extrême-Orient

Les caractères d'Extrême-Orient sont définis comme un jeu de caractères Unicode allant de U+20000 à U+2FFFD et de U+30000 à U+3FFFD. Ce sous-ensemble est parfois appelé « idéogrammes CJK ». Pour plus d'informations, consultez http://www.unicode.org.

Voir aussi

Concepts

Vue d'ensemble du langage XAML

Référence

Entités de caractères XML et XAML

Gestion de xml:space en XAML