Struktur dan konsep aliran simpul XAML

Pembaca XAML dan penulis XAML seperti yang diimplementasikan dalam Layanan XAML .NET didasarkan pada konsep desain aliran simpul XAML. Aliran simpul XAML adalah konseptualisasi sekumpulan simpul XAML. Dalam konseptualisasi ini, prosesor XAML berjalan melalui struktur hubungan simpul di XAML satu per satu. Kapan saja, hanya satu rekaman saat ini atau posisi saat ini yang ada dalam aliran simpul XAML terbuka, dan banyak aspek laporan API hanya informasi yang tersedia dari posisi tersebut. Simpul saat ini dalam aliran simpul XAML dapat dijelaskan sebagai objek, anggota, atau nilai. Dengan memperlakukan XAML sebagai aliran simpul XAML, pembaca XAML dapat berkomunikasi dengan penulis XAML dan memungkinkan program untuk melihat, berinteraksi dengan, atau mengubah konten aliran simpul XAML selama jalur beban atau operasi jalur penyimpanan yang melibatkan XAML. Desain API pembaca dan penulis XAML dan konsep aliran simpul XAML mirip dengan desain dan konsep pembaca dan penulis terkait sebelumnya, seperti XML Document Object Model (DOM) dan kelas XmlReader dan XmlWriter. Topik ini membahas konsep aliran simpul XAML dan menjelaskan bagaimana Anda dapat menulis rutinitas yang berinteraksi dengan representasi XAML di tingkat simpul XAML.

Memuat XAML ke dalam Pembaca XAML

Kelas XamlReader dasar tidak mendeklarasikan teknik tertentu untuk memuat XAML awal ke pembaca XAML. Sebaliknya, kelas turunan menyatakan dan mengimplementasikan teknik pemuatan, termasuk karakteristik umum dan batasan sumber inputnya untuk XAML. Misalnya, XamlObjectReader membaca grafik objek, dimulai dari sumber input objek tunggal yang mewakili akar atau dasar. XamlObjectReader kemudian menghasilkan aliran simpul XAML dari grafik objek.

Subkelas XamlReader .NET XAML Services yang paling menonjol adalah XamlXmlReader. XamlXmlReader memuat XAML awal, baik dengan memuat file teks langsung melalui aliran atau jalur file, atau secara tidak langsung melalui kelas pembaca terkait seperti TextReader. XamlReader dapat dianggap berisi keseluruhan sumber input XAML setelah dimuat. Namun, API dasar XamlReader dirancang sehingga pembaca berinteraksi dengan satu simpul XAML. Ketika pertama kali dimuat, simpul tunggal pertama yang Anda temui adalah akar XAML, dan objek mulainya.

Konsep Aliran Simpul XAML

Jika Anda lebih terbiasa dengan pendekatan berbasis DOM, metafora pohon, atau kueri untuk mengakses teknologi berbasis XML, cara yang berguna untuk mengonsep aliran simpul XAML adalah sebagai berikut. Bayangkan bahwa XAML yang dimuat adalah DOM atau pohon di mana setiap simpul yang mungkin diperluas sepanjang jalan, dan kemudian disajikan secara linier. Saat Anda maju melalui simpul, Anda mungkin melintasi "masuk" atau "keluar" dari tingkat yang akan relevan dengan DOM, tetapi aliran simpul XAML tidak secara eksplisit melacak karena konsep tingkat ini tidak relevan dengan aliran simpul. Aliran simpul memiliki posisi "saat ini", tetapi kecuali Anda telah menyimpan bagian lain dari streaming sendiri sebagai referensi, setiap aspek aliran simpul selain posisi simpul saat ini tidak terlihat.

Konsep aliran simpul XAML memiliki keuntungan penting bahwa jika Anda melalui seluruh aliran node, Anda yakin bahwa Anda telah memproses seluruh representasi XAML; Anda tidak perlu khawatir bahwa kueri, operasi DOM, atau beberapa pendekatan nonlinear lainnya untuk memproses informasi telah melewatkan beberapa bagian dari representasi XAML lengkap. Untuk alasan ini, representasi aliran simpul XAML sangat ideal untuk menghubungkan pembaca XAML dan penulis XAML, dan untuk menyediakan sistem di mana Anda dapat menyisipkan proses Anda sendiri yang bertindak antara fase baca dan tulis dari operasi pemrosesan XAML. Dalam banyak kasus, pengurutan simpul dalam aliran simpul XAML sengaja dioptimalkan atau disusun ulang oleh pembaca XAML versus bagaimana urutan mungkin muncul dalam teks sumber, biner, atau grafik objek. Perilaku ini dimaksudkan untuk memberlakukan arsitektur pemrosesan XAML di mana penulis XAML tidak pernah berada dalam posisi di mana mereka harus "kembali" di aliran simpul. Idealnya, semua operasi penulisan XAML harus dapat bertindak berdasarkan konteks skema ditambah posisi aliran simpul saat ini.

