•  09-06-2019
  •  | 
  •  

Domanda

Un po ' di tempo fa, ho iniziato un progetto in cui ho progettato un html-esque XML schema, in modo che gli autori possono scrivere il loro contenuto (corso scolastico di materiale) in un formato semplificato, che si sarebbe poi trasformato in HTML tramite XSLT.Ho giocato (lottato) per un po', e ha ottenuto un livello molto di base, ma poi era troppo infastidito dal limite che stavo incontrando (che potrebbe essere stato limitazioni di mia conoscenza) e quando ho letto un blog suggerendo di abbandonare XSLT e basta scrivere il tuo XML-per-qualunque sia il parser nella vostra lingua, a scelta, con entusiasmo ho saltato su e ha funzionato brillantemente.

Sto ancora lavorando su di esso per un giorno (In realtà ho dovuto essere al lavoro su di esso ora, invece di giocare COSÌ), e sto vedendo sempre di più le cose che mi fanno pensare che la decisione di abbandonare XSLT è stata una buona.

So che XSLT ha il suo posto, che è uno standard accettato, e che se tutti scrivono i loro interpreti, il 90% di loro andrà a finire nelle TheDailyWTF.Ma dato che non è un stile funzionale della lingua invece procedurali stile che la maggior parte dei programmatori sono a conoscenza, per qualcuno di iniziare un progetto come il mio, mi consiglia loro di andare giù per il sentiero che ho fatto io, o bastone con XSLT?

È stato utile?

Soluzione

Vantaggi di XSLT:

  • Dominio-specifiche di XML, così, per esempio, non c'è bisogno di citazione letterale XML in uscita.
  • Supporta XPath/XQuery, che può essere un bel modo per query DOMs, nello stesso modo in cui le espressioni regolari possono essere un bel modo per stringhe di query.
  • Linguaggio funzionale.

Gli svantaggi di XSLT:

  • Può essere oscenamente verbose - non devi citazione letterale XML, il che significa che effettivamente fare a meno di citare il codice.E non in un bel modo.Ma poi di nuovo, non è molto peggio che il vostro tipico SSI.
  • Non fare certe cose, che la maggior parte dei programmatori per scontato.Per esempio la manipolazione di stringhe può essere un lavoro di routine.Questo può portare a "sfortunato momenti" quando novizi di design, codice, poi freneticamente a cercare sul web per suggerimenti su come implementare le funzioni hanno assunto che sarebbe solo essere lì e di non dare a se stessi il tempo per scrivere.
  • Linguaggio funzionale.

Un modo per ottenere un comportamento procedurale, a proposito, è una catena di trasformazioni multiple insieme.Dopo ogni passaggio si dispone di un nuovissimo DOM al lavoro che riflette le variazioni di questo passo.Alcuni XSL processori sono le estensioni in modo efficace di fare questo in una trasformazione, ma non ricordo i dettagli.

Così, se il codice è praticamente uscita e non molto logica, XSLT può essere un modo molto ordinato per esprimerlo.Se c'è un sacco di logica, ma soprattutto di forme che si sono costruiti in XSLT (seleziona tutti gli elementi che sembrano bla, e per ognuno di uscita bla), è probabile che sia piuttosto un ambiente accogliente.Se avete voglia di pensare XML-ishly in tutti i tempi, e quindi dare XSLT 2 go.

In caso contrario, direi che se il tuo preferito linguaggio di programmazione ha un buon DOM attuazione di supporto XPath e che consente di creare documenti in modo utile, poi ci sono alcuni vantaggi ad usare XSLT.Associazioni di libxml2 e gdome2 dovrebbe fare bene, e non c'è nessuna vergogna nell'attaccare generici lingue che si conoscono bene.

Home-grown parser XML sono di solito o incompleto (nel qual caso ti scollarsi qualche giorno) o altro non molto più piccola rispetto a qualcosa che si potrebbe avere ottenuto off the shelf (nel qual caso probabilmente stai sprecando il tuo tempo), e dare un qualsiasi numero di opportunità di introdurre gravi problemi di sicurezza relativi input dannoso.Non scrivere se non sai esattamente quello che si guadagna facendo.Non c'è che dire, non è possibile scrivere un parser per qualcosa di più semplice di XML come formato di input, se non avete bisogno di tutto quello che XML offre.

