Ci sono dei buoni motivi per usare, imparare o raccomandare XSLT? [chiuso]

Ci sono alcuni casi importanti in cui XSLT può essere una buona scelta:

• Il software ETL ( Estrai, Trasforma, Carica ) può in alcuni casi utilizzare XSLT. Ad esempio, può essere una buona scelta quando sia i dati estratti che i dati da caricare sono in un formato XML e dove la trasformazione può essere cambiata senza la necessità di ricompilare l'applicazione.

• Alcune applicazioni che memorizzano i dati in XML utilizzano XSLT per presentare questi dati in un formato leggibile dall'uomo¹. Ad esempio, Windows Live Messenger memorizza la traccia di messaggi come XML, ma quando apri la cronologia in WLM, ti mostra una bella tabella che di fatto è costruita in HTML tramite XSLT.

• Alcuni siti web orientati agli sviluppatori o basati su dati potrebbero voler fornire un accesso a XML se l'intento è di utilizzare le pagine del sito Web a livello di programmazione². È in qualche modo più bello che usare parser HTML, soprattutto perché il codice HTML può essere modificato in qualsiasi momento.

• XSLT, se utilizzato nei siti web, consente una separazione rigorosa tra HTML e code-behind, che consente di assumere uno sviluppatore per code-behind e un altro sviluppatore per materiale HTML / CSS. Vedere il punto 1 in la mia risposta ad un'altra domanda .

XSLT sarà una scelta importante in futuro? Bene, questa non è una scelta significativa oggi, e dubito che l'uso di XSLT aumenterà nel tempo. Ignoro il motivo, ma a molti sviluppatori non piace XML e odio XSLT.

Puoi consigliare nuovi programmatori per studiare XSLT? Sicuro! Non solo XSLT può essere utilizzato in alcune circostanze quando altri approcci sarebbero più difficili, ma anche XSLT ha un approccio molto specifico che altri linguaggi non hanno.

