Quali sono i vantaggi reali di linguaggi dichiarativi-UI, come XAML e QML?

Question

Al momento sto valutando QtQuick ( Qt Interfaccia utente Creation Kit) che sarà rilasciato come parte di Qt 4.7. QML è il linguaggio dichiarativo basato su JavaScript dietro QtQuick.

Sembra essere un concetto molto potente, ma mi chiedo se qualcuno che è fatto largo uso di altri, più maturo linguaggi dichiarativi-UI come XAML in WPF o Silverlight possono dare alcuna comprensione dei benefici reali che si possono ottenere da questo stile di programmazione. Diversi vantaggi sono spesso citati:

• Velocità di sviluppo
• separazione forze tra la presentazione e la logica
• Una migliore integrazione tra i programmatori e designer
modifiche
• UI non richiedono ricompilazione

Inoltre, ci sono aspetti negativi? Alcuni potenziali aree di preoccupazione in mente:

• La velocità di esecuzione
• Utilizzo della memoria
• complessità

Ci sono altre considerazioni che dovrebbero essere presi in considerazione?

Answer 1

(Aggiornato)

L'equivoco con XAML è che non è compilato. Si è infatti compilato fino a BAML un binario pre-token XAML. A quanto pare c'era una versione compilata di IL XAML anche chiamato CAML. Il PO mi ha segnalato questo buon articolo spiegando cosa XAML / BAML e CAML sono.

In ogni caso, alla domanda perché usarlo:

XAML è semplicemente un formato di serializzazione di oggetti C # che è particolarmente adatto per descrivere strutture degli oggetti gerarchiche, come trovato in WPF GUI.

Cosa WPF ti aiuta a fare è meno noioso di scrittura di codice C # in questo modo:

var grid = new Grid();
grid.Content.add(new TextBlock() {Text = "Hello"});
grid.Content.add(new TextBlock() {Text = "World"});

e proprio esprimerlo in un modo più leggibile in questo modo:

<Grid>
  <TextBlock Text="Hello">
  <TextBlock Text="World">
</Grid>

Da oggetto WPF nidificazione (mettendo roba dentro altri oggetti) può ottenere molto profonda, WPF rende molto più facile da leggere rispetto al codice C # risultante.

Per quanto riguarda la separazione degli interessi: XAML aiuta anche in questo caso dal momento che non consentono solo di esprimere gli oggetti e le loro relazioni / proprietà, piuttosto che la logica. Che le forze di separare la logica di layout dell'interfaccia utente. Il pattern MVVM è molto adatto per questo compito e consente testabilità eay ed intercambiabili Vista.

complessità in XAML può essere facilmente respinto perché lo stesso codice in C # si ottiene facilmente più complessa di quanto il markup XAML.

non posso dare alcuna visione QtQuick però. Siamo spiacenti

Answer 2

QtQuick è estendibile tramite plugin C ++, in realtà ciò che la Qt ragazzi recomment è che si fa l'interfaccia utente, animazioni, transizioni ecc in QtQuick / QML mentre tutti la logica di business è in C ++ / Qt. Quindi, in questo modo si ottiene il meglio dei due mondi, è possibile eseguire il debug del codice C ++, come si fa di solito, mentre allo stesso tempo facendo interfacce utente diventa facile ed estremamente facile.

Anche un altro think importante circa QtQuick / XAML è che sono con accelerazione hardware, così per esempio si può ottenere abbastanza bene fps senza alcuno sforzo. Quindi non sono lenti a tutti per quello che si prefiggono di realizzare.

Si risparmia tempo, così tanto tempo. Ho fatto una UI con il codice in 3 giorni, ha fatto lo stesso in QML in 2 ore.

Answer 3

Il punto di codificazione dichiarativa, cioè WPF o QtQuick è quello di realizzare una separazione tra l'autore e presumibilmente l'artista che implementa gli aspetti visivi dell'applicazione. Per quanto riguarda WPF, trovo che il debug viene ad essere un po 'più difficile. Mentre parliamo, sto compilare l'ultimissimo QT per guardare QtQuick. (Ci vuole molto tempo e non ho tempo di guardare StackOverflow :-)) Quindi, non ho un parere su quella ancora.

Answer 4

QML / XAML sono:

• Grande per modello MVVM
• Hardware accelerato (QML con l'utilizzo di OpenGL per Windows, Mac, Linux e sistemi operativi del telefono ... XAML con l'utilizzo di DirectX per Windows e la sua versione del telefono)
• Più vicino agli artisti
• È possibile creare un grande e piacevole interfaccia utente utilizzando XAML / QML
• implementazione UI facile
• Nizza animazione è possibile
• In XAML, di solito è possibile creare una versione di Silverlight della vostra applicazione solo con un po modifiche
• In XAML c'è alcune grandi caratteristiche come modello, Trigger (DataTrigger, Grilletto, EventTrigger), Binding (in ogni parte e anche entrambi i lati insieme), di risorse, Comandi, DependencyProperty e soggette a denuncia Proprietà.

Ma per favore nota in XAML: (io sono un programmatore XAML, quindi non ho punti di QML)

• XAML debug non è possibile
• Per qualsiasi cambiamento di XAML, tutti i programmi deve essere ricompilazione

• Essere più attenti per le prestazioni. Per esempio, se si utilizza molto numerose RoutedCommands in XAML, l'applicazione sarà inutilizzabile!

• In XAML, alcune funzionalità non funziona come previsto. Non v'è, purtroppo, alcuni trucchi. (Dovrebbe essere chiaro ... dovrebbe funziona come previsto ... non è vero?)

• Fare attenzione per alcuni spazi dei nomi simili come BitmapEffect ed effetto. C'è diverse caratteristiche e costi. (Ad esempio BitmapEffect ha alcuni effetti con il software di rendering e effetti ha qualche effetto con l'hardware rendering)

• Nel mondo reale, gli artisti non poteva usare WPF come Flash (almeno con buone prestazioni).

• Alcune caratteristiche opere in luoghi speciali. Per esempio DataTrigger funziona nella modifica Stile non nella sezione Risorse.

• Ci sono alcune debolezze in XAML. Alcuni esempi: non c'è alcuna animazione sequenziale ... non si può fare alcun calcolo in XAML (! È necessario scrivere un convertitore in C #, anche per un lavoro liiiittle Javasript è un ottimo sostituto in QML) ... alcuni attributi sono duplicati. per esempio. x: Nome e Nome ... Controllo Vista dal ViewModel non è chiaro. per esempio. chiusura Vista dal ViewModel (avete bisogno di qualche CodeBehind)

• tooooooo errori molto run-time. Se si utilizzano alcuni tag in brutto posto si noterà voi per errore di sintassi, ma molti di errori si verifica solo nella fase di esecuzione. per esempio. se scelgo come destinazione proprietà Background (invece di Background.Color) per ColorAnimation, esso verrà compilato con successo, ma nella gestione di animazione ... BUMP ... errore di runtime !!! in tal caso, su Expression Blend, l'applicazione va in crash !!!