Altri suggerimenti

Tanta negatività!

Sto usando XSLT per un bel po ' di anni ormai, e sinceramente l'amore.La cosa fondamentale è capire che non è un linguaggio di programmazione è un linguaggio di template (e in questo senso trovo indescrivibilmente superiore a asp.net /spit).

XML è de facto il formato dei dati di sviluppo per il web di oggi, sia i file di configurazione, dati grezzi o nella memoria reprsentation.XSLT e XPath dare un' enormemente potente e molto efficace per trasformare i dati in qualsiasi formato di output come si potrebbe, istantaneamente dando MVC aspetto di separare la presentazione dal dati.

Poi c'è il programma di utilità di abilità:il lavaggio di spazi dei nomi, riconoscendo disparate definizioni di schema, l'unione di documenti.

Si deve essere migliore per affrontare con XSLT di sviluppare i suoi propri metodi.Almeno XSLT è uno standard ed è qualcosa che si potrebbe assumere, e, se mai è davvero un problema per la tua squadra è molto natura che consentono di mantenere la maggior parte del vostro team di lavoro solo con XML.

Un vero e proprio mondo di caso d'uso:Ho appena scritto un app che gestisce XML in memoria documenti in tutto il sistema, e si trasforma in JSON, HTML o XML come richiesto dall'utente finale.Ho avuto abbastanza casuale richiesta di fornire i dati di Excel.Un ex collega aveva fatto qualcosa di simile a livello di programmazione, ma è necessario un modulo di un paio di file di classe e che il server di MS Office installato!Si rivelasse Excel ha un XSD:nuove funzionalità con il minimo basecode impatto in 3 ore.

Personalmente credo che sia una delle cose più pulito che ho incontrato nella mia carriera, e credo che tutti è evidente che i problemi (debug, la manipolazione di stringhe, strutture di programmazione) sono giù per una comprensione imperfetta dello strumento.

Ovviamente, sono fermamente convinto che questo è "vale la pena".

Devo ammettere che un pregiudizio perché insegno XSLT per vivere.Ma, potrebbe essere la pena di copertura fuori le aree che vedo I miei studenti che lavorano nel.Si dividono in tre gruppi in genere:editoria, banche e web.

Molte delle risposte finora può essere riassunta come "non è un bene per la creazione di siti web" o "niente a che vedere con la lingua X".Molti tech gente passare attraverso le loro carriere con nessuna esposizione funzionale/linguaggi dichiarativi.Quando insegno, l'esperto Java/VB/C/ecc popolari sono quelli che hanno problemi con la lingua (le variabili sono variabili, nel senso dell'algebra non di programmazione procedurale per esempio).Che molte delle persone che risponde qui - non ho mai avuto con Java, ma non ho intenzione di preoccuparsi di criticare la lingua a causa di questo.

In molte circostanze è un appropriato strumento per la creazione di siti web - un generico linguaggio di programmazione può essere migliore.Ho spesso bisogno di prendere molto grande e documenti XML presente sul web;XSLT che banale.Gli studenti che vedo in questo spazio tendono ad essere l'elaborazione di set di dati e la loro presentazione sul web.XSLT non è certo l'unico strumento applicabile in questo spazio.Tuttavia, molti di loro sono utilizzando il DOM per fare questo e XSLT è sicuramente meno doloroso.

Bancario studenti la vedo io uso un DataPower casella in generale.Questo è un XML apparecchio usato per sedersi tra i servizi di 'parlare' XML diversi dialetti.La trasformazione da un linguaggio XML per un altro, è quasi banale in XSLT e il numero degli studenti che frequentano i miei corsi su questo sono in aumento.

Il set finale di studenti vedo provenire da una pubblicazione di sfondo (come me).Queste persone tendono ad avere un immenso documenti in XML (credetemi, editoria del settore è sempre molto in XML - editoria tecnica è stato lì per anni e commercio la pubblicazione è sempre lì ora).Questi documenti devono essere oggetto di trattamento (DocBook ePub viene in mente qui).

