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

Sono uno sviluppatore da 8 anni. Abbiamo usato XSLT principalmente per trasformare XML in HTML. Lo abbiamo anche usato per la trasformazione da XML a XML.

Ma ora abbiamo il sostituto di tutto. L'HTML può essere comodamente creato attraverso linguaggi di programmazione come ASP.Net. XML può essere letto e manipolato in qualsiasi linguaggio standard di alto livello. Poiché la programmazione in XSLT è un po 'complessa, chiunque preferirebbe lavorare sugli ultimi linguaggi di programmazione.

Ora la mia domanda: XSLT sarà una scelta significativa in futuro, non considerando il fatto di mantenere XSLT già sviluppato? Posso raccomandare ai nuovi programmatori di studiare XSLT?

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 in cui la trasformazione può essere modificata senza la necessità di ricompilare l'applicazione.

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

• Alcuni siti Web orientati agli sviluppatori o ai dati potrebbero voler fornire un accesso a XML se si intende utilizzare le pagine del sito Web in modo programmatico². È in qualche modo più bello che usare i parser HTML, specialmente perché il codice HTML può essere modificato in qualsiasi momento.

• XSLT, quando utilizzato nei siti Web, consente una stretta separazione tra HTML e code-behind, che consente di assumere uno sviluppatore per code-behind e un altro sviluppatore per roba HTML / CSS. Vedi il punto 1 nella mia risposta a un'altra domanda .

XSLT sarà una scelta significativa in futuro? Bene, questa non è una scelta significativa oggi, e dubito che l'uso di XSLT aumenterà nel tempo. Ignoro la ragione di ciò, ma a molti sviluppatori non piace XML e odiano XSLT.

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

^{¹ Con questo intendo che 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 è solo 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 a XML.}

XSLT è praticamente morto perché solo pochi appassionati lo usano ancora. Tuttavia, non esiste una vera alternativa. Se ti concentri solo su un singolo caso d'uso, come ad esempio il rendering di pagine HTML da documenti semantici, trovi strumenti migliori. Se cerchi motori di template per la generazione di codice, ci sono ancora strumenti migliori. Lo stesso per la trasformazione dei documenti.

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

Ad ogni modo, puoi imparare XSLT in pochi giorni, forse settimane. Non ti farà male fare un'esperienza di prima mano. Provaci. Vale almeno la pena di conservare questo tipo di modello (trasformazioni basate su regole) nella tua testa per un uso successivo. Questo da solo giustifica l'apprendimento di XSLT.

Hmm, mi chiedo se le API di alto livello che creano HTML dal codice utilizzino qualsiasi XSLT "nascosto" ...

XSLT è ampiamente utilizzato dove lavoro per trasformare XML da un formato sorgente a una varietà di altri. Può anche essere usato per trasformare XML in output non XML. Non ho fatto molto di questo, ma ne ho sentito parlare per indirizzare PDF e PostScript, tra gli altri.

Sì.

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

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

Ci sarà sempre scelta e varietà nei linguaggi di programmazione, e i motivi per cui uno viene scelto in preferenza a un altro sono tanto legati alla familiarità e alla moda quanto a 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 molte persone che hanno superato le barriere di apprendimento iniziali per XSLT e scoprono che si tratta di uno strumento estremamente produttivo per una varietà molto ampia di compiti (probabilmente una varietà più ampia di quanto non sia mai stata progettata per affrontare).

Per molte delle attività per le quali vedo che XSLT viene utilizzato (e le attività che lo uso per me stesso), scrivere codice Java o ASP per fare il lavoro sarebbe uno spreco spaventoso del budget del tuo datore di lavoro. Ma forse no, se sei bravo a scrivere Java e cattivo 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 è abbastanza 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à. Per quanto riguarda questo aspetto, Velocity o GenearateXY sono migliori di XSLT. GenerateXY è ancora un po 'migliore poiché separa l'anteprima e il flusso mentre con Velocity dovresti purtroppo interrompere il rientro dell'anteprima per fornire un flusso leggibile.

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

Infatti

Qualcosa probabilmente sostituirà XSLT un giorno poiché è un po 'macchinoso da imparare e usare. Tuttavia, al momento non esiste un linguaggio di template / trasformazione disponibile che sia flessibile e "puro" nella sua implementazione.

XSL-T può essere utilizzato per diversi scopi:

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

Fondamentalmente, tutti questi sono la stessa cosa, la trasformazione di un file di dati XML in un altro. Ora diamo un'occhiata ad alcuni strumenti diversi che potremmo usare al posto di XSLT.

Se volessimo manipolare il contenuto di dire una pagina XHTML potremmo usare regexp, ma regexp è disordinato per cose strutturali. Brilla per manipolare le stringhe ma non lo 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 un po 'di codice per le parti dinamiche. Un'altra alternativa è quella di rinunciare alla parte del layout e generare qualsiasi cosa, ad esempio un database e l'utilizzo di C # creando l'output desiderato.

Il problema con il primo approccio è che è goffo passare dai dati descrittivi al contenuto reale. Se hai alcuni file di dati contenenti numeri di telefono che vuoi presentare con le intestazioni per ogni lettera, mostra un numero totale di voci ecc. Dovresti avere un po 'di layout nel file di layout e alcuni nel codice che stai generando . Un'altra opzione è quella di utilizzare una qualche forma di griglia Web, trovo che siano piuttosto disordinati e improvvisamente devi imparare come funziona la griglia frigging quando tutto quello che volevi fare era produrre un HTML specifico dato i dati.

Andare totalmente dinamico è certamente un'opzione, ma è anche piuttosto goffo. Anche nel migliore dei casi in cui stai usando 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 i contenuti non strutturati in stile documento ricorsivo come di solito è html.

Con XSLT puoi semplicemente creare un modello per un determinato tag, così come è o nel contesto del suo genitore, quindi viene reso in modo diverso se, ad esempio, è parentetizzato da qualcos'altro.

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

Il più grande fallimento di XSLT è l'incapacità (in qualsiasi implementazione reale) di ridurre al minimo la quantità di documento che deve essere tenuto 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 in questo modo. Se il documento è molto grande, lo sono anche i requisiti di memoria. Tuttavia, molti fogli di stile necessitano chiaramente solo del tag corrente e di pochi altri, ad esempio gli antenati del tag, in qualsiasi momento e quindi potrebbero essere elaborati con memoria minima e streaming efficiente.

Sì, in termini di una lingua è strano, ma è solo una barriera all'ingresso. Se conosci XSLT, è spesso più facile delle alternative, ma se avrai documenti di grandi dimensioni (o molti documenti che vengono elaborati contemporaneamente), l'impatto sulla memoria di XSLT spesso impone altre alternative più dispendiose in termini di tempo.

È un dato di fatto, penso che sia più efficiente utilizzare XSL di un'altra lingua per presentare i dati. Ad esempio puoi presentare un XML come PDF usando XSL-FO e puoi controllare ogni centimetro, 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 suo 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 sia più stabile e meno complesso).

Lavoro per un'azienda di integrazione dei dati e usiamo XSLT con i nostri strumenti proprietari come un'ottima soluzione che coinvolge da XML a HTML / XML / Ascii.