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 L'API può essere riepilogata nel modo seguente: Load o Parse per supportare un percorso di caricamento XAML, Save per supportare un percorso di salvataggio XAML e Transform 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. In questo argomento vengono riepilogate le classificazioni di ognuna di queste API e vengono descritte le differenze tra determinati overload dei metodi.

Load

Diversi overload di Load implementano la logica completa per un percorso di caricamento. Il percorso di caricamento usa XAML in diversi formati e restituisce un flusso del nodo XAML. La maggior parte di questi percorsi di caricamento usa XAML in un formato di file di testo XML codificato. È tuttavia anche possibile caricare un flusso generale oppure un'origine XAML precaricata già inclusa in una implementazione XamlReader diversa.

L'overload più semplice per la maggior parte degli scenari è Load(String). Questo overload dispone di un parametro fileName che rappresenta semplicemente il nome di un file di testo contenente il codice XAML da caricare. Costituisce la soluzione appropriata per scenari di applicazioni, ad esempio applicazioni con attendibilità totale in cui è stata eseguita in precedenza la serializzazione dello stato o dei dati nel computer locale. È anche utile per i framework in cui viene definito il modello di applicazione e si vuole caricare uno dei file standard che definisce il comportamento dell'applicazione, l'interfaccia utente di avvio o altre funzionalità definite dal framework che usano XAML.

Load(Stream) dispone di altri scenari simili. Questo overload può essere utile nei casi in cui l'utente sceglie i file da caricare, in quanto Stream rappresenta un output frequente di altre API System.IO che possono accedere a un file system oppure nei casi in cui l'accesso alle origini XAML viene eseguito 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, vedi 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 formato pertinente (testo o XML). Non è importante se i puntatori dei record sono stati già spostati negli altri reader o se con questi sono state eseguite altre operazioni. La logica del percorso di caricamento da Load determina sempre l'elaborazione dell'intero input XAML dalla radice verso il basso. Gli scenari seguenti potrebbero giustificare l'uso di questi overload:

  • Aree di progettazione in cui si forniscono funzionalità di modifica di XAML semplici da un editor di testo specifico di XML esistente.

  • Varianti degli scenari di System.IO in cui si usano i reader dedicati per aprire file o flussi. La logica esegue la verifica rudimentale o l'elaborazione del contenuto prima di effettuare un tentativo di caricamento come XAML.

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

A livello interno, ognuno degli overload precedenti è in definitiva un oggetto Load(XmlReader)e l'oggetto XmlReader passato viene usato per creare un nuovo oggetto 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 oggetto XamlReader.

  • È necessario specificare impostazioni per XamlReader diverse dalle impostazioni predefinite.

Esempi di impostazioni non predefinite:

AllowProtectedMembersOnRoot
BaseUri
IgnoreUidsOnPropertyElements
LocalAssembly
ValuesMustBeString.

Il reader predefinito di XamlServices è XamlXmlReader. Se si specificano impostazioni personalizzate XamlXmlReader , di seguito sono riportate le proprietà per impostare un valore non predefinito XamlXmlReaderSettings:

CloseInput
SkipXmlCompatibilityProcessing
XmlLang
XmlSpacePreserve

Analizza

Parse è analogo a Load in quanto è un'API del percorso di caricamento che crea un flusso del nodo XAML da un input XAML. In questo caso l'input XAML viene fornito direttamente come una stringa che contiene tutto il codice XAML da caricare. Parse è un approccio leggero più adatto a scenari di applicazioni che a quelli di framework. Per ulteriori informazioni, vedere Parse. Parse è solo una chiamata di Load(XmlReader) cui è stato eseguito il wrapping che coinvolge internamente un oggetto StringReader .

Salva

Diversi overload di Save implementano il percorso di salvataggio. Tutte i metodi Save accettano un oggetto grafico come input e producono l'output come flusso, file o istanza di XmlWriter/TextWriter .

L'oggetto di input deve essere l'oggetto radice di alcune rappresentazioni dell'oggetto. Potrebbe trattarsi della radice di un oggetto business, della radice di un albero degli oggetti per una pagina in un scenario di interfaccia utente, della superficie di modifica di lavoro di un strumento di progettazione oppure di altri concetti dell'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. L'albero degli oggetti potrebbe presentare differenze determinate da cambiamenti di stato, modifiche nel punto in cui l'applicazione ha acquisito le impostazioni di runtime di un utente, codice XAML modificato perché l'applicazione è un'area di progettazione XAML e così via. Con o senza modifiche, il concetto di caricamento iniziale del codice XAML dal markup e del suo successivo ulteriore salvataggio, seguito dal confronto dei due formati di markup XAML, viene talvolta definito come una rappresentazione di round trip del codice XAML.

Quando si salva e si serializza un oggetto complesso impostato in un formato di markup, la sfida consiste nel raggiungere un bilanciamento ottimale tra una rappresentazione completa senza perdita di informazioni e l'eccesso di dettagli che rendono il codice XAML difficilmente leggibile. Inoltre, clienti di XAML diversi potrebbero oltretutto usare definizioni diverse o avere altre aspettative rispetto a tale modalità di bilanciamento. Le API Save rappresentano una definizione di tale bilanciamento. Le API Save usano il contesto dello schema XAML disponibile e le caratteristiche basate su CLR predefinite di XamlType, XamlMember, nonché altri concetti intrinseci di XAML e del sistema di tipi XAML per determinare la posizione in cui costrutti del flusso del nodo XAML specifici possono essere ottimizzati quando vengono nuovamente salvati nel markup. Ad esempio,i percorsi di salvataggio XamlServices possono usare il contesto dello schema XAML predefinito basato su CLR per risolvere XamlType per gli oggetti, determinare un oggetto XamlType.ContentPropertye quindi omettere tag di elementi proprietà durante la scrittura della proprietà del contenuto XAML dell'oggetto.

Trasformazione

Transform esegue la conversione o la trasformazione di XAML tramite il collegamento a un percorso di caricamento e a un percorso di salvataggio come una sola operazione. Per XamlReader e XamlWriterè possibile usare un contesto dello schema diverso o un sistema di tipi di supporto diverso, essendo questi gli elementi che influenzano il modo in cui il codice XAML risultante viene trasformato. Si tratta di una soluzione appropriata per le operazioni di trasformazione ampie.

Per le operazioni che si basano sull'esame di ogni nodo in un flusso del nodo XAML, il metodo Transformnon viene in genere usato. È invece necessario definire una serie di operazioni del percorso di caricamento e di salvataggio personalizzate, quindi inserire la logica personalizzata. In uno dei percorsi, usare una coppia di writer XAML reader XAML intorno al ciclo del nodo. Ad esempio, caricare il codice XAML iniziale usando XamlXmlReader e avanzare nei nodi con chiamate Read successive. Operando a livello del flusso del nodo XAML, è ora possibile regolare i singoli nodi (tipi, membri, altri nodi) per applicare una trasformazione oppure lasciare il nodo invariato. Il nodo verrà quindi inviato in avanti all'API Write pertinente di un oggetto XamlObjectWriter e si scriverà l'oggetto. Per altre informazioni, vedere Understanding XAML Node Stream Structures and Concepts.

Vedi anche