Condividi tramite

Classe XAMLServices e lettura o scrittura XAML di base

  • Articolo

XamlServices è una classe fornita da .NET che può essere usata per risolvere gli scenari XAML che non richiedono l'accesso specifico al flusso del nodo XAML o alle informazioni sul sistema dei tipi XAML ottenute da tali nodi. XamlServices'API può essere riepilogata come segue: Load o Parse per supportare un percorso di caricamento XAML, Save per supportare un percorso di salvataggio XAML e Transform per fornire una tecnica che unisce un percorso di caricamento e salvare il percorso. Transform può essere usato per passare da uno schema XAML a un altro. Questo argomento riepiloga ognuna di queste classificazioni API e descrive le differenze tra overload di metodi specifici.

Carico

Vari overload di Load implementano la logica completa per un percorso di caricamento. Il percorso di caricamento usa XAML in qualche formato e restituisce un flusso di nodi XAML. La maggior parte di questi percorsi di caricamento usa XAML in un formato di file di testo XML codificato. Tuttavia, puoi anche caricare un flusso generale oppure caricare un'origine XAML precaricata già contenuta in un'implementazione XamlReader diversa.

L'overload più semplice per la maggior parte degli scenari è Load(String). Questo overload ha un parametro fileName che è semplicemente il nome di un file di testo che contiene il codice XAML da caricare. Questa opzione è appropriata per gli scenari dell'applicazione, ad esempio applicazioni con attendibilità totale che in precedenza hanno serializzato lo stato o i dati nel computer locale. Ciò è utile anche per i framework in cui si definisce il modello di applicazione e si vuole caricare uno dei file standard che definisce il comportamento dell'applicazione, l'avvio dell'interfaccia utente o altre funzionalità definite dal framework che usano XAML.

Load(Stream) presenta scenari simili. Questo overload può essere utile se l'utente sceglie i file da caricare, perché un Stream è un output frequente di altre API System.IO che possono accedere a un file system. In alternativa, è possibile accedere alle origini XAML tramite download asincroni o altre tecniche di rete che forniscono anche un flusso. Il caricamento da un flusso o da un'origine selezionata dall'utente può avere implicazioni sulla sicurezza. Per altre informazioni, vedere considerazioni sulla sicurezza XAML.)

Load(TextReader) e Load(XmlReader) sono overload che si basano sui lettori di formati delle versioni precedenti di .NET. Per usare questi overload, è necessario aver già creato un'istanza del lettore e usare l'API Create per caricare il codice XAML nel modulo pertinente (testo o XML). Se sono già stati spostati puntatori di record negli altri lettori o se sono state eseguite altre operazioni con essi, questo non è importante. La logica del percorso di caricamento da Load elabora sempre l'intero input XAML dalla radice verso il basso. Gli scenari seguenti potrebbero giustificare l'uso di questi overload:

  • Aree di progettazione in cui fornisci una semplice funzionalità di modifica XAML da un editor di testo specifico di XML esistente.

  • Varianti degli scenari principali System.IO, in cui si usano i lettori dedicati per aprire file o flussi. La logica esegue il controllo o l'elaborazione rudimentale del contenuto prima che tenti di caricare come XAML.

È possibile caricare un file o un flusso oppure caricare un XmlReader, TextReadero XamlReader che esegue il wrapping dell'input XAML caricando con le API del lettore.

Internamente, ognuno degli overload precedenti viene in definitiva Load(XmlReader)e il XmlReader passato viene usato per creare un nuovo XamlXmlReader.

La firma Load che fornisce scenari più avanzati è Load(XamlReader). È possibile usare questa firma per uno dei casi seguenti:

  • È stata definita la propria implementazione di un XamlReader.

  • È necessario specificare le impostazioni per XamlReader che variano dalle impostazioni predefinite.

Esempi di impostazioni non predefinite:

AllowProtectedMembersOnRoot
BaseUri
IgnoreUidsOnPropertyElements
LocalAssembly
ValuesMustBeString.

Il lettore predefinito per XamlServices è XamlXmlReader. Se si specifica un XamlXmlReader personalizzato con le impostazioni, di seguito sono riportate le proprietà per impostare XamlXmlReaderSettingsnon predefinite:

