Col senno di poi, basare XAML su XML è un errore o un buon approccio?


16

XAML è essenzialmente un sottoinsieme di XML. Uno dei principali vantaggi di basare XAML su XML è che può essere analizzato con strumenti esistenti. E può, in larga misura, sebbene i valori degli attributi (sintatticamente non banali) rimarranno in forma di testo e richiederanno ulteriori analisi.

Esistono due alternative principali alla descrizione di una GUI in un linguaggio derivato da XML. Uno è fare ciò che ha fatto WinForms e descriverlo in codice reale. Ci sono numerosi problemi con questo, sebbene non sia completamente privo di vantaggi (una domanda per confrontare XAML con questo approccio ). L'altra alternativa principale è progettare una sintassi completamente nuova, appositamente studiata per l'attività da svolgere. Questo è generalmente noto come linguaggio specifico del dominio .

Quindi, col senno di poi, e come lezione per le generazioni future, è stata una buona idea basare XAML su XML o sarebbe stato meglio come linguaggio specifico del dominio progettato su misura? Se stessimo progettando un framework UI ancora migliore, dovremmo scegliere XML o un DSL personalizzato?

Dal momento che è molto più facile pensare positivamente allo status quo, in particolare a quello che è abbastanza apprezzato dalla comunità, fornirò alcuni motivi per cui costruire su XML potrebbe essere considerato un errore.

Basare un linguaggio su XML ha una cosa in gioco: è molto più facile analizzarlo (il parser principale è già disponibile), richiede molto, molto meno lavoro di progettazione e anche parser alternativi sono molto più facili da scrivere per sviluppatori di terze parti.

Ma la lingua risultante può essere insoddisfacente in vari modi. È piuttosto prolisso. Se cambi il tipo di qualcosa, devi cambiarlo nel tag di chiusura. Ha un supporto molto scarso per i commenti; è impossibile commentare un attributo. Esistono limitazioni poste sul contenuto degli attributi da XML. Le estensioni di markup devono essere costruite "in cima" alla sintassi XML, non integrate in modo profondo e gradevole. E, il mio preferito personale, se si imposta qualcosa tramite un attributo, si utilizza una sintassi completamente diversa rispetto a se si imposta esattamente la stessa cosa di una proprietà di contenuto.

Si dice anche che poiché tutti conoscono XML, XAML richiede meno apprendimento. A rigor di termini questo è vero, ma l'apprendimento della sintassi è una piccola parte del tempo impiegato per apprendere un nuovo framework dell'interfaccia utente; sono i concetti del framework che rendono la curva ripida. Inoltre, le idiosincrasie di un linguaggio basato su XML potrebbero effettivamente aggiungere al paniere "esigenze di apprendimento".

Questi svantaggi sono compensati dalla facilità di analisi? Il prossimo fantastico framework dovrebbe continuare la tradizione o investire il tempo necessario per progettare un fantastico DSL che non può essere analizzato dagli strumenti esistenti e la cui sintassi deve essere appresa da tutti?

PS Non tutti confondono XAML e WPF , ma alcuni lo fanno. XAML è una cosa simile a XML. WPF è il framework con supporto per attacchi, temi, accelerazione hardware e molte altre cose interessanti.


3
Sì, può essere analizzato da un parser XML, ma non in modo significativo / completo. Ad esempio, utilizza gli attributi di stringa per definire origini dati e mappature delle proprietà.
Konrad Rudolph,

5
Cosa proponi in alternativa? Qualsiasi discussione sull'idoneità di una particolare tecnologia dovrebbe riguardare tecnologie di sostituzione adeguate.
Robert Harvey,

2
XAML non è senza controparti, lo sai. XUL, Glade e QML sono tutti basati sulla stessa idea. Penso che tu stia scegliendo XAML ingiustamente.
user16764

3
Penso che il più grande vantaggio di XAML non sia che può essere analizzato dai parser XML. Piuttosto è che XAML è simile a XML e la maggior parte degli sviluppatori sa già come lavorare con XML, quindi la curva di apprendimento è molto meno ripida.
Juozas Kontvainis,

2
@JuozasKontvainis Se per "lavoro" intendi "analizzalo nei loro strumenti", allora sì. Se intendi "scrivere un'interfaccia utente da essa descritta", la sintassi familiare potrebbe sembrare utile, ma realisticamente, devi ancora imparare cosa mettere all'interno degli attributi (perché non è XML), e questo è di gran lunga il più difficile cosa, nella mia esperienza personale. Imparare una nuova sintassi, specialmente se è semplice e ben progettata, è banale, secondo me.
Roman Starkov,

Risposte:


4

L'unico motivo convincente per utilizzare XML è stabilire uno standard di dati aperto. XAML è lo stesso linguaggio di visualizzazione utilizzato in Silverlight e WPF; qualsiasi fornitore può utilizzare lo stesso standard di markup per creare una definizione di visualizzazione per la propria piattaforma e può essere riutilizzato in Silverlight o WPF.

Nel settore aerospaziale disponiamo di sale di controllo che, grazie ai progressi della tecnologia informatica, sono ora ragionevolmente flessibili. In passato, tutto l'hardware era personalizzato, unico e molto costoso; oggi è tutto gestito con PC economici, comunemente disponibili e pronti all'uso. Ciò riduce notevolmente il blocco del fornitore. Tuttavia, i widget di visualizzazione vengono comunque scritti utilizzando ActiveX, poiché è così che è sempre stato fatto.