Perulangan Simpul Pembacaan Dasar

Loop simpul baca dasar untuk memeriksa aliran simpul XAML terdiri dari konsep berikut. Untuk tujuan perulangan simpul seperti yang dibahas dalam topik ini, asumsikan bahwa Anda membaca file XAML berbasis teks yang dapat dibaca manusia menggunakan XamlXmlReader. Tautan di bagian ini mengacu pada API perulangan simpul XAML tertentu yang diterapkan oleh XamlXmlReader.

  • Pastikan Anda tidak berada di akhir aliran simpul XAML (periksa IsEof, atau gunakan nilai pengembalian Read). Jika Anda berada di akhir aliran, tidak ada simpul saat ini dan Anda harus keluar.

  • Periksa jenis simpul apa yang saat ini diekspos oleh aliran simpul XAML dengan memanggil NodeType.

  • Jika Anda memiliki penulis objek XAML terkait yang terhubung langsung, Anda umumnya memanggil WriteNode pada saat ini.

  • Berdasarkan XamlNodeType mana yang dilaporkan sebagai simpul saat ini atau rekaman saat ini, panggil salah satu hal berikut untuk mendapatkan informasi tentang konten simpul:

    • Untuk NodeTypeStartMember atau EndMember, hubungi Member untuk mendapatkan informasi XamlMember tentang anggota. Anggota mungkin adalah XamlDirective, dan dengan demikian mungkin belum tentu menjadi anggota objek sebelumnya yang ditentukan jenis konvensional. Misalnya, x:Name diterapkan ke objek muncul sebagai anggota XAML di mana IsDirective benar dan Name anggota Name, dengan properti lain yang menunjukkan bahwa arahan ini berada di bawah namespace XAML bahasa XAML.

    • Untuk NodeTypeStartObject atau EndObject, panggil Type untuk mendapatkan informasi XamlType tentang objek.

    • Untuk NodeTypeValue, panggil Value. Simpul adalah nilai hanya jika itu adalah ekspresi nilai paling sederhana untuk anggota, atau teks inisialisasi untuk objek (namun, Anda harus mengetahui perilaku konversi jenis seperti yang didokumentasikan di bagian yang akan datang dari topik ini).

    • Untuk NodeTypeNamespaceDeclaration, panggil Namespace untuk mendapatkan informasi namespace layanan untuk simpul namespace.

  • Panggil Read untuk memajukan pembaca XAML ke simpul berikutnya di aliran simpul XAML, dan ulangi langkah-langkahnya lagi.

Aliran simpul XAML yang disediakan oleh pembaca XAML Layanan XAML .NET selalu menyediakan traversal penuh dan mendalam dari semua node yang mungkin. Teknik kontrol aliran umum untuk perulangan simpul XAML termasuk menentukan isi dalam while (reader.Read()), dan mengaktifkan NodeType di setiap titik simpul dalam perulangan simpul.

Jika aliran simpul berada di akhir file, simpul saat ini null.

Perulangan paling sederhana yang menggunakan pembaca dan penulis menyerupai contoh berikut.

XamlXmlReader xxr = new XamlXmlReader(new StringReader(xamlStringToLoad));
//where xamlStringToLoad is a string of well formed XAML
XamlObjectWriter xow = new XamlObjectWriter(xxr.SchemaContext);
while (xxr.Read()) {
  xow.WriteNode(xxr);
}

