Vale la pena XSLT? [chiuso]

Tempo fa, ho iniziato un progetto in cui ho progettato uno schema XML in stile html in modo che gli autori potessero scrivere il loro contenuto (materiale del corso educativo) in un formato semplificato che poi sarebbe stato trasformato in HTML tramite XSLT. Ci ho giocato (faticato) per un po 'e l'ho portato a un livello molto elementare, ma poi ero troppo infastidito dai limiti che stavo incontrando (che potrebbero essere stati limiti della mia conoscenza) e quando ho letto un blog che mi suggeriva di abbandonare XSLT e scrivi semplicemente il tuo parser XML-to-any nella tua lingua preferita, ci sono saltato sopra con impazienza e ha funzionato brillantemente.

Ci sto ancora lavorando fino ad oggi ( dovrei effettivamente lavorarci adesso, invece di giocare su SO ), e vedo sempre più cose che mi fanno pensare che la decisione di abbandonare XSLT sia stata una buona.

So che XSLT ha il suo posto, in quanto è uno standard accettato, e che se ognuno scrive i propri interpreti, il 90% di loro finirà su TheDailyWTF . Ma dato che si tratta di un linguaggio di stile funzionale invece dello stile procedurale con cui la maggior parte dei programmatori ha familiarità, per qualcuno che si imbarca in un progetto come il mio, consiglieresti di seguire il percorso che ho fatto io, o di mantenerlo con XSLT ?

Vantaggi di XSLT:

• Specifico del dominio per XML, quindi, ad esempio, non è necessario citare XML letterale nell'output.
• Supporta XPath / XQuery, che può essere un bel modo per interrogare i DOM, nello stesso modo in cui le espressioni regolari possono essere un bel modo per interrogare le stringhe.
• Linguaggio funzionale.

Svantaggi di XSLT:

• Può essere oscenamente prolisso: non è necessario citare XML letterale, il che significa effettivamente che è necessario citare il codice. E non in modo carino. Ma poi di nuovo, non è molto peggio del tuo tipico SSI.
• Non fa certe cose che la maggior parte dei programmatori dà per scontate. Ad esempio, la manipolazione delle stringhe può essere un lavoro di routine. Questo può portare a "momenti sfortunati" quando i principianti progettano codice, quindi cercano freneticamente nel web suggerimenti su come implementare funzioni che presumevano sarebbero state lì e non si sono dati il ​​tempo di scrivere.
• Linguaggio funzionale.

Un modo per ottenere un comportamento procedurale, a proposito, è concatenare più trasformazioni insieme. Dopo ogni passaggio hai un nuovo DOM su cui lavorare che riflette i cambiamenti in quel passaggio. Alcuni processori XSL hanno estensioni per farlo in modo efficace in una trasformazione, ma dimentico i dettagli.

Quindi, se il tuo codice è principalmente in output e non c'è molta logica, XSLT può essere un modo molto pulito per esprimerlo. Se c'è molta logica, ma principalmente moduli incorporati in XSLT (seleziona tutti gli elementi che assomigliano a blah e per ognuno emette blah), è probabile che sia un ambiente piuttosto amichevole. Se hai voglia di pensare in modo XML in ogni momento, prova XSLT 2.

Altrimenti, direi che se il tuo linguaggio di programmazione preferito ha una buona implementazione DOM che supporta XPath e ti consente di creare documenti in modo utile, allora ci sono pochi vantaggi nell'usare XSLT. I collegamenti a libxml2 e gdome2 dovrebbero andare bene, e non c'è da vergognarsi nell'attenersi a linguaggi generici che conosci bene.

I parser XML coltivati ​​in casa sono di solito o incompleti (nel qual caso un giorno ti sbloccherai) oppure non molto più piccoli di qualcosa che potresti aver preso dallo scaffale (nel qual caso probabilmente stai perdendo tempo) e danno un numero illimitato di opportunità per introdurre gravi problemi di sicurezza relativi a input dannosi. Non scriverne uno a meno che tu non sappia esattamente cosa guadagni facendolo. Il che non vuol dire che non puoi scrivere un parser per qualcosa di più semplice di XML come formato di input, se non hai bisogno di tutto ciò che offre XML.

Quanta negatività!

