Delen via

Witruimteverwerking in XAML

  • Artikel

De taalregels voor XAML stellen dat aanzienlijke witruimte moet worden verwerkt door een XAML-processor-implementatie. In dit artikel worden deze XAML-taalregels beschreven. Het document documenteert ook aanvullende witruimteafhandeling die is gedefinieerd door de WPF-implementatie (Windows Presentation Foundation) van de XAML-processor en de XAML-schrijver voor serialisatie.

Witruimtedefinitie

Consistent met XML zijn spatietekens in XAML spatie, regelfeed en tab. Deze komen overeen met de Unicode-waarden 0020, 000A en 0009.

Normalisatie van witruimte

Standaard vindt de volgende normalisatie van witruimte plaats wanneer een XAML-processor een XAML-bestand verwerkt:

  1. Regelfeedtekens tussen Oost-Aziatische tekens worden verwijderd. Zie de sectie Oost-Aziatische tekens verderop in dit onderwerp voor een definitie van deze term.

  2. Alle spatietekens (spatie, regelfeed, tabblad) worden geconverteerd naar spaties.

  3. Alle opeenvolgende spaties worden verwijderd en vervangen door één spatie.

  4. Een spatie direct na de starttag wordt verwijderd.

  5. Een spatie direct voordat de eindtag wordt verwijderd.

'Standaard' komt overeen met de status die wordt aangeduid met de standaardwaarde van het kenmerk xml:space.

Witruimte in binnenste tekst en tekenreeksprimitief

De vorige normalisatieregels zijn van toepassing op binnenste tekst die in XAML-elementen wordt gevonden. Na normalisatie converteert een XAML-processor elke binnenste tekst als volgt naar een geschikt type:

  • Als het type van de eigenschap geen verzameling is, maar niet rechtstreeks een Object type is, probeert de XAML-processor naar dat type te converteren met behulp van het typeconversieprogramma. Een mislukte conversie veroorzaakt hier een compilatiefout.

  • Als het type eigenschap een verzameling is en de binnenste tekst aaneengesloten is (geen tussenliggende elementtags), wordt de binnenste tekst geparseerd als één String. Als het verzamelingstype geen Stringkan accepteren, veroorzaakt dit ook een compilatietijdfout.

  • Als het type eigenschap Objectis, wordt de binnenste tekst geparseerd als één String. Als er tussenliggende elementtags zijn, veroorzaakt dit een compilatiefout omdat het Object type één object (String of anderszins) impliceert.

  • Als het type van de eigenschap een verzameling is en de binnenste tekst niet aaneengesloten is, wordt de eerste subtekenreeks geconverteerd naar een String en toegevoegd als een verzamelingsitem, wordt het tussenliggende element toegevoegd als een verzamelingsitem en ten slotte wordt de volgsubtekenreeks (indien aanwezig) toegevoegd aan de verzameling als een derde String item.

Witruimte behouden

Er zijn verschillende technieken voor het behouden van witruimte in de bron-XAML voor uiteindelijke presentaties die niet worden beïnvloed door de normalisatie van witruimte in de XAML-processor.

xml:space="preserve": geef dit kenmerk op het niveau van het element op waar behoud van witruimte gewenst is. Hierdoor blijft alle witruimte behouden, waaronder de spaties die kunnen worden toegevoegd door codebewerkingstoepassingen om elementen 'pretty-print' uit te lijnen als visueel intuïtief nesten. Of deze spaties echter worden weergegeven door het inhoudsmodel voor het element dat het bevat. Vermijd het opgeven van xml:space="preserve" op hoofdniveau, omdat de meeste objectmodellen geen witruimte als belangrijk beschouwen, ongeacht hoe u het kenmerk instelt. Het instellen van xml:space wereldwijd kan gevolgen hebben voor de prestaties van XAML-verwerking (met name serialisatie) in sommige implementaties. Het is een betere gewoonte om alleen het kenmerk specifiek in te stellen op het niveau van elementen die witruimte binnen tekenreeksen weergeven of significante verzamelingen met witruimte zijn.