Contoh dasar perulangan simpul XAML jalur beban ini secara transparan menghubungkan pembaca XAML dan penulis XAML, tidak melakukan hal yang berbeda daripada jika Anda telah menggunakan XamlServices.Parse. Tetapi struktur dasar ini kemudian diperluas untuk diterapkan pada skenario membaca atau menulis Anda. Beberapa skenario yang mungkin adalah sebagai berikut:

  • Aktifkan NodeType. Lakukan tindakan yang berbeda tergantung pada jenis node mana yang sedang dibaca.

  • Jangan panggil WriteNode dalam semua kasus. Hanya panggil WriteNode dalam beberapa kasus NodeType.

  • Dalam logika untuk jenis node tertentu, analisis spesifik node tersebut dan bertindak pada node tersebut. Misalnya, Anda hanya dapat menulis objek yang berasal dari namespace XAML tertentu, lalu menjatuhkan atau menuguhkan objek apa pun yang bukan dari namespace XAML tersebut. Atau Anda dapat menghilangkan atau memproses ulang arahan XAML apa pun yang tidak didukung sistem XAML Anda sebagai bagian dari pemrosesan anggota Anda.

  • Tentukan XamlObjectWriter kustom yang mengambil alih metode Write*, mungkin melakukan pemetaan jenis yang melewati konteks skema XAML.

  • Buat XamlXmlReader untuk menggunakan konteks skema XAML nondefault, sehingga perbedaan yang disesuaikan dalam perilaku XAML digunakan oleh pembaca dan penulis.

Mengakses XAML Di Luar Konsep Perulangan Node

Ada kemungkinan cara lain untuk bekerja dengan representasi XAML selain sebagai perulangan simpul XAML. Misalnya, mungkin ada pembaca XAML yang dapat membaca simpul terindeks, atau dalam simpul akses tertentu langsung dengan x:Name, dengan x:Uid, atau melalui pengidentifikasi lain. Layanan XAML .NET tidak menyediakan implementasi penuh, tetapi menyediakan pola yang disarankan melalui jenis layanan dan dukungan. Untuk informasi selengkapnya, lihat IXamlIndexingReader dan XamlNodeList.

Bekerja dengan Simpul Saat Ini

Sebagian besar skenario yang menggunakan perulangan simpul XAML tidak hanya membaca simpul. Sebagian besar skenario memproses simpul saat ini dan meneruskan setiap simpul satu per satu ke implementasi XamlWriter.

Dalam skenario jalur beban umum, XamlXmlReader menghasilkan aliran simpul XAML; simpul XAML diproses sesuai dengan konteks logika dan skema XAML Anda; dan simpul diteruskan ke XamlObjectWriter. Anda kemudian mengintegrasikan grafik objek yang dihasilkan ke dalam aplikasi atau kerangka kerja Anda.

Dalam skenario jalur penyimpanan umum, XamlObjectReader membaca grafik objek, simpul XAML individual diproses, dan XamlXmlWriter menghasilkan hasil serial sebagai file teks XAML. Kuncinya adalah bahwa jalur dan skenario melibatkan kerja dengan tepat satu simpul XAML pada satu waktu, dan node XAML tersedia untuk perawatan dengan cara standar yang ditentukan oleh sistem jenis XAML dan THE.NET API Layanan XAML.

Bingkai dan Cakupan

Perulangan simpul XAML berjalan melalui aliran simpul XAML dengan cara linier. Aliran simpul melintasi ke objek, ke dalam anggota yang berisi objek lain, dan sebagainya. Seringkali berguna untuk melacak cakupan dalam aliran simpul XAML dengan menerapkan konsep bingkai dan tumpukan. Ini terutama benar jika Anda secara aktif menyesuaikan aliran simpul saat Anda berada di dalamnya. Dukungan bingkai dan tumpukan yang Anda terapkan sebagai bagian dari logika perulangan simpul Anda dapat menghitung StartObject (atau GetObject) dan EndObject cakupan saat Anda turun ke struktur simpul XAML jika struktur dipikirkan dari perspektif DOM.

Melintas dan Memasukkan Simpul Objek

Simpul pertama dalam aliran simpul ketika dibuka oleh pembaca XAML adalah simpul objek awal dari objek akar. Menurut definisi, objek ini selalu merupakan simpul objek tunggal dan tidak memiliki rekan. Dalam contoh XAML dunia nyata apa pun, objek akar didefinisikan untuk memiliki satu atau beberapa properti yang menyimpan lebih banyak objek, dan properti ini memiliki simpul anggota. Simpul anggota kemudian memiliki satu atau beberapa simpul objek, atau mungkin juga berakhir dalam simpul nilai sebagai gantinya. Objek akar biasanya mendefinisikan namescope XAML, yang secara sintetis ditetapkan sebagai atribut dalam markup teks XAML tetapi memetakan ke jenis node Namescope dalam representasi aliran simpul XAML.