CloseInput
SkipXmlCompatibilityProcessing
XmlLang
XmlSpacePreserve

Analizzare

Parse è come Load perché si tratta di un'API del percorso di caricamento che crea un flusso di nodi XAML dall'input XAML. In questo caso, tuttavia, l'input XAML viene fornito direttamente come stringa che contiene tutto il codice XAML da caricare. Parse è un approccio leggero più appropriato per gli scenari dell'applicazione rispetto agli scenari del framework. Per altre informazioni, vedere Parse. Parse è solo una chiamata di Load(XmlReader) di cui è stato eseguito il wrapping che implica un StringReader internamente.

Salvare

Vari overload di Save implementare il percorso di salvataggio. Tutti i metodi Save accettano tutti un oggetto grafico come input e producono output come flusso, file o XmlWriter/TextWriter istanza.

L'oggetto di input deve essere l'oggetto radice di una rappresentazione dell'oggetto. Potrebbe trattarsi della singola radice di un oggetto business, della radice di un albero di oggetti per una pagina in uno scenario dell'interfaccia utente, della superficie di modifica funzionante da uno strumento di progettazione o di altri concetti di oggetto radice appropriati per gli scenari.

In molti scenari, l'albero degli oggetti salvato è correlato a un'operazione originale che ha caricato XAML con Load o con altre API implementate da un modello framework/applicazione. Potrebbero esserci differenze acquisite nell'albero degli oggetti dovute a modifiche di stato, modifiche in cui l'applicazione ha acquisito le impostazioni di runtime da un utente, modificato XAML perché l'applicazione è un'area di progettazione XAML e così via. Con o senza modifiche, il concetto di caricamento del codice XAML dal markup e quindi del salvataggio e del confronto dei due moduli di markup XAML viene talvolta definito rappresentazione round trip del codice XAML.

La sfida con il salvataggio e la serializzazione di un oggetto complesso impostato in un modulo di markup consiste nel raggiungere un equilibrio tra la rappresentazione completa senza perdita di informazioni, rispetto alla verbosità che rende il codice XAML meno leggibile. Inoltre, clienti diversi per XAML potrebbero avere definizioni o aspettative diverse per il modo in cui deve essere impostato tale equilibrio. Le API Save rappresentano una definizione di tale bilanciamento. Le API Save usano il contesto dello schema XAML disponibile e le caratteristiche predefinite basate su CLR di XamlType, XamlMembere altri concetti intrinseci e di sistema dei tipi XAML per determinare dove è possibile ottimizzare determinati costrutti del flusso di nodi XAML quando vengono salvati di nuovo nel markup. Ad esempio, XamlServices i percorsi di salvataggio possono usare il contesto dello schema XAML predefinito basato su CLR per risolvere XamlType per gli oggetti, può determinare un XamlType.ContentPropertye quindi può omettere i tag degli elementi di proprietà quando scrivono la proprietà nel contenuto XAML dell'oggetto.

Trasformare

Transform converte o trasforma XAML collegando un percorso di caricamento e un percorso di salvataggio come singola operazione. È possibile usare un contesto di schema diverso o un sistema di tipi di supporto diverso per XamlReader e XamlWriter, che influisce sul modo in cui viene trasformato il codice XAML risultante. Questo funziona bene per le operazioni di trasformazione su larga scala.

Per le operazioni che si basano sull'analisi di ogni nodo in un flusso di nodi XAML, in genere non si usa Transform. È invece necessario definire una serie di operazioni di percorso di salvataggio del percorso di caricamento personalizzate e inserire una logica personalizzata. In uno dei percorsi usa una coppia di writer XAML reader/XAML intorno al tuo ciclo di nodi. Ad esempio, caricare il codice XAML iniziale usando XamlXmlReader ed eseguire l'istruzione nei nodi con chiamate Read successive. Operando a livello di flusso del nodo XAML è ora possibile modificare i singoli nodi (tipi, membri, altri nodi) per applicare una trasformazione o lasciare il nodo as-is. Quindi si invia il nodo all'API Write pertinente di un XamlObjectWriter e si scrive l'oggetto. Per altre informazioni, vedere Understanding XAML Node Stream Structures and Concepts.For more information, see Understanding XAML Node Stream Structures and Concepts.

Vedere anche