Qualcuno sopra ha commentato che gli script tendono ad essere al di sotto del 60 linee o diventare ingombrante.Se diventa un po ' ingombrante, le probabilità sono il programmatore non ha davvero avuto l'idea - XSLT è molto diversa mentalità da molte altre lingue.Se non si ottiene la mentalità non funziona.

Certamente non è un morire lingua (la quantità di lavoro che ho mi dice che).Ora come ora, è un po 'bloccato' fino a quando Microsoft non finire il loro (molto in ritardo) per l'attuazione di XSLT 2.Ma è ancora lì e sembra andare forte dal mio punto di vista.

Possiamo utilizzare XSLT ampiamente per le cose, come la documentazione, e facendo alcuni complessi impostazioni di configurazione riparabili dall'utente.

Per la documentazione, usiamo un sacco di DocBook, che è un formato basato su XML.Questo ci permette di archiviare e gestire la documentazione con tutto il nostro codice sorgente, dal momento che i file sono in formato testo normale.Con XSLT, si può facilmente costruire la nostra documentazione formati, che ci permette sia di genera automaticamente il contenuto in modo generico, e di rendere il contenuto più leggibile.Per esempio, quando pubblichiamo le note di rilascio, siamo in grado di creare XML che sembra qualcosa di simile:

<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, utilizzando XSLT, che trasforma il sopra di DocBook), finiamo con belle note di rilascio (in formato PDF o HTML di solito) dove bug Id sono automaticamente collegati al nostro bug tracker, i bug sono raggruppati per componente e formato di tutto è perfettamente coerente.E al di sopra di XML può essere generato automaticamente interrogando il nostro bug tracker per cosa è cambiato tra le versioni.

Il posto dove abbiamo trovato XSLT per essere utile è in realtà nel nostro prodotto principale.A volte, quando l'interfacciamento con sistemi di terze parti, dobbiamo in qualche modo i dati di processo in un complesso di pagina HTML.L'analisi HTML è brutto, così alimentiamo i dati attraverso qualcosa di simile TagSoup (che genera il corretto SAX XML eventi, essenzialmente di farci trattare con l'HTML come se fosse scritto correttamente XML) e quindi siamo in grado di eseguire alcuni XSLT contro di essa, per trasformare i dati in una "scuderia" di formato che si può effettivamente lavorare.Separando che la trasformazione in un file XSLT, il che significa che se e quando il formato HTML modifiche, l'applicazione non ha bisogno di essere aggiornato, invece, l'utente finale può modificare il file XSLT se stessi, o siamo in grado di inviare per e-mail un file XSLT aggiornato senza l'intero sistema che ha bisogno di essere aggiornato.

Direi che per i progetti web, ci sono modi migliori per gestire la vista laterale di XSLT oggi, ma come la tecnologia ci sono sicuramente usi per XSLT.Non è la lingua più facile del mondo, ma che non è sicuramente morto, e dal mio punto di vista ha ancora un sacco di usi bene.

XSLT è un esempio di un programmazione dichiarativa lingua.

Altri esempi di programmazione dichiarativa lingue sono espressioni regolari, Prolog, e di SQL.Tutti questi sono molto espressivi e compatto, e di solito molto ben progettato e potente per il compito per cui sono stati progettati.

Tuttavia, gli sviluppatori di software in genere odio le lingue, perché sono così diversi da più mainstream OO o linguaggi procedurali che sono difficili da imparare ed eseguire il debug.La struttura compatta e la natura in genere rende molto facile fare un sacco di danni involontariamente.

Così, mentre XSLT è un meccanismo efficiente per unire i dati in presentazione, non riesce la facilità di utilizzo di reparto.Credo che è perché non ha davvero catturato.

Ricordo che tutto l'hype intorno XSLT quando lo standard è stato appena rilasciato.Tutte le emozioni in giro di essere in grado costruita un'intera UI HTML con un 'semplice' trasformare.

Ammettiamolo, è difficile da usare, quasi impossibile eseguire il debug, spesso insopportabilmente lento.Il risultato finale è quasi sempre eccentrica e meno ideale.

Io prima rosicchiare fuori la mia gamba di utilizzare un XSLT, mentre ci sono modi migliori di fare le cose.Ancora ha i suoi luoghi, la sua buona per semplice attività di trasformazione.

Ho usato XSLT (e anche XQuery) ampiamente per varie cose - per generare il codice C++ come parte del processo di generazione, di produrre una documentazione da doc commenti, e all'interno di un'applicazione che ha dovuto lavorare con XML in generale e XHTML, in particolare, un sacco.Il generatore di codice, in particolare, era in eccesso di 10.000 linee di XSLT 2.0 codice diffusione in tutto una decina di file separati (ha fatto un sacco di cose - intestazioni per i clienti, servizi remoti proxies/stubs, wrapper COM, .NET wrapper, ORM - solo per citarne alcuni).Ho ereditato più di un altro ragazzo che non capiva bene la lingua, e il più vecchio di bit, di conseguenza, un bel pasticcio.Più recente delle cose che abbiamo scritto è stato in gran parte mantenuto sano e leggibile, tuttavia, e non ricordo particolari problemi con il raggiungimento di questo.Non era di certo qualsiasi più difficile che farlo per C++.

Parlando di versioni, trattare con XSLT 2.0 sicuramente aiuta a mantenere sano di mente, ma 1.0 è ancora bene, per semplici trasformazioni.Nella sua nicchia, è estremamente pratico strumento, e la produttività si ottiene da un certo dominio di funzioni specifiche, soprattutto, dinamico spedizione tramite template matching) è difficile da eguagliare.Nonostante la percezione wordiness di XSLT la sintassi basata su XML, la stessa cosa in LINQ to XML (anche in VB con XML literals) di solito è stato diverse volte di più.Molto spesso, tuttavia, si arriva immeritata flack a causa di un uso non necessario di XML, in qualche caso, in primo luogo.