Pertimbangkan contoh XAML berikut (ini adalah XAML arbitrer, tidak didukung oleh jenis yang ada di .NET). Asumsikan bahwa dalam model objek ini, FavorCollectionList<T>Favor, Balloon dan NoiseMaker dapat ditugaskan untuk Favor, properti Balloon.Color didukung oleh objek Color yang mirip dengan bagaimana WPF mendefinisikan warna sebagai nama warna yang diketahui, dan Color mendukung pengonversi jenis untuk sintaks atribut.

Markup XAML Menghasilkan aliran simpul XAML
<Party simpul Namespace untuk Party
xmlns="PartyXamlNamespace"> simpul StartObject untuk Party
<Party.Favors> simpul StartMember untuk Party.Favors
simpul StartObject untuk FavorCollection implisit
StartMember node untuk properti item FavorCollection implisit.
<Balloon simpul StartObject untuk Balloon
Color="Red" simpul StartMember untuk Color

simpul Value untuk string nilai atribut "Red"

EndMember untuk Color
HasHelium="True" simpul StartMember untuk HasHelium

simpul Value untuk string nilai atribut "True"

EndMember untuk HasHelium
> EndObject untuk Balloon
<NoiseMaker>Loudest</NoiseMaker> simpul StartObject untuk NoiseMaker

simpul StartMember untuk _Initialization

simpul Value untuk string nilai inisialisasi "Loudest"

simpul EndMember untuk _Initialization

EndObject untuk NoiseMaker
EndMember node untuk properti item FavorCollection implisit.
simpul EndObject untuk FavorCollection implisit
</Party.Favors> EndMember untuk Favors
</Party> EndObject untuk Party

Dalam aliran simpul XAML, Anda dapat mengandalkan perilaku berikut:

  • Jika simpul Namespace ada, simpul ditambahkan ke aliran segera sebelum StartObject yang mendeklarasikan namespace XAML dengan xmlns. Lihat tabel sebelumnya dengan XAML dan contoh aliran simpul lagi. Perhatikan bagaimana simpul StartObject dan Namespace tampaknya ditransposisikan versus posisi deklarasi mereka dalam markup teks. Ini adalah perwakilan dari perilaku di mana node namespace selalu muncul di depan node yang mereka terapkan di aliran simpul. Tujuan dari desain ini adalah bahwa informasi namespace sangat penting bagi penulis objek dan harus diketahui sebelum penulis objek mencoba melakukan pemetaan jenis atau memproses objek. Menempatkan informasi namespace XAML di depan cakupan aplikasinya dalam aliran membuatnya lebih mudah untuk selalu memproses aliran simpul dalam urutan yang disajikan.

  • Karena pertimbangan di atas, itu adalah satu atau beberapa simpul Namespace yang Anda baca terlebih dahulu dalam sebagian besar kasus markup dunia nyata saat melintasi simpul dari awal, bukan StartObject akar.

  • Simpul StartObject dapat diikuti dengan StartMember, Value, atau EndObjectlangsung . Ini tidak pernah diikuti segera oleh StartObjectlain .

  • StartMember dapat diikuti oleh StartObject, Value, atau EndMemberlangsung . Ini dapat diikuti oleh GetObject, untuk anggota di mana nilai seharusnya berasal dari nilai objek induk yang ada daripada StartObject yang akan membuat instans nilai baru. Ini juga dapat diikuti oleh simpul Namespace, yang berlaku untuk StartObjectmendatang. Ini tidak pernah diikuti segera oleh StartMemberlain .

  • Simpul Value mewakili nilai itu sendiri; tidak ada "EndValue". Ini hanya dapat diikuti oleh EndMember.

    • Teks inisialisasi XAML objek seperti yang mungkin digunakan oleh konstruksi tidak menghasilkan struktur Object-Value. Sebagai gantinya, simpul anggota khusus untuk anggota bernama _Initialization dibuat. dan simpul anggota tersebut berisi string nilai inisialisasi. Jika ada, _Initialization selalu menjadi StartMemberpertama. _Initialization mungkin memenuhi syarat dalam beberapa representasi layanan XAML dengan namescope XAML bahasa XAML, untuk mengklarifikasi bahwa _Initialization bukan properti yang ditentukan dalam jenis pencadangan.

    • Kombinasi Member-Value mewakili pengaturan atribut nilai. Mungkin pada akhirnya ada pengonversi nilai yang terlibat dalam pemrosesan nilai ini, dan nilainya adalah string biasa. Namun, itu tidak dievaluasi sampai penulis objek XAML memproses aliran simpul ini. Penulis objek XAML memiliki konteks skema XAML yang diperlukan, pemetaan sistem jenis, dan dukungan lain yang diperlukan untuk konversi nilai.

  • Simpul EndMember dapat diikuti oleh simpul StartMember untuk anggota berikutnya, atau oleh simpul EndObject untuk pemilik anggota.

  • Simpul EndObject dapat diikuti oleh simpul EndMember. Ini juga dapat diikuti oleh simpul StartObject untuk kasus di mana objek adalah serekan dalam item koleksi. Atau dapat diikuti oleh simpul Namespace, yang berlaku untuk StartObjectmendatang.

    • Untuk kasus unik menutup seluruh aliran simpul, EndObject akar tidak diikuti oleh apa pun; pembaca sekarang merupakan akhir file, dan Read mengembalikan false.