Uso XSLT da alcuni anni e lo adoro sinceramente. La cosa fondamentale che devi capire è che non è un linguaggio di programmazione, ma un linguaggio di modellazione (e sotto questo aspetto lo trovo indescrivibilmente superiore ad asp.net / spit).

XML è il formato dati de facto dello sviluppo web oggi, che si tratti di file di configurazione, dati grezzi o rappresentazioni in memoria. XSLT e XPath ti offrono un modo estremamente potente e molto efficiente per trasformare quei dati in qualsiasi formato di output che ti potrebbe piacere, dandoti immediatamente quell'aspetto MVC di separare la presentazione dai dati.

Poi ci sono le capacità di utilità: lavare gli spazi dei nomi, riconoscere definizioni di schemi disparate, unire documenti.

Essa deve essere migliore per affrontare XSLT che sviluppare i propri metodi in-house. Almeno XSLT è uno standard e qualcosa per cui potresti assumere, e se è davvero un problema per il tuo team, la natura stessa ti consentirebbe di mantenere la maggior parte del tuo team a lavorare solo con XML.

Un caso d'uso nel mondo reale: ho appena scritto un'app che gestisce i documenti XML in memoria in tutto il sistema e si trasforma in JSON, HTML o XML come richiesto dall'utente finale. Ho ricevuto una richiesta abbastanza casuale da fornire come dati Excel. Un ex collega aveva fatto qualcosa di simile programmaticamente ma richiedeva un modulo di alcuni file di classe e che il server avesse installato MS Office! Si scopre che Excel ha un XSD: nuove funzionalità con un impatto minimo sul codice di base in 3 ore.

Personalmente penso che sia una delle cose più pulite che ho incontrato nella mia carriera, e credo che tutti i suoi problemi apparenti (debugging, manipolazione delle stringhe, strutture di programmazione) siano dovuti a una comprensione imperfetta dello strumento.

Ovviamente, credo fermamente che ne valga la pena.

Devo ammettere un pregiudizio qui perché insegno XSLT per vivere. Ma potrebbe valere la pena coprire le aree in cui vedo lavorare i miei studenti. Si dividono generalmente in tre gruppi: editoria, banca e web.

Molte delle risposte finora potrebbero essere riassunte come "non va bene per creare siti web" o "non ha niente a che fare con il linguaggio X". Molte persone tecnologiche intraprendono la loro carriera senza esposizione a linguaggi funzionali / dichiarativi. Quando insegno, le persone esperte di Java / VB / C / ecc. Sono quelle che hanno problemi con il linguaggio (le variabili sono variabili nel senso di algebra non programmazione procedurale per esempio). Sono molte le persone che rispondono qui: non sono mai andato d'accordo con Java, ma non mi prenderò la briga di criticare il linguaggio per questo motivo.

In molte circostanze è uno strumento inappropriato per la creazione di siti Web: un linguaggio di programmazione generico potrebbe essere migliore. Spesso ho bisogno di prendere documenti XML molto grandi e presentarli sul web; XSLT lo rende banale. Gli studenti che vedo in questo spazio tendono a elaborare set di dati e a presentarli sul web. XSLT non è certamente l'unico strumento applicabile in questo spazio. Tuttavia, molti di loro usano il DOM per farlo e XSLT è sicuramente meno doloroso.

Gli studenti di banche che vedo usano una scatola DataPower in generale. Questa è un'appliance XML ed è usata per sedersi tra servizi che "parlano" diversi dialetti XML. La trasformazione da un linguaggio XML a un altro è quasi banale in XSLT e il numero di studenti che frequentano i miei corsi su questo argomento è in aumento.

Il gruppo finale di studenti che vedo proviene da un background editoriale (come me). Queste persone tendono ad avere immensi documenti in XML (credetemi, l'editoria come industria sta diventando molto appassionata di XML - l'editoria tecnica esiste da anni e la pubblicazione commerciale ci sta arrivando ora). Questi documenti devono essere elaborati (qui viene in mente da DocBook a ePub).

Qualcuno sopra ha commentato che gli script tendono ad essere inferiori a 60 righe o diventano ingombranti. Se diventa ingombrante, è probabile che il programmatore non ne abbia davvero l'idea: XSLT è una mentalità molto diversa da molte altre lingue. Se non ottieni la mentalità, non funzionerà.

