Limitazioni relative alla serializzazione di XamlWriter.Save

  • Articolo

L'API Save può essere usata per serializzare il contenuto di un'applicazione Windows Presentation Foundation (WPF) come file XAML (Extensible Application Markup Language). Esistono tuttavia limitazioni considerevoli relative alla definizione precisa dell'oggetto della serializzazione. Queste limitazioni vengono esaminate in questo argomento, insieme ad alcune considerazioni generali.

Rappresentazione della fase di esecuzione, non della fase di progettazione

La filosofia di base di ciò che viene serializzato da una chiamata a Save è che il risultato sarà una rappresentazione dell'oggetto serializzato, in fase di esecuzione. Molte proprietà della fase di progettazione del file XAML originale potrebbero essere già ottimizzate o perse dal momento in cui il codice XAML viene caricato come oggetti in memoria e non vengono mantenute quando si chiama Save per serializzare. Il risultato serializzato è una rappresentazione efficace dell'albero logico costruito dell'applicazione, ma non necessariamente del codice XAML originale che lo ha prodotto. Questi problemi rendono estremamente difficile usare la Save serializzazione come parte di un'ampia area di progettazione XAML.

La serializzazione è autonoma

L'output serializzato di è indipendente. Tutto ciò che viene serializzato è contenuto all'interno di Save una singola pagina XAML, con un singolo elemento radice e nessun riferimento esterno diverso dagli URI. Ad esempio, se una pagina faceva riferimento a risorse dalle risorse dell'applicazione, queste appariranno come componenti della pagina serializzata.

I riferimenti alle estensioni vengono dereferenziati

I riferimenti comuni agli oggetti realizzati in diversi formati di estensione di markup, ad esempio StaticResource o Binding, saranno dereferenziati durante il processo di serializzazione. Questi oggetti sono già stati dereferenziati al momento della creazione di oggetti in memoria dal runtime dell'applicazione e la Save logica non rivede il codice XAML originale per ripristinare tali riferimenti all'output serializzato. In questo modo, potenzialmente qualsiasi valore associato ai dati o proveniente dalla risorsa viene bloccato sull'ultimo valore usato dalla rappresentazione in fase di esecuzione, con possibilità solo limitate o indirette di distinguerlo da qualsiasi altro valore impostato localmente. Le immagini vengono serializzate anche come riferimenti a oggetti alle immagini così come sono presenti nel progetto, anziché come riferimenti di origine originali, perdendo qualsiasi nome file o URI a cui è stato originariamente fatto riferimento. Perfino le risorse dichiarate all'interno della stessa pagina sono serializzate nel punto in cui vengono referenziate, anziché essere conservate come chiave della raccolta di risorse.

La gestione degli eventi non viene mantenuta

Quando i gestori eventi aggiunti tramite XAML vengono serializzati, non vengono mantenuti. XAML senza code-behind (e anche senza il meccanismo x:Code correlato) non ha modo di serializzare la logica procedurale del runtime. Poiché la serializzazione è autonoma e limitata all'albero logico, non sono disponibili funzionalità per l'archiviazione dei gestori eventi. Di conseguenza, gli attributi del gestore eventi, sia l'attributo stesso che il valore stringa che denomina il gestore, vengono rimossi dal codice XAML di output.

Scenari realistici per l'uso di XamlWriter.Save

Anche se le limitazioni elencate di seguito sono piuttosto sostanziali, esistono ancora diversi scenari appropriati per l'uso Save per la serializzazione.

  • Output vettoriale o grafico: l'output dell'area sottoposta a rendering può essere usato per riprodurre lo stesso vettore o la stessa grafica se caricato nuovamente.

  • Documenti RTF o dinamici: il testo con tutta la formattazione e il contenimento degli elementi inclusi viene mantenuto nell'output. Questo può essere utile per i meccanismi che si avvicinano a una funzionalità degli Appunti.

  • Mantenimento dei dati degli oggetti business: se sono stati archiviati dati in elementi personalizzati, ad esempio dati XML, a condizione che gli oggetti business seguano le regole XAML di base, ad esempio la fornitura di costruttori personalizzati e la conversione per i valori delle proprietà per riferimento, questi oggetti business possono essere perpetuati tramite la serializzazione.