Pengonversi Nilai dan Aliran Simpul XAML

Pengonversi nilai adalah istilah umum untuk ekstensi markup, pengonversi jenis (termasuk serializer nilai) atau kelas khusus lain yang dilaporkan sebagai pengonversi nilai melalui sistem jenis XAML. Dalam aliran simpul XAML, penggunaan pengonversi jenis dan penggunaan ekstensi markup memiliki representasi yang sangat berbeda.

Ketik Pengonversi di Aliran Simpul XAML

Set atribut yang akhirnya menghasilkan penggunaan pengonversi jenis dilaporkan dalam aliran simpul XAML sebagai nilai anggota. Aliran simpul XAML tidak mencoba menghasilkan objek instans pengonversi jenis dan meneruskan nilai ke objek tersebut. Menggunakan implementasi konversi pengonversi jenis memerlukan pemanggilan konteks skema XAML dan menggunakannya untuk pemetaan jenis. Bahkan menentukan kelas pengonversi jenis mana yang harus digunakan untuk memproses nilai memerlukan konteks skema XAML secara tidak langsung. Saat Anda menggunakan konteks skema XAML default, informasi tersebut tersedia dari sistem jenis XAML. Jika Anda memerlukan informasi kelas pengonversi jenis di tingkat aliran simpul XAML sebelum koneksi ke penulis XAML, Anda dapat memperolehnya dari informasi XamlMember anggota yang diatur. Tetapi jika tidak, jenis input pengonversi harus dipertahankan dalam aliran simpul XAML sebagai nilai biasa sampai sisa operasi yang memerlukan sistem pemetaan jenis dan konteks skema XAML dilakukan, misalnya pembuatan objek oleh penulis objek XAML.

Misalnya, pertimbangkan kerangka definisi kelas berikut dan penggunaan XAML untuk itu:

public class BoardSizeConverter : TypeConverter {
  //converts from string to an int[2] by splitting on an "x" char
}
public class GameBoard {
  [TypeConverter(typeof(BoardSizeConverter))]
  public int[] BoardSize; //2x2 array, initialization not shown
}

<GameBoard BoardSize="8x8"/>

Representasi teks dari aliran simpul XAML untuk penggunaan ini dapat dinyatakan sebagai berikut:

StartObject dengan XamlType mewakili GameBoard

StartMember dengan XamlMember mewakili BoardSize

simpul Value, dengan string teks "8x8"

EndMember cocok dengan BoardSize

EndObject cocok dengan GameBoard

Perhatikan bahwa tidak ada instans pengonversi jenis dalam aliran simpul ini. Tetapi Anda bisa mendapatkan informasi pengonversi jenis dengan memanggil XamlMember.TypeConverter di XamlMember untuk BoardSize. Jika Anda memiliki konteks skema XAML yang valid, Anda juga dapat memanggil metode pengonversi dengan mendapatkan instans dari ConverterInstance.

Ekstensi Markup di Aliran Simpul XAML

Penggunaan ekstensi markup dilaporkan dalam aliran simpul XAML sebagai simpul objek dalam anggota, di mana objek mewakili instans ekstensi markup. Dengan demikian, penggunaan ekstensi markup disajikan lebih eksplisit dalam representasi aliran simpul daripada penggunaan pengonversi jenis, dan membawa lebih banyak informasi. XamlMember informasi tidak dapat memberi tahu Anda apa pun tentang ekstensi markup, karena penggunaannya bersifat situasional dan bervariasi dalam setiap kemungkinan kasus markup; ini tidak didedikasikan dan implisit per jenis atau anggota seperti halnya dengan pengonversi jenis.