entiteiten en niet-brekende spaties: XAML ondersteunt het plaatsen van een Unicode-entiteit in een tekstobjectmodel. U kunt toegewezen entiteiten gebruiken, zoals vaste ruimte (  in UTF-8-codering). U kunt ook besturingselementen voor tekst met opmaak gebruiken die vrije ruimtetekens ondersteunen. U moet voorzichtig zijn als u entiteiten gebruikt om indelingskenmerken zoals inspringing te simuleren, omdat de runtime-uitvoer van de entiteiten varieert op basis van een groter aantal factoren dan de mogelijkheden voor het produceren van inspringing resulteert in een typisch indelingssysteem, zoals het juiste gebruik van panelen en marges. Entiteiten worden bijvoorbeeld toegewezen aan lettertypen en kunnen de grootte wijzigen als reactie op de selectie van gebruikerslettertypen.

Oost-Aziatische tekens

Oost-Aziatische tekens worden gedefinieerd als een set Unicode-tekenbereiken U+20000 tot U+2FFFD en U+30000 tot U+3FFFD. Deze subset wordt ook wel 'CJK ideographs' genoemd. Zie https://www.unicode.orgvoor meer informatie.

Witruimte- en tekstinhoudsmodellen

In de praktijk is het behouden van witruimte alleen belangrijk voor een subset van alle mogelijke inhoudsmodellen. Deze subset bestaat uit inhoudsmodellen die een singleton String type in een bepaalde vorm kunnen hebben, een toegewezen String verzameling of een combinatie van String en andere typen in een IList of ICollection<T> verzameling.

Witruimte en tekstinhoudsmodellen in WPF

Ter illustratie verwijst de rest van deze sectie naar bepaalde typen die zijn gedefinieerd door WPF. De witruimteafhandelingsfuncties die in dit artikel worden beschreven, zijn relevant voor zowel .NET XAML Services als WPF. Als u dit gedrag in actie wilt zien, kunt u experimenteren met sommige WPF XAML-markeringen, de resultaten in een objectgrafiek bekijken en vervolgens weer serialiseren naar markeringen.

Zelfs voor inhoudsmodellen die tekenreeksen kunnen aannemen, is het standaardgedrag binnen deze inhoudsmodellen dat witruimte die overblijft, niet als significant wordt behandeld. ListBox neemt bijvoorbeeld een IList, maar de witruimte (zoals regelfeeds tussen elke ListBoxItem) blijft niet behouden en wordt niet weergegeven. Als u linefeeds probeert te gebruiken als scheidingstekens tussen tekenreeksen voor ListBoxItem items, werkt dit helemaal niet; de tekenreeksen die door de regelfeeds worden gescheiden, worden behandeld als één tekenreeks en één item.

Deze verzamelingen die witruimte behandelen als belangrijk, maken doorgaans deel uit van het stroomdocumentmodel. De primaire verzameling die ondersteuning biedt voor het behoud van witruimte is InlineCollection. Deze verzamelingsklasse wordt gedeclareerd met de WhitespaceSignificantCollectionAttribute; wanneer dit kenmerk wordt gevonden, behandelt de XAML-processor witruimte binnen de verzameling als significant. De combinatie van xml:space="preserve" en witruimte binnen een WhitespaceSignificantCollectionAttribute aangegeven verzameling is dat alle witruimte behouden blijft en weergegeven. De combinatie van xml:space="default" en witruimte binnen een WhitespaceSignificantCollectionAttribute zorgt ervoor dat de initiële witruimtenormalisatie die eerder is beschreven, één spatie in bepaalde posities laat en die spaties behouden en weergegeven. Welk gedrag wenselijk is, is aan u en u moet xml:space selectief gebruiken om het gewenste gedrag in te schakelen.

Bovendien moeten bepaalde inline-elementen die een regeleinde in een stroomdocumentmodel aanduen, opzettelijk geen extra ruimte introduceren, zelfs in een aanzienlijke verzameling witruimte. Het LineBreak-element heeft bijvoorbeeld hetzelfde doel als de tag <BR/> in HTML en voor leesbaarheid in markeringen, meestal wordt een LineBreak gescheiden van eventuele volgende tekst door een geschreven regelfeed. Deze regelfeed mag niet worden genormaliseerd om een voorloopruimte in de volgende regel te worden. Om dat gedrag mogelijk te maken, past de klassedefinitie voor het element LineBreak de TrimSurroundingWhitespaceAttributetoe, die vervolgens wordt geïnterpreteerd door de XAML-processor, zodat de witruimte rondom LineBreak altijd wordt ingekort.

Zie ook