Per riassumere:è uno strumento incredibilmente utile per avere nella cassetta degli attrezzi, ma è molto specialistico, in modo da è buono così a lungo come si usano correttamente e per il suo scopo.Vorrei davvero che ci fosse un vero e proprio nativo .NET attuazione di XSLT 2.0.

Io uso XSLT (per mancanza di alternative), ma non per la presentazione, solo per la trasformazione:

  1. Io di scrivere una breve trasformazioni XSLT per fare massa modifiche sul nostro maven pom.xml i file.

  2. Ho scritto una pipeline di trasformazioni, per generare Schemi XML da XMI (Diagramma UML).Ha funzionato per un po, ma alla fine è troppo complesso e abbiamo dovuto portarlo fuori, dietro il fienile.

  3. Ho usato trasformazioni refactoring di Schemi XML.

  4. Ho lavorato intorno ad alcune limitazioni in XSLT usando per generare un file XSLT per fare il lavoro.(Mai provato a scrivere un file XSLT che produce un output utilizzando gli spazi dei nomi non sono noti fino a runtime?)

Io ritorno perché era un lavoro migliore round-tripping XML è l'elaborazione di altri approcci che ho provato, che sembrava inutilmente con perdita di dati o semplicemente fraintendere XML.XSLT è sgradevole, ma trovo che usare Ossigeno lo rende sopportabile.

Detto questo, sto indagando utilizzando Clojure (un lisp) per effettuare trasformazioni di XML, ma non ho ottenuto abbastanza lontano ancora di sapere se questo approccio mi porterà benefici.

Personalmente ho usato XSLT in un contesto totalmente differente.Il gioco per computer che stavo lavorando al momento utilizzato tonnellate di UI pagine definite utilizzando XML.Nel corso di un grande refactor poco dopo un comunicato volevamo cambiare la struttura dei documenti XML.Abbiamo fatto il gioco del formato di input seguire molto meglio e schema di conoscenza della struttura.