Representasi aliran simpul ekstensi markup sebagai simpul objek adalah kasusnya bahkan jika penggunaan ekstensi markup dibuat dalam formulir atribut dalam markup teks XAML (yang sering terjadi). Penggunaan ekstensi markup yang menggunakan formulir elemen objek eksplisit diperlakukan dengan cara yang sama.

Dalam simpul objek ekstensi markup, mungkin ada anggota ekstensi markup tersebut. Representasi aliran simpul XAML mempertahankan penggunaan ekstensi markup tersebut, baik itu penggunaan parameter posisional atau penggunaan dengan parameter bernama eksplisit.

Untuk penggunaan parameter posisi, aliran simpul XAML berisi properti yang ditentukan bahasa XAML _PositionalParameters yang merekam penggunaan. Properti ini adalah List<T> generik dengan batasan Object. Batasannya adalah objek dan bukan string karena mungkin penggunaan parameter posisional dapat berisi penggunaan ekstensi markup berlapis di dalamnya. Untuk mengakses parameter posisi dari penggunaan, Anda dapat melakukan iterasi melalui daftar dan menggunakan pengindeks untuk nilai daftar individual.

Untuk penggunaan parameter bernama, setiap parameter bernama diwakili sebagai node anggota dari nama tersebut di aliran simpul. Nilai anggota belum tentu string, karena mungkin ada penggunaan ekstensi markup berlapis.

ProvideValue dari ekstensi markup belum dipanggil. Namun, ini dipanggil jika Anda menghubungkan pembaca XAML dan penulis XAML sehingga WriteEndObject dipanggil pada simpul ekstensi markup saat Anda memeriksanya di aliran simpul. Untuk alasan ini, Anda umumnya memerlukan konteks skema XAML yang sama yang tersedia seperti yang akan digunakan untuk membentuk grafik objek pada jalur beban. Jika tidak, ProvideValue dari ekstensi markup apa pun dapat melemparkan pengecualian di sini, karena tidak memiliki layanan yang diharapkan yang tersedia.

Anggota Language-Defined XAML dan XML di Aliran Simpul XAML

Anggota tertentu diperkenalkan ke aliran simpul XAML karena interpretasi dan konvensi pembaca XAML, alih-alih melalui pencarian atau konstruksi XamlMember eksplisit. Seringkali, anggota ini adalah arahan XAML. Dalam beberapa kasus, ini adalah tindakan membaca XAML yang memperkenalkan arahan ke dalam aliran simpul XAML. Dengan kata lain, teks XAML input asli tidak secara eksplisit menentukan arahan anggota, tetapi pembaca XAML menyisipkan arahan untuk memenuhi konvensi XAML struktural dan melaporkan informasi dalam aliran simpul XAML sebelum informasi tersebut hilang.