^{¹ Con questo intendo che l'XML non è realmente leggibile dall'uomo: se chiedi a una persona che non lavora nell'IT di leggere XML, sarà inorridito.
² So che ci sono servizi web. Ma a volte è più semplice e più semplice, su ogni pagina, costruire un oggetto dinamico, quindi serializzarlo in XML, quindi trasformarlo in HTML tramite XSLT o consentire al bot di accedere direttamente all'XML.}

XSLT è praticamente morto perché solo pochi entusiasti lo usano ancora. Tuttavia, non esiste una vera alternativa per questo. Se ci si concentra solo su un caso a uso singolo, come ad esempio il rendering di pagine HTML da documenti semantici, si trovano strumenti migliori. Se cerchi motori di template di generazione del codice, di nuovo ci sono strumenti migliori. Lo stesso vale per la trasformazione del documento.

Ma se cerchi uno strumento che supporti tutti questi casi d'uso piuttosto bene su tutte le piattaforme, le scelte diventano molto limitate. Se hai già un documento XML e dovresti trasformarlo in qualcosa per poter utilizzare il tuo strumento, probabilmente stai meglio semplicemente elaborando i tuoi dati con XSLT (o XQuery).

In ogni caso, puoi imparare XSLT in pochi giorni, forse settimane. Non ti farà male fare un'esperienza di prima mano. Dagli un colpo. Vale almeno la pena di conservare questo tipo di schema (trasformazioni basate su regole) nella tua testa per un uso futuro. Questo da solo giustifica l'apprendimento dell'XSLT.

Hmm Mi chiedo se le API di alto livello che creano codice HTML dal codice utilizzino qualsiasi XSLT "sotto il cofano" ...

XSLT è usato estesamente dove lavoro per trasformare XML da un formato sorgente a vari altri. Può anche essere usato per trasformare XML in output non XML. Non ho fatto molto di questo, ma ho sentito che è stato fatto per indirizzare PDF e PostScript, tra gli altri.

Sì.

Facciamo un buon esempio: rapporti sui test unitari in continua integrazione. La maggior parte dei test unitari e dei programmi di copertura del codice emettono semplicemente tonnellate di XML illeggibile. Ma con alcuni semplici XSLT, puoi creare una dozzina di rapporti utili dagli stessi dati. E altre persone possono riutilizzare tali rapporti.

Ora puoi scrivere questi in qualsiasi lingua lo strumento CI usi per i plugin, ma se non conosci quella lingua (ad esempio, sei uno sviluppatore .NET, usando Jenkins), non c'è bisogno di impararlo. Basta usare un plug-in che applica già un XSLT a un file XML e scrivere alcuni XSLT utili.

Ci sarà sempre scelta e varietà nei linguaggi di programmazione, e le ragioni per le quali uno viene scelto preferibilmente rispetto ad un altro hanno a che fare tanto con la familiarità e la moda quanto con criteri oggettivi come funzionalità, produttività e prestazioni. Nessuno può prevedere la moda, quindi nessuno può prevedere le tendenze future nei linguaggi di programmazione. Ma ci sono un sacco di persone che hanno superato le barriere di apprendimento iniziali per XSLT e trovano che sia uno strumento estremamente produttivo per una vasta gamma di compiti (forse una varietà più ampia di quanto non sia mai stato progettato per affrontare).

Per molte delle attività in cui viene utilizzato XSLT (e le attività che uso per me stesso), scrivere codice Java o ASP per fare il lavoro sarebbe uno spaventoso spreco di budget del tuo datore di lavoro. Ma forse no, se sei bravo a scrivere Java e male a scrivere XSLT.

XSLT non è leggibile dall'uomo. Le meta-informazioni (i tag) occupano troppo spazio rispetto alle informazioni reali (testo, richieste xpath). Un buon codice dovrebbe apparire come una documentazione e questo non è il caso di XSLT. È piuttosto un buon formato di persistenza per gli strumenti di mappatura.

Un buon linguaggio di trasformazione dovrebbe consentire di visualizzare in anteprima il risultato della trasformazione e visualizzare contemporaneamente il flusso di trasformazione (IF, ELSE, FOR, WHILE). questo è importante per la manutenibilità. Riguardo questo aspetto Velocity o GenearateXY sono meglio di XSLT. GenerateXY è anche un po 'meglio poiché separa l'anteprima e il flusso mentre con Velocity dovresti sfortunatamente interrompere l'indentazione di anteprima per fornire un flusso leggibile.

L'unico aspetto positivo in XSLT è che si preoccupa della modularità usando e persino abusando degli elementi "xsl: template". Il problema con questo è che è buono per un linguaggio di elaborazione dati (Java, C, ...) ma molto secondario per una lingua di presentazione.

In effetti

Un giorno probabilmente sostituiremo XSLT un giorno, dal momento che è un po 'macchinoso da imparare e usare. Tuttavia, attualmente non esiste un linguaggio di template / trasformazione disponibile afaik che sia flessibile e "puro" nella sua implementazione.

XSL-T può essere usato per diversi scopi:

• Puoi "creare" contenuti in formato HTML da un dato utilizzando un modello
• Puoi convertire da un formato xml a un altro
• Puoi manipolare xml in un altro formato, magari mostrare un sottoinsieme

Fondamentalmente tutte queste sono la stessa cosa, tuttavia, la trasformazione di un file di dati XML in un altro. Ora esaminiamo alcuni strumenti diversi che potremmo utilizzare al posto di XSLT.

Se volessimo manipolare il contenuto di una pagina XHTML potremmo usare regexp, ma regexp è disordinato per elementi strutturali. Brilla per manipolare le stringhe ma non la userei per creare un sommario per qualcosa o presentarlo in un layout diverso.

Il prossimo è ASP.Net. Inseriamo il nostro layout nella nostra pagina asp e inseriamo del codice dietro per le parti dinamiche. Un'altra alternativa è quella di rinunciare alla parte di layout e generare tutto da un database e usando C # creando l'output desiderato.

Il problema con il primo approccio è che è goffo passare da dati descrittivi a contenuti effettivi. Se si dispone di un file di dati contenente numeri di telefono che si desidera presentare con intestazioni per ciascuna lettera, mostrare un numero totale di voci, ecc., Si dovrà avere parte del layout nel file di layout e alcuni nel codice che si sta generando . Un'altra opzione è quella di usare una qualche forma di web-grid, trovo che siano piuttosto disordinati e improvvisamente devi imparare come funziona la griglia frigging quando tutto ciò che volevi fare era produrre un determinato html dato i dati.

L'andare totalmente dinamici è certamente un'opzione ma è anche piuttosto maldestro. Anche nel migliore dei casi in cui utilizzi qualcosa come LINQ dovrai mescolare il codice di programmazione con l'output in un modo piuttosto brutto. Inoltre non esiste un buon modo per gestire correttamente il contenuto in stile documento ricorsivo non strutturato di solito in html.

Con XSLT puoi semplicemente creare un modello per un determinato tag, sia come è, sia nel contesto del suo genitore, quindi è reso in modo diverso se per esempio è parentet da qualcos'altro.

Una risposta piuttosto lunga, ma sì, penso che ci sia un grande valore in un linguaggio descrittivo del template e XSLT è il migliore e più standardizzato che abbiamo ottenuto finora.

Il più grande errore di XSLT è l'impossibilità (in qualsiasi implementazione reale) di ridurre al minimo la quantità del documento che deve essere conservato in memoria alla volta per un'elaborazione efficiente. Invece, l'intero documento viene letto in una qualche forma di rappresentazione DOM e l'elaborazione viene eseguita a tale scopo. Se il documento è molto grande, lo sono anche i requisiti di memoria. Tuttavia, molti fogli di stile hanno chiaramente bisogno solo del tag corrente e di alcuni altri, ad es. gli antenati del tag, in qualsiasi momento e quindi potrebbero essere elaborati con memoria minima e streaming efficiente.

Sì, in termini di linguaggio è strano, ma questa è solo una barriera all'ingresso. Se si conosce XSLT, è spesso più semplice delle alternative - ma se si avranno documenti di grandi dimensioni (o molti documenti elaborati contemporaneamente) l'impatto della memoria di XSLT spesso costringe altre alternative, più dispendiose in termini di tempo.

In effetti, penso che sia più efficiente usare XSL di un'altra lingua per presentare i dati. Ad esempio, puoi presentare un XML come PDF usando XSL-FO e puoi controllare ogni pollice, ma se lavori con RDLC (.NET), ad esempio, vedrai che è molto difficile presentare esattamente quello che vuoi.

Anche l'evoluzione / correzione è abbastanza semplice, poiché in XSL ogni elemento ha il proprio modello. Penso che l'estensione di XSL sia più importante come XSLT e XSL-FO. Ecco perché questo linguaggio sarà ancora usato in futuro (ma spero davvero che sarà più stabile e meno complesso).

Lavoro per un'azienda di Data Integration e utilizziamo XSLT con i nostri strumenti proprietari come un'ottima soluzione che coinvolge XML in HTML / XML / Ascii.