XSLT è sembrata la scelta perfetta per questa traduzione dal vecchio formato -> Nuovo formato.Entro due settimane ho avuto un lavoro di conversione dal vecchio al nuovo per le nostre centinaia di pagine.Sono stato anche in grado di usarlo per estrarre un sacco di informazioni sul layout dell'interfaccia utente pagine.Ho creato elenchi di cui i componenti sono stati inseriti in che modo relativamente semplice, che ho poi utilizzato XSLT scrivere nel nostro definizioni di schema.

Anche proveniente da un background di C++, è stato molto divertente e interessante di lingua per padroneggiare.

Penso che come strumento per la traduzione di XML da un formato all'altro è fantastico.Tuttavia, non è l'unico modo per definire un algoritmo che prende XML come input e output Qualcosa.Se il tuo algoritmo è sufficientemente complesso, il fatto che l'ingresso è XML diventa irrilevante per la vostra scelta dello strumento - i.e arrotolare in C++ / Python / qualunque cosa.

Specifici per il tuo esempio, mi viene da pensare che l'idea migliore sarebbe quella di creare il proprio XML->conversione XML che segue la logica di business.Avanti, scrivere un XSLT traduttore che sa solo sulla formattazione e non fa nulla di intelligente.Che potrebbe essere una bella via di mezzo, ma tutto dipende da cosa si sta facendo.Avere un XSLT traduttore in uscita rende più facile per creare alternative di formati di output stampabile, per i cellulari, etc.

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

Non è una panacea.Ci sono cose che fa bene, e le cose non fanno bene, e come tutti gli altri aspetti di programmazione, è tutto su come usare lo strumento giusto per il lavoro giusto.Si tratta di uno strumento che vale la pena di avere nella vostra cassetta degli attrezzi, ma dovrebbe essere utilizzato solo quando è opportuno farlo.

Mi sarebbe sicuramente consigliamo di stick it out.In particolare se si utilizza visual studio che ha costruito in modifica, visualizzazione e strumenti di debug per XSLT.

Sì, è un dolore mentre si sta imparando, ma la maggior parte del dolore è quello di fare con una certa familiarità.Il dolore non diminuisce, come si impara la lingua.

W3schools dispone di due articoli che sono di particolare pregiohttp://www.w3schools.com/xpath/xpath_functions.asp http://www.w3schools.com/xsl/xsl_functions.asp

Ho trovato XSLT essere molto difficile da lavorare.

Ho avuto esperienza di lavoro su un sistema un po ' simile a quello che tu descrivi.La mia azienda ha notato che i dati erano di ritorno da un "livello intermedio" era in XML, e che le pagine dovevano essere visualizzato in HTML che potrebbe anche essere XHTML, in più avevo sentito che XSL è uno standard per la trasformazione tra i formati XML.Così il "architetti" (mi riferisco a gente che la pensa deep design pensieri, ma a quanto pare non codice) ha deciso che i nostri anteriore tier vorresti essere implementata attraverso la scrittura di script XSLT che trasforma i dati in XHTML per la visualizzazione.

La scelta si è rivelata disastrosa.XSLT, si scopre, è un dolore per scrivere.E così tutte le nostre pagine sono difficili da scrivere e da mantenere.Ci avrebbe fatto molto meglio avere usato JSP (questo era in Java) o qualche simile approccio utilizzato un tipo di markup (tra parentesi angolari) per il formato di output (HTML) e un altro tipo di markup (come <%...%>) per i meta-dati.La parte più confusa XSLT è che è scritto in XML, e si traduce da XML XML...è molto difficile mantenere tutti e 3 diversi documenti XML dritto nella mente.

La tua situazione è leggermente diversa:invece di creare ogni pagina XSLT come ho fatto io, è solo bisogno di scrivere UN pezzo di codice in XSLT (il codice per la conversione da modelli di display).Ma sembra che è lo stesso tipo di difficoltà che ho fatto.Direi che il tentativo di interpretare un semplice basato su XML DSL (domain specific language) come si sta facendo NON è uno dei punti di forza di XSLT.(Anche se si PUÒ fare il lavoro...dopo tutto, È Turing completo!)

Tuttavia, se ciò che si aveva era più semplice:si dispone di dati in un formato XML e volevo fare delle semplici modifiche ad esso-non è una pagina intera-descrizione DSL, ma alcune semplici semplici modifiche, quindi XSLT è un ottimo strumento per questo scopo.È dichiarativa (e non processuale) la natura è in realtà un vantaggio per tale scopo.