Certamente non è un linguaggio morente (la quantità di lavoro che ricevo me lo dice). In questo momento, è un po '"bloccato" fino a quando Microsoft non completa la sua (molto tarda) implementazione di XSLT 2. Ma è ancora lì e sembra andare forte dal mio punto di vista.

Usiamo ampiamente XSLT per cose come la documentazione e per rendere alcune impostazioni di configurazione complesse utilizzabili dall'utente.

Per la documentazione, utilizziamo molto DocBook, che è un formato basato su XML. Questo ci consente di archiviare e gestire la nostra documentazione con tutto il nostro codice sorgente, poiché i file sono testo semplice. Con XSLT, possiamo creare facilmente i nostri formati di documentazione, permettendoci sia di generare automaticamente il contenuto in modo generico, sia di renderlo più leggibile. Ad esempio, quando pubblichiamo note di rilascio, possiamo creare XML che assomigli a:

<ReleaseNotes>
    <FixedBugs>
        <Bug id="123" component="Admin">Error when clicking the Foo button</Bug>
        <Bug id="125" component="Core">Crash at startup when configuration is missing</Bug>
        <Bug id="127" component="Admin">Error when clicking the Bar button</Bug>
    </FixedBugs>
</ReleaseNotes>

E poi usando XSLT (che trasforma quanto sopra in DocBook) ci ritroviamo con belle note di rilascio (PDF o HTML di solito) dove gli ID dei bug sono automaticamente collegati al nostro bug tracker, i bug sono raggruppati per componente e il formato di tutto è perfettamente coerente . E l'XML sopra può essere generato automaticamente interrogando il nostro bug tracker per sapere cosa è cambiato tra le versioni.

L'altro punto in cui abbiamo trovato utile XSLT è in realtà nel nostro prodotto principale. A volte, quando ci interfacciamo con sistemi di terze parti, dobbiamo in qualche modo elaborare i dati in una pagina HTML complessa. L'analisi dell'HTML è brutta, quindi alimentiamo i dati tramite qualcosa come TagSoup(che genera eventi SAX XML appropriati, essenzialmente permettendoci di trattare l'HTML come se fosse XML scritto correttamente) e quindi possiamo eseguire alcuni XSLT su di esso, per trasformare i dati in un formato "noto stabile" con cui possiamo effettivamente lavorare . Separando quella trasformazione in un file XSLT, ciò significa che se e quando il formato HTML cambia, l'applicazione stessa non deve essere aggiornata, ma l'utente finale può semplicemente modificare il file XSLT da solo, oppure possiamo inviare un'e-mail loro un file XSLT aggiornato senza che l'intero sistema debba essere aggiornato.

Direi che per i progetti web ci sono modi migliori per gestire il lato di visualizzazione di XSLT oggi, ma come tecnologia ci sono sicuramente usi per XSLT. Non è la lingua più facile al mondo da usare, ma sicuramente non è morta e dal mio punto di vista ha ancora molti buoni usi.

XSLT è un esempio di un linguaggio di programmazione dichiarativo .

Altri esempi di linguaggi di programmazione dichiarativi includono espressioni regolari, Prolog e SQL. Tutti questi sono altamente espressivi e compatti, e di solito molto ben progettati e potenti per il compito per cui sono progettati.

Tuttavia, gli sviluppatori di software generalmente odiano tali linguaggi, perché sono così diversi dai linguaggi OO o procedurali più tradizionali che sono difficili da imparare e da correggere. La loro natura compatta generalmente rende molto facile fare molti danni inavvertitamente.

Quindi, sebbene XSLT sia un meccanismo efficiente per unire i dati nella presentazione, fallisce nel reparto facilità d'uso. Credo che sia per questo che non ha davvero preso piede.

Ricordo tutto il clamore intorno a XSLT quando lo standard è stato rilasciato di recente. Tutto l'entusiasmo derivante dalla possibilità di costruire un'intera interfaccia utente HTML con una trasformazione "semplice".

Ammettiamolo, è difficile da usare, quasi impossibile da eseguire il debug, spesso insopportabilmente lento. Il risultato finale è quasi sempre bizzarro e tutt'altro che ideale.