ActiveX richiede l'accesso a strumenti Microsoft obsoleti. Quindi l'Air Force e l' Inter-Range Instrumentation Group stanno elaborando un Data Markup Language Language, basato su XML. Ciò consentirà ai professionisti di progettare display utilizzando il markup XML, nell'editor di loro scelta. Suona familiare?

Nessuno sostiene che XML non sia privo di difetti. Ma è la cosa migliore disponibile per ciò per cui è stato progettato, fino a quando non arriva qualcosa di meglio.

Vedi anche
Perché XML non fa schifo


3
Concorderesti che lo stesso ragionamento si applica ugualmente bene a cose come, diciamo, descrizioni grammaticali YACC, TeX, regex, Verilog e forse anche LISP? Abbiamo creato una sintassi speciale per ognuna di queste. Potrebbero beneficiare nello stesso modo in cui elenchi nel primo paragrafo. Quindi non ne consegue che usare XML per loro sarebbe la cosa giusta, perché XML soddisfa gli obiettivi che hai menzionato?
Roman Starkov

Solo XML è ampiamente riconosciuto come un meta-standard di dati universale, dal quale è possibile creare tutti i singoli standard di dati desiderati. Per evitare di confondere le acque, ho rimosso il primo paragrafo.
Robert Harvey,

Le espressioni S non sono mai state utilizzate come standard di metadati, forse perché a nessuno piacciono tutte quelle sciocche parentesi. L'ubiquità è il fattore convincente qui; tutte quelle sintassi alternative che hai citato possono essere rappresentate in XML, se sei così incline.
Robert Harvey,

2
Tutti possono essere rappresentati anche in YAML e JSON (e viceversa).
Timwi

2
Un enorme problema che vedo in tutto questo argomento è che XAML non è realmente un dato. Certo, potrebbe essere trattato come un semplice oggetto grafico, ma questo tipo di pensiero è probabilmente il motivo per cui a molte persone non piace e perché ha una tale curva di apprendimento. "hey lascia andare fare un oggetto grafico, ehm, intendo un'interfaccia utente". Non ho idea di come possa essere migliorato, ma sono sicuro che potrebbe essere.
Earlz,

2

Le tue obiezioni all'XML non hanno nulla a che fare con l'uso come linguaggio di descrizione della GUI; sono tutte lamentele sull'uso della sintassi XML che si applicano ugualmente a qualsiasi forma di XML.

Quindi sembra che non ti piaccia XML.

Hai ragione, potrebbe non essere la scelta ottimale per la modifica a mano, ma per un linguaggio di descrizione della GUI farei alcuni contro-argomenti:

  1. (IMHO,) Le GUI sono grafiche e devono essere strutturate graficamente. Il formato del file non è poi così importante, perché non dovresti davvero modificarlo a mano. (Il testo è utile per il controllo del codice sorgente, ma la verbosità non è un problema.)

  2. Oltre alla disponibilità del parser, XML è anche facile da convalidare: puoi scrivere uno schema DTD o XML e quindi utilizzare strumenti generici per dirti se il tuo file è legale. Questo sarà molto utile per un linguaggio di descrizione della GUI. Fare lo stesso in JSON o YAML non è così semplice.

  3. Se sei davvero scontento di scrivere direttamente XAML, non c'è nulla che ti impedisca di sviluppare un nuovo formato e poi di compilarlo in XAML. Ad esempio, potresti creare una mappatura semplice da JSON a XAML, in modo da poter avere la sintassi più leggera di JSON (e la possibilità di commentare gli attributi) e quindi generare XAML quando crei la tua app. Le persone raramente scrivono più direttamente l'HTML, ma l'HTML è ancora un ottimo formato.


1
Mi piace XML; Non mi piace scriverlo a mano. 1. Sì, dovrebbero, ma purtroppo la realtà è che Visual Studio non può davvero farlo. 3. Questo è ortogonale alla discussione sul fatto se XAML sia stata, a ben vedere, una cattiva idea. Sì, si potrebbe, ma perché sarebbe necessario se XAML non fosse una cattiva scelta?
Roman Starkov,

1
Il mio punto è che lo stai giudicando interamente in base ai criteri per scriverlo; le tue preoccupazioni devono essere bilanciate rispetto alla convalida e all'interpretazione anche. Un DSL più bello da scrivere sarebbe quasi sicuramente più difficile da analizzare. Ma una fase di compilazione intermedia potrebbe darti il ​​meglio di entrambi i mondi.
benzado,

0

Questa domanda è soggettiva, quindi penso che sia giusto pubblicare una risposta basata sulle mie preferenze personali.

XML è difficile da leggere. Ad esempio, aprire questo collegamento e fare clic su "Esempio" per confrontare XML e YAML fianco a fianco. Quest'ultimo è chiaramente molto più leggibile dall'uomo.

Se vuoi usare XML per descrivere una GUI, allora è meglio essere dannatamente sicuri di fornire strumenti sufficienti in modo che gli umani non debbano guardare all'XML.

Chiaramente XPF ha fallito al riguardo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.