- Michael Chermside

XSLT è difficile da lavorare, ma una volta che si conquista si avrà una conoscenza approfondita del DOM e schema.Se anche voi XPath, quindi il tuo modo di imparare la programmazione funzionale e questo esporrà le nuove tecniche e modi di risolvere i problemi.In alcuni casi, la successiva trasformazione è più potente di soluzioni procedurali.

Io uso XSLT ampiamente, per un custom stile MVC front-end.Il modello è "serializzato" xml (non tramite xml serializaiton), e poi convertiti in html tramite xslt.Il vantaggio rispetto ASP.NET giacciono in una naturale integrazione con XPath, e la più rigorosa well-formedness requisiti (è molto più facile ragionare sulla struttura del documento xslt che nella maggior parte delle altre lingue).

Purtroppo, il linguaggio contiene diverse limitazioni (per esempio, la capacità di trasformare l'uscita di un'altra trasformazione), che significa che è occasionalmente frustrante lavorare con.

Tuttavia, l'facilmente realizzabili, fortemente imposto la separazione delle preoccupazioni che le sovvenzioni non sono qualcosa vedo un'altra tecnologia che fornisce in questo momento - così per documento trasforma è ancora qualcosa che mi consiglia.

Ho usato XML, XSD, XSLT e su un progetto di integrazione tra molto dis-simile DB sistemi a volte nel 2004.Ho dovuto imparare XSD XSLT da zero ma non è stato difficile.La cosa grandiosa di questi strumenti è stato che mi ha permesso di scrivere i dati indipendente di codice C++, contando su XSD XSLT e di verificare verificare e quindi di trasformare documenti XML.Modificare il formato dei dati, modificare i documenti XSLT XSD e non il codice C++ che hanno impiegato i Xerces librerie.

Per interesse:il principale XSD era 150KB e la dimensione media del XSLT era < 5KB IIRC.

L'altro grande vantaggio è che XSD è un documento di specifica che il XSLT è basato su.I due lavorano in armonia.E specifiche sono rare nello sviluppo di software in questi giorni.

Anche se non ho avuto troppi problemi di apprendimento, la natura dichiarativa XSD XSLT e ho trovato che altri programmatori C/C++ avuto grandi difficoltà ad adattarsi alla modalità dichiarativa.Quando videro che era, ah procedurali, si mormora, ora che ho capito!E si è proceduto (gioco di parole?) per scrivere procedurali XSLT!Il fatto è che devi imparare XPath e capire gli assi di XML.Mi ricorda dei vecchi programmatori C regolazione a impiegare OO durante la scrittura di C++.

Io ho utilizzato questi strumenti, mi ha permesso di scrivere un piccolo codice C++ di base che è stato isolato da tutti, ma il più fondamentale di struttura di dati modifiche e questi ultimi sono stati DB modifiche di struttura.Anche se preferisco il C++ per qualsiasi altra lingua, io uso quello che io ritengo essere utili a beneficio della redditività a lungo termine di un progetto software.

Ho usato a pensare XSLT è stata una grande idea.Voglio dire, è è una grande idea.

Dove fallisce l'esecuzione.

Il problema che ho scoperto nel corso del tempo è che i linguaggi di programmazione in XML sono solo una cattiva idea.Si rende il tutto impenetrabile.In particolare penso XSLT è molto difficile imparare, codice e capire.L'XML in cima gli aspetti funzionali solo rende il tutto troppo confuso.Ho cercato di imparare circa 5 volte nella mia carriera, e non il bastone.

OK, si potrebbe 'strumento' -- e penso che è stato in parte il punto di design-ma questo è il secondo difetto:tutti i XSLT strumenti sul mercato sono, molto semplicemente ...merda!

Il XSLT specifica definisce XSLT come "una lingua per la trasformazione di documenti XML in altri documenti XML".Se si sta tentando di fare qualsiasi cosa, ma la maggior parte dei dati di base di elaborazione all'interno di XSLT, probabilmente ci sono soluzioni migliori.