Mi rosiccherò prima la gamba piuttosto che usare un XSLT mentre ci sono modi migliori per fare le cose. Tuttavia ha i suoi posti, è buono per semplici compiti di trasformazione.

Ho utilizzato XSLT (e anche XQuery) ampiamente per varie cose: per generare codice C ++ come parte del processo di compilazione, per produrre documentazione dai commenti ai documenti e all'interno di un'applicazione che doveva lavorare con XML in generale e XHTML in particolare molto . Il generatore di codice in particolare superava le 10.000 righe di codice XSLT 2.0 distribuite su una dozzina di file separati (faceva molte cose: intestazioni per client, proxy / stub remoti, wrapper COM, wrapper .NET, ORM - per citarne alcune). L'ho ereditato da un altro ragazzo che non capiva bene la lingua, e di conseguenza i pezzi più vecchi erano un bel casino. Le cose più recenti che abbiamo scritto sono state per lo più mantenute integre e leggibili, tuttavia, e non ricordo alcun problema particolare nel raggiungerlo. Non è stato certamente più difficile che farlo per C ++.

Parlando di versioni, trattare con XSLT 2.0 ti aiuta sicuramente a mantenerti sano, ma 1.0 va ancora bene per trasformazioni più semplici. Nella sua nicchia, è uno strumento estremamente utile e la produttività che ottieni da alcune funzionalità specifiche del dominio (soprattutto, l'invio dinamico tramite la corrispondenza dei modelli) è difficile da eguagliare. Nonostante la verbosità percepita della sintassi basata su XML di XSLT, la stessa cosa in LINQ to XML (anche in VB con valori letterali XML) era in genere molte volte più lunga. Abbastanza spesso, tuttavia, ottiene un errore immeritato a causa dell'uso non necessario di XML in alcuni casi in primo luogo.

Per riassumere: è uno strumento incredibilmente utile da avere nella propria cassetta degli attrezzi, ma è molto specializzato, quindi è buono purché lo si usi correttamente e per lo scopo previsto. Vorrei davvero che ci fosse una corretta implementazione .NET nativa di XSLT 2.0.

Uso XSLT (per mancanza di alternative migliori), ma non per la presentazione, solo per la trasformazione:

1. Scrivo brevi trasformazioni XSLT per apportare modifiche di massa ai nostri file pom.xml maven.

2. Ho scritto una pipeline di trasformazioni per generare schemi XML da XMI (diagramma UML). Ha funzionato per un po ', ma alla fine è diventato troppo complesso e abbiamo dovuto portarlo fuori dietro la stalla.

3. Ho usato le trasformazioni per rifattorizzare gli schemi XML.

4. Ho aggirato alcune limitazioni in XSLT utilizzandolo per generare un XSLT per fare il vero lavoro. (Hai mai provato a scrivere un XSLT che produce un output utilizzando spazi dei nomi che non sono noti fino al runtime?)

Continuo a tornarci perché fa un lavoro migliore facendo girare l'XML che sta elaborando rispetto ad altri approcci che ho provato, che sono sembrati inutilmente con perdite o semplicemente fraintendono XML. XSLT è spiacevole, ma trovo che l'uso di ossigeno lo renda sopportabile.

Detto questo, sto studiando l'utilizzo di Clojure (un lisp) per eseguire trasformazioni di XML, ma non sono ancora andato abbastanza lontano per sapere se questo approccio mi porterà vantaggi.

Personalmente ho utilizzato XSLT in un contesto totalmente diverso. Il gioco per computer su cui stavo lavorando all'epoca utilizzava tonnellate di pagine dell'interfaccia utente definite utilizzando XML. Durante un importante refactoring subito dopo un rilascio, abbiamo voluto modificare la struttura di questi documenti XML. Abbiamo fatto in modo che il formato di input del gioco seguisse una struttura molto migliore e consapevole dello schema.

XSLT sembrava la scelta perfetta per questa traduzione dal vecchio formato -> Nuovo formato. Entro due settimane ho avuto una conversione funzionante da vecchio a nuovo per le nostre centinaia di pagine. Sono stato anche in grado di usarlo per estrarre molte informazioni sul layout delle nostre pagine dell'interfaccia utente. Ho creato elenchi di quali componenti erano incorporati in modo relativamente semplice, che poi ho usato XSLT per scrivere nelle nostre definizioni di schema.

Inoltre, provenendo da un background C ++, è stato un linguaggio molto divertente e interessante da padroneggiare.

Penso che come strumento per tradurre XML da un formato all'altro sia fantastico. Tuttavia, non è l'unico modo per definire un algoritmo che accetta XML come input e genera qualcosa . Se il tuo algoritmo è sufficientemente complesso, il fatto che l'input sia XML diventa irrilevante per la tua scelta dello strumento, ad esempio lancia il tuo in C ++ / Python / qualunque cosa.

In modo specifico per il tuo esempio, immagino che l'idea migliore sarebbe quella di creare la tua conversione XML-> XML che segua la tua logica aziendale. Quindi, scrivi un traduttore XSLT che conosce solo la formattazione e non fa nulla di intelligente. Potrebbe essere una bella via di mezzo, ma dipende totalmente da cosa stai facendo. Avere un traduttore XSLT sull'output semplifica la creazione di formati di output alternativi: stampabili, per cellulari, ecc.

Sì, lo uso molto. Utilizzando diversi file xslt, posso utilizzare la stessa sorgente XML per creare più file HTML poliglotta (X) (presentando gli stessi dati in modi diversi), un feed RSS, un feed Atom, un file descrittore RDF e un frammento di una mappa del sito .

Non è una panacea. Ci sono cose che fa bene e cose che non fa bene, e come tutti gli altri aspetti della programmazione, si tratta di usare lo strumento giusto per il lavoro giusto. È uno strumento che vale la pena avere nella tua cassetta degli attrezzi, ma dovrebbe essere utilizzato solo quando è appropriato.

Consiglio vivamente di tenerlo fuori. Soprattutto se utilizzi Visual Studio che dispone di strumenti di modifica, visualizzazione e debug integrati per XSLT.

Sì, è un dolore mentre impari, ma la maggior parte del dolore ha a che fare con la familiarità. Il dolore diminuisce man mano che impari la lingua.

W3schools ha due articoli di particolare valore: http://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Ho trovato che XSLT è abbastanza difficile da lavorare.

Ho avuto esperienza lavorando su un sistema in qualche modo simile a quello che descrivi. La mia azienda ha notato che i dati che stavamo restituendo dal "livello intermedio" erano in XML e che le pagine dovevano essere visualizzate in HTML, che potrebbe anche essere XHTML, inoltre avevano sentito che XSL era uno standard per la trasformazione tra XML formati. Quindi gli "architetti" (con questo intendo le persone che pensano a pensieri di progettazione profondi ma apparentemente non scrivono mai codice) hanno deciso che il nostro livello principale sarebbe stato implementato scrivendo script XSLT che trasformassero i dati nell'XHTML per la visualizzazione.

La scelta si è rivelata disastrosa. XSLT, si scopre, è un dolore da scrivere. E così tutte le nostre pagine erano difficili da scrivere e da mantenere. Avremmo fatto molto meglio se avessimo usato JSP (questo era in Java) o un approccio simile che usasse un tipo di markup (parentesi angolari) per il formato di output (l'HTML) e un altro tipo di markup (come <% ... %>) per i metadati. La cosa più confusa di XSLT è che è scritto in XML e si traduce da XML a XML ... è abbastanza difficile tenere bene a mente tutti e 3 i diversi documenti XML.

La tua situazione è leggermente diversa: invece di creare ogni pagina in XSLT come ho fatto io, devi solo scrivere UN bit di codice in XSLT (il codice da convertire da modelli a display). Ma sembra che tu possa aver incontrato lo stesso tipo di difficoltà che ho fatto io. Direi che cercare di interpretare un semplice DSL basato su XML (linguaggio specifico del dominio) come stai facendo NON è uno dei punti di forza di XSLT. (Anche se PU fare il lavoro ... dopotutto, è Turing completo!)

Tuttavia, se quello che avevi era più semplice: hai dati in un formato XML e volevi apportarvi semplici modifiche - non un DSL con descrizione completa della pagina, ma alcune semplici modifiche dirette, allora XSLT è uno strumento eccellente a tale scopo. La sua natura dichiarativa (non procedurale) è in realtà un vantaggio a tale scopo.

- Michael Chermside

XSLT è difficile da lavorare, ma una volta conquistato avrai una comprensione molto approfondita del DOM e dello schema. Se usi anche XPath, sei sulla buona strada per imparare la programmazione funzionale e questo ti esporrà a nuove tecniche e modi per risolvere i problemi. In alcuni casi, la trasformazione successiva è più potente delle soluzioni procedurali.

Uso ampiamente XSLT, per un front-end in stile MVC personalizzato. Il modello viene "serializzato" in xml (non tramite xml serializaiton) e quindi convertito in html tramite xslt. Il vantaggio rispetto ad ASP.NET risiede nella naturale integrazione con XPath e nei requisiti più rigorosi di buona formazione (è molto più facile ragionare sulla struttura del documento in xslt che nella maggior parte degli altri linguaggi).

Sfortunatamente, il linguaggio contiene diverse limitazioni (ad esempio, la capacità di trasformare l'output di un'altra trasformazione) il che significa che a volte è frustrante lavorare con.

Tuttavia, la separazione delle preoccupazioni facilmente realizzabile e fortemente applicata che garantisce non è qualcosa che vedo fornire un'altra tecnologia in questo momento, quindi per le trasformazioni dei documenti è ancora qualcosa che consiglierei.

Ho usato XML, XSD e XSLT su un progetto di integrazione tra sistemi DB molto dissimili nel 2004. Ho dovuto imparare XSD e XSLT da zero ma non è stato difficile. La cosa grandiosa di questi strumenti è che mi hanno permesso di scrivere codice C ++ indipendente dai dati, basandomi su XSD e XSLT per convalidare / verificare e quindi trasformare i documenti XML. Modificare il formato dei dati, modificare i documenti XSD e XSLT non il codice C ++ che utilizzava le librerie Xerces.

Per interesse: l'XSD principale era 150KB e la dimensione media dell'XSLT era <5KB IIRC.

L'altro grande vantaggio è che l'XSD è un documento di specifiche su cui si basa XSLT. I due lavorano in armonia. E le specifiche sono rare nello sviluppo del software in questi giorni.

Anche se non ho avuto troppi problemi ad apprendere la natura dichiarativa XSD e XSLT, ho scoperto che altri programmatori C / C ++ avevano grossi problemi nell'adattarsi al modo dichiarativo. Quando hanno visto che era finita, ah procedurale hanno borbottato, ora che ho capito! E hanno proceduto (gioco di parole?) A scrivere XSLT procedurale! Il fatto è che devi imparare XPath e capire gli assi di XML. Mi ricorda i vecchi programmatori in C che si abituano a utilizzare OO quando scrivono C ++.

Ho usato questi strumenti perché mi hanno permesso di scrivere una piccola base di codice C ++ che era isolata da tutte le modifiche alla struttura dei dati tranne le più fondamentali e queste ultime erano le modifiche alla struttura del DB. Anche se preferisco il C ++ a qualsiasi altro linguaggio, userò quello che considero utile per beneficiare della fattibilità a lungo termine di un progetto software.

Pensavo che XSLT fosse un'ottima idea. Voglio dire, è un'ottima idea.

Dove fallisce è l'esecuzione.

Il problema che ho scoperto nel tempo è stato che i linguaggi di programmazione in XML sono solo una cattiva idea. Rende l'intera cosa impenetrabile. In particolare, penso che XSLT sia molto difficile da imparare, codificare e capire. L'XML oltre agli aspetti funzionali rende l'intera cosa troppo confusa. Ho provato a impararlo circa 5 volte nella mia carriera e non si attacca.

OK, potresti "manipolarlo" - penso che fosse in parte il punto del suo design - ma questo è il secondo errore: tutti gli strumenti XSLT sul mercato sono, semplicemente ... schifo!

La specifica XSLT definisce XSLT come "un linguaggio per trasformare i documenti XML in altri documenti XML". Se stai cercando di fare qualsiasi cosa tranne l'elaborazione dei dati di base all'interno di XSLT, probabilmente ci sono soluzioni migliori.

Vale anche la pena notare che le capacità di elaborazione dei dati di XSLT possono essere estese in .NET utilizzando funzioni di estensione personalizzate:

• Documentazione MSDN
• CSharpFriends: Tutorial

Mantengo un sistema di documentazione in linea per la mia azienda. Gli autori creano la documentazione in SGML (un linguaggio simile a xml). L'SGML viene quindi combinato con XSLT e trasformato in HTML.

Questo ci consente di apportare facilmente modifiche al layout della documentazione senza eseguire alcuna codifica. È solo questione di cambiare XSLT.

Questo funziona bene per noi. Nel nostro caso, è un documento di sola lettura. L'utente non sta interagendo con la documentazione.

Inoltre, utilizzando XSLT, stai lavorando più vicino al tuo dominio problematico (HTML). Considero sempre che sia una buona idea.

Infine, se il tuo sistema attuale FUNZIONA, lascialo stare. Non suggerirei mai di cestinare il codice esistente. Se partissi da zero, userei XSLT, ma nel tuo caso, userei quello che hai.

Dipende da cosa ti serve. Il suo principale punto di forza è la facile manutenibilità della trasformazione, e scrivere un proprio parser generalmente lo cancella. Detto questo, a volte un sistema è piccolo e semplice e non necessita di una soluzione "fantasia". Finché il tuo generatore basato su codice è sostituibile senza dover modificare altro codice, non è un grosso problema.

Per quanto riguarda la bruttezza di XSL, sì, è brutto. Sì, ci vuole un po 'per abituarsi. Ma una volta capito (non dovrebbe volerci molto IMO), in realtà è una navigazione tranquilla. Le trasformazioni compilate vengono eseguite abbastanza rapidamente secondo la mia esperienza e puoi sicuramente eseguire il debug in esse.

Continuo a credere che XSLT possa essere utile, ma è un linguaggio brutto e può portare a un terribile pasticcio illeggibile e irrimediabile. In parte perché XML non è abbastanza leggibile dall'uomo per creare un "linguaggio" e in parte perché XSLT è bloccato da qualche parte tra l'essere dichiarativo e procedurale. Detto questo, e penso che si possa fare un confronto con le espressioni regolari, ha i suoi usi quando si tratta di problemi semplici e ben definiti.

Usare l'approccio alternativo e analizzare l'XML nel codice può essere altrettanto sgradevole e si desidera davvero impiegare una sorta di tecnologia di marshalling / binding XML (come JiBX in Java) che convertirà il tuo XML direttamente in un oggetto.

Se puoi usare XSLT in uno stile dichiarativo (anche se non sono del tutto d'accordo sul fatto che sia un linguaggio dichiarativo), penso che sia utile ed espressivo.

Ho scritto app Web che utilizzano un linguaggio OO (C # nel mio caso) per gestire il livello dati / elaborazione, ma restituiscono XML anziché HTML. Questo può quindi essere utilizzato direttamente dai client come API di dati o reso come HTML dagli XSLT. Poiché il C # emetteva XML che era strutturalmente compatibile con questo uso, tutto era molto fluido e la logica di presentazione era mantenuta dichiarativa. È stato più facile seguire e modificare che inviare i tag da C #.

Tuttavia, poiché è necessaria più logica di elaborazione a livello XSLT, diventa contorta e prolissa, anche se "si ottiene" lo stile funzionale.

Ovviamente, in questi giorni probabilmente avrei scritto quelle app web utilizzando un'interfaccia RESTful - e penso che i "linguaggi" di dati come JSON stiano guadagnando terreno in aree in cui XML è stato tradizionalmente trasformato da XSLT. Ma per ora XSLT è ancora una tecnologia importante e utile.

Ho trascorso molto tempo in XSLT e ho scoperto che sebbene sia uno strumento utile in alcune situazioni, non è sicuramente una soluzione completa. Funziona molto bene per scopi B2B quando viene utilizzato per la traduzione dei dati per input / output XML leggibili dalla macchina. Non penso che tu sia sulla strada sbagliata nella tua dichiarazione dei suoi limiti. Una delle cose che mi ha frustrato di più sono state le sfumature nelle implementazioni di XSLT.

Forse dovresti esaminare alcuni degli altri linguaggi di markup disponibili. Credo che Jeff abbia scritto un articolo proprio su questo argomento riguardante Stack Overflow.

HTML è un linguaggio di markup umano?

Vorrei dare un'occhiata a quello che ha scritto. Probabilmente puoi trovare un pacchetto software che fa quello che vuoi "fuori dagli schemi", o almeno molto vicino invece di scrivere le tue cose da zero.

Al momento ho il compito di estrarre dati da un sito pubblico (sì, lo so). Per fortuna è conforme a xhtml, quindi posso usare xslt per raccogliere i dati di cui ho bisogno. La soluzione risultante è leggibile, pulita e facile da cambiare se necessario. Perfetto!

Ho già usato XSLT. Il gruppo di 6 file .xslt (refactored da uno grande) era di circa 2750 righe molto prima che lo riscrivessi in C #. Il codice C # è attualmente di 4000 righe contenenti molta logica; Non voglio nemmeno pensare a cosa ci sarebbe voluto per scrivere in XSLT.

Il punto in cui ho rinunciato è stato quando ho capito che non avere XPATH 2.0 stava danneggiando in modo significativo i miei progressi.

Per rispondere alle tue tre domande:

1. Ho usato XSLT una volta alcuni anni fa.
2. Credo che XSLT potrebbe essere la soluzione giusta in determinate circostanze. (Mai dire mai)
3. Tendo a concordare con la tua affermazione che è utile soprattutto per trasformazioni "semplici". Ma penso che fintanto che si capisce bene XSLT, ci sono ragioni per usarlo per attività più grandi come la pubblicazione di un sito Web come XML trasformato in HTML.

Credo che il motivo per cui molti sviluppatori non amano XSLT è perché non capiscono il paradigma fondamentalmente diverso su cui si basa. Ma con il recente interesse per la programmazione funzionale potremmo vedere XSLT fare un ritorno ...

Un aspetto in cui xslt brilla davvero è nella generazione di report. Ho scoperto che un processo in 2 fasi, con il primo passaggio che esporta i dati del report come file xml e il secondo passaggio che genera il report visivo da xml utilizzando xslt. Ciò consente di creare rapporti visivi piacevoli pur mantenendo i dati grezzi in giro come meccanismo di convalida se necessario.

In una società precedente abbiamo fatto molto con XML e XSLT. Sia XML che XSLT big.

Sì, c'è una curva di apprendimento, ma poi hai un potente strumento per gestire XML. E puoi persino usare XSLT su XSLT (che a volte può essere utile).

Anche le prestazioni sono un problema (con XML molto grandi) ma è possibile affrontarlo utilizzando XSLT intelligente ed eseguire un po 'di pre-elaborazione con l'XML (generato).

Chiunque abbia una conoscenza di XSLT può cambiare l'aspetto del prodotto finito perché non è compilato.

Personalmente mi piace XSLT e potresti voler dare un aspetto alla sintassi semplificata (nessun modello esplicito, solo un normale vecchio file HTML con alcuni tag XSLT per sputarci valori), ma non è per tutti.

Forse vuoi solo offrire ai tuoi autori una semplice interfaccia Wiki o Markdown. Ci sono anche librerie per questo, e se XSLT non funziona per te, forse XML non funziona neanche per loro.

XSLT non è l'essenziale della trasformazione xml. Tuttavia, è molto difficile giudicare in base alle informazioni fornite se sarebbe stata la migliore soluzione al tuo problema o se ci fossero altri approcci più efficienti e mantenibili. Dici che gli autori potrebbero inserire i loro contenuti in un formato semplificato: quale formato? Caselle di testo? In che tipo di HTML lo stavi convertendo? Per giudicare se XSLT è lo strumento giusto per il lavoro, sarebbe utile conoscere le caratteristiche di questa trasformazione in modo più dettagliato.

Mi piace usare XSLT solo per modificare la struttura ad albero dei documenti XML. Trovo scomodo fare qualsiasi cosa relativa all'elaborazione del testo e relegarla a uno script personalizzato che posso eseguire prima o dopo aver applicato un XSLT a un documento XML.

XSLT 2.0 includeva molte più funzioni per le stringhe, ma penso che non sia adatto al linguaggio e non ci sono molte implementazioni di XSLT 2.0.