Daftar berikut mencatat semua kasus di mana pembaca XAML diharapkan untuk memperkenalkan simpul anggota XAML direktif, dan bagaimana simpul anggota tersebut diidentifikasi dalam implementasi Layanan XAML .NET.

  • Teks inisialisasi untuk simpul objek: Nama simpul anggota ini _Initialization, ini mewakili arahan XAML, dan didefinisikan dalam namespace XAML bahasa XAML. Anda bisa mendapatkan entitas statis untuk itu dari Initialization.

  • Parameter posisi untuk ekstensi markup: Nama simpul anggota ini _PositionalParameters, dan ditentukan dalam namespace XAML bahasa XAML. Ini selalu berisi daftar generik objek, yang masing-masing adalah parameter posisi yang telah dipisahkan sebelumnya dengan memisahkan karakter pemisah , seperti yang disediakan dalam XAML input. Anda bisa mendapatkan entitas statis untuk arahan parameter posisi dari PositionalParameters.

  • konten Tidak Diketahui: Nama simpul anggota ini _UnknownContent. Secara ketat, ini adalah XamlDirective, dan didefinisikan dalam namespace XAML bahasa XAML. Direktif ini digunakan sebagai sentinel untuk kasus di mana elemen objek XAML berisi konten di XAML sumber tetapi tidak ada properti konten yang dapat ditentukan di bawah konteks skema XAML yang saat ini tersedia. Anda dapat mendeteksi kasus ini dalam aliran simpul XAML dengan memeriksa anggota bernama _UnknownContent. Jika tidak ada tindakan lain yang diambil dalam aliran simpul XAML jalur beban, XamlObjectWriter default melemparkan upaya WriteEndObject ketika menemukan anggota _UnknownContent pada objek apa pun. XamlXmlWriter default tidak melemparkan, dan memperlakukan anggota sebagai implisit. Anda bisa mendapatkan entitas statis untuk _UnknownContent dari UnknownContent.

  • Koleksi properti koleksi: Meskipun jenis CLR cadangan dari kelas koleksi yang digunakan untuk XAML biasanya memiliki properti bernama khusus yang menyimpan item koleksi, properti tersebut tidak diketahui oleh sistem jenis XAML sebelum resolusi jenis backing. Sebagai gantinya, aliran simpul XAML memperkenalkan tempat penampung Items sebagai anggota jenis XAML koleksi. Dalam implementasi Layanan XAML .NET, nama direktif atau anggota ini dalam aliran simpul _Items. Konstanta untuk arahan ini dapat diperoleh dari Items.

    Perhatikan bahwa aliran simpul XAML mungkin berisi properti Item dengan item yang ternyata tidak dapat diurai berdasarkan resolusi jenis backing dan konteks skema XAML. Misalnya

  • anggota yang ditentukan XML: anggota xml:base, xml:lang, dan xml:space yang ditentukan XML dilaporkan sebagai arahan XAML bernama base, lang, dan space dalam implementasi Layanan XAML .NET. Namespace layanan untuk ini adalah namespace XML http://www.w3.org/XML/1998/namespace. Konstanta untuk masing-masing dapat diperoleh dari XamlLanguage.

Urutan Simpul

Dalam beberapa kasus, XamlXmlReader mengubah urutan simpul XAML dalam aliran simpul XAML, versus urutan simpul muncul jika dilihat dalam markup atau jika diproses sebagai XML. Ini dilakukan untuk mengurutkan simpul singgahan sehingga XamlObjectWriter dapat memproses aliran simpul dengan cara khusus ke depan. Dalam Layanan XAML .NET, pembaca XAML menyusun ulang simpul daripada meninggalkan tugas ini ke penulis XAML, sebagai pengoptimalan performa untuk konsumen penulis objek XAML dari aliran simpul.

Arahan tertentu dimaksudkan khusus untuk memberikan informasi lebih lanjut untuk pembuatan objek dari elemen objek. Arahan ini adalah: Initialization, PositionalParameters, TypeArguments, FactoryMethod, Arguments. Pembaca XAML Layanan XAML .NET mencoba untuk menempatkan arahan ini sebagai anggota pertama dalam aliran simpul setelah StartObjectobjek , karena alasan yang dijelaskan di bagian berikutnya.

Perilaku XamlObjectWriter dan Urutan Simpul

StartObject ke XamlObjectWriter belum tentu merupakan sinyal kepada penulis objek XAML untuk segera membangun instans objek. XAML mencakup beberapa fitur bahasa yang memungkinkan untuk menginisialisasi objek dengan input tambahan, dan untuk tidak sepenuhnya mengandalkan pemanggilan konstruktor tanpa parameter untuk menghasilkan objek awal, dan hanya kemudian mengatur properti. Fitur-fitur ini meliputi: XamlDeferLoadAttribute; teks inisialisasi; x:TypeArguments; parameter posisi ekstensi markup; metode pabrik dan terkait x:Argumen simpul (XAML 2009). Masing-masing kasus ini menunda konstruksi objek aktual, dan karena aliran simpul disusun ulang, penulis objek XAML dapat mengandalkan perilaku benar-benar membangun instans setiap kali anggota mulai ditemui yang tidak secara khusus direktif konstruksi untuk jenis objek tersebut.

Dapatkan Objek

GetObject mewakili simpul XAML di mana daripada membuat objek baru, penulis objek XAML seharusnya mendapatkan nilai properti yang berisi objek. Kasus umum di mana simpul GetObject ditemui dalam aliran simpul XAML adalah untuk objek koleksi atau objek kamus, ketika properti yang berisi sengaja baca-saja dalam model objek jenis backing. Dalam skenario ini, koleksi atau kamus sering dibuat dan diinisialisasi (biasanya kosong) oleh logika inisialisasi jenis pemilik.

Lihat juga

  • Terakhir diperbarui pada