Vale anche la pena notare che la capacità di elaborazione dei dati di XSLT può essere estesa .NET utilizzando funzioni di estensione personalizzata:

Mantenere un sistema di documentazione online per la mia azienda.Gli scrittori di creare la documentazione in SGML xml come linguaggio ).L'SGML è poi combinato con XSLT e trasformato in HTML.

Questo ci permette di apportare modifiche alla documentazione di layout senza fare alcuna codifica.Il suo solo una questione di cambiare il XSLT.

Questo funziona bene per noi.Nel nostro caso, la sua sola lettura del documento.L'utente non interagisce con la documentazione.

Inoltre, utilizzando XSLT, si lavora più vicino al vostro dominio del problema (HTML).Ho sempre considerare che, per essere una buona idea.

Infine, se il vostro sistema attuale FUNZIONA, lascia stare.Non avrei mai suggerire cestinare il codice esistente.Se ero a partire da zero, vorrei utilizzare XSLT, ma nel tuo caso, vorrei usare quello che hai.

Si tratta di che cosa avete bisogno per.Il suo principale punto di forza è la facilità di manutenzione della trasformazione, e la scrittura di un proprio parser generalmente devastano che.Detto questo, a volte, un sistema di piccole e semplici e davvero non ha bisogno di una "fantasia" soluzione.Fintanto che il codice di base di generatore è sostituibile senza dover cambiare altro codice, non un grosso problema.

Come per la bruttezza di XSL, sì, è brutto.Sì, ci vuole un po per abituarsi.Ma una volta a ottenere il blocco di esso (che non deve durare a lungo IMO), è in realtà regolare la vela.Compilato trasforma funzionare abbastanza rapidamente nella mia esperienza, e si può certamente eseguire il debug in loro.

Io credo ancora che XSLT può essere utile, ma è una brutta lingua e può portare a una terribile illeggibile, non gestibile pasticcio.In parte a causa XML non è leggibile abbastanza per fare una "lingua" e, in parte, perché XSLT è bloccato da qualche parte tra l'essere dichiarativa e procedurale.Detto questo, e credo che un confronto può essere disegnato con le espressioni regolari, si ha la usi quando si tratta di semplici e ben definiti problemi.

Utilizzando l'approccio alternativo e il parsing di XML nel codice può essere altrettanto brutte, e la voglia di impiegare un qualche tipo di XML marshalling/tecnologia vincolante (come JiBX in Java) che permette di convertire il vostro XML direttamente a un oggetto.

Se è possibile utilizzare XSLT in un dichiarativa di stile (anche se non del tutto d'accordo che è un linguaggio dichiarativo) quindi penso che sia utile ed espressiva.

Ho scritto le applicazioni web che utilizzano un linguaggio OO (C# nel mio caso) per gestire i dati/ livello di elaborazione, ma l'output XML piuttosto che HTML.Questo può quindi essere consumati direttamente dai clienti come un API di dati, o come HTML da Xslt.Perché il C# è stato l'output XML che era strutturalmente compatibili con questo uso è stato tutto molto liscio, e la logica di presentazione è stato mantenuto dichiarativa.Era più facile seguire e modificare di inviare i tag da C#.

Tuttavia, come si richiede più logica di elaborazione presso il XSLT livello diventa contorto e prolisso - anche se è "ottenere" stile funzionale.

Naturalmente, in questi giorni ho probabilmente hanno scritto quelle applicazioni web utilizzando un'interfaccia RESTful - e penso di dati "lingue" come JSON stanno guadagnando la trazione in aree che XML è tradizionalmente stata trasformata da XSLT.Ma per ora XSLT è un importante e utile, tecnologia.

Ho speso un sacco di tempo in XSLT e ha scoperto che, mentre è uno strumento molto utile in alcune situazioni, non è sicuramente una soluzione tutto.Funziona molto bene per il B2B fini quando viene utilizzato per i dati di traduzione per leggibili dalla macchina XML di input/output.Non penso che sei sulla strada sbagliata nella tua dichiarazione dei propri limiti.Una delle cose che frustrato a me la maggior parte erano le sfumature nelle implementazioni di XSLT.

Forse si dovrebbe guardare in altri linguaggi di markup disponibili.Credo che Jeff ha fatto un articolo su questo argomento materia di Overflow dello Stack.

HTML è un Umano Linguaggio di Markup?

Vorrei dare un'occhiata a ciò che ha scritto.Probabilmente si può trovare un pacchetto software che fa quello che vuoi "out of the box", o almeno molto vicino, invece di scrivere le sue cose da terra.

Attualmente sto compito di raschiare i dati da un sito pubblico (sì, lo so).Per fortuna è conforme alla xhtml, sono in grado di utilizzare xslt per raccogliere i dati di cui ho bisogno.La soluzione risultante è leggibile, pulito e facile da modificare, se necessario, si verifica.Perfetto!

Ho usato XSLT prima.Il gruppo di 6 .file xslt (refactoring di una più grande) era di circa 2750 linee molto prima che ho riscritto in C#.Il codice C# è attualmente 4000 righe che contengono un sacco di logica;Non voglio neanche pensare a quello che avrebbe preso a scrivere in XSLT.

Il punto in cui ho rinunciato è quando mi sono reso conto di non avere XPATH 2.0 era significativamente male i miei progressi.

Per rispondere a tre domande:

  1. Ho usato XSLT una volta alcuni anni fa.
  2. Credo XSLT potrebbe essere la soluzione giusta in determinate circostanze.(Mai dire mai)
  3. Tendo ad essere d'accordo con la valutazione che è molto utile per i "semplici" trasformazioni.Ma penso come capire le XSLT bene, c'è un caso da effettuare per il suo utilizzo per i più grandi compiti come la pubblicazione di un sito web XML trasformato in HTML.

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

Un luogo dove xslt brilla davvero è la generazione di report.Ho scoperto che un 2 fase di processo, con il primo passo di esportare i dati del report in un file xml, e il secondo passo generare il report di visual xml con xslt.Questo permette per un bel rapporti visivi, pur mantenendo la dati grezzi in giro come un meccanismo di convalida in caso di necessità.

In una precedente società, abbiamo fatto un sacco con XML e XSLT.XML e XSLT grande.

Sì, c'è una curva di apprendimento, ma poi si dispone di un potente strumento per gestire XML.E si può anche utilizzare XSLT su XSLT (che a volte può essere utile).

La Performance è anche un problema (con molto XML di grandi dimensioni), ma che si può affrontare che con l'utilizzo di smart XSLT e fare qualche elaborazione con l' (generato) XML.

Chiunque con una conoscenza di XSLT può cambiare la apearance del prodotto finito, perché non è compilato.

Personalmente, come XSLT, e si potrebbe voler dare il sintassi semplificata un'occhiata (non esplicito modelli, solo un normale vecchio file HTML con un paio di XSLT tag a sputare i valori in esso), ma non è proprio per tutti.

Forse si vuole solo offrire agli autori un semplice Wiki o Markdown interfaccia.Ci sono librerie che, troppo, e se XSLT non funziona per voi, forse XML non funziona per loro.

XSLT non è la fine del mondo in fatto di trasformazione xml.Tuttavia, è molto difficile giudicare in base alle informazioni contenute se sarebbe stata la migliore soluzione al vostro problema o se ci sono altri più efficiente e gestibile approcci.Dire che gli autori possono inserire i propri contenuti in forma semplificata - in che formato?Le caselle di testo?Che tipo di html eri la conversione?Per giudicare se XSLT è lo strumento giusto per il lavoro, sarebbe utile per conoscere le caratteristiche di questa trasformazione in modo più dettagliato.

Mi piace usare XSLT solo per cambiare la struttura di documenti XML.Io la trovo ingombrante per fare tutto ciò che riguarda l'elaborazione del testo e relegare il che per uno script personalizzato che mi può eseguire prima o dopo l'applicazione di un XSLT per un documento XML.

XSLT 2.0 incluso un sacco di più funzioni di stringa, ma penso che non sia una buona misura per la lingua, e non ci sono molte implementazioni di XSLT 2.0.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top