XSLT lato client

Ho convertito tutto il mio sito in XML/XSL e mi piacerebbe conoscere tutti i problemi attuali con l'esecuzione di XSLT lato client.XSLT lato client

Qui ci sono quelli che già conosco (da esperienze di prima mano):

file XSL tra domini (si tratta di un problema di sicurezza e il browser non croce)
disable-output-escaping (questo non funziona in FF ... lo considerano un problema di sicurezza)

anche per quanto riguarda il supporto del browser questo è tutto quello che so di:

Opera 9+
FF 1.0+
SF 2.0 + (posso sbagliarmi su questo)
Chrome
IE 6,0 +

Tutti gli altri possono essere utili :)

Edit:

per quanto riguarda la seconda insidia c'è una soluzione decente che consente di passare al vostro xhtml xsl. Funziona effettivamente convertendo e assicurandosi che il tuo XHTML sia XML valido e inserendolo nel tuo XML come XML. Quindi nel tuo XSL copi il xml;) e lo metti in uscita come XHTML.

fonte

2009-05-08 Chad Scira

Sono molto curioso anche di questo. Mi piace molto usare il lato client xslt e non ho mai avuto problemi con esso, ma mi sono sempre chiesto se ci fossero degli svantaggi. – Zifre

È troppo bello per essere vero :). La possibilità di scaricare tutta la generazione di template sul client ... E lasciare che memorizzino il template nel cache ... È totalmente geniale. Nel 2004 era supportato quasi da browser, nel 2009 ... lo è, da quello che ho capito. –

Perché non usare XHTML come base e quindi applicare le trasformazioni da lì? Perché iniziare con XML? Utilizzerai anche altri standard web come CSS o cose come JavaScript e immagini di base? Ogni file aggiuntivo causerà problemi di prestazioni fino a quando non viene memorizzato nella cache sul lato client. – JamesEggers

Velocità: Il browser ha bisogno di applicare la trasformazione XSLT prima del rendering HTML, quindi l'utente dovrà aspettare più a lungo per vedere la pagina. I motori XSLT utilizzati dai browser potrebbero non essere di prim'ordine. Su Mac OS X, il browser potrebbe bloccarsi mentre l'XML viene trasformato e causare il cursore "spinning beach ball", pertanto l'utente potrebbe colpire lo schermo e ferirsi.
Accessibilità: Che dire dei browser non in quel set, come gli screen-reader? Gli utenti sono importanti per te?

fonte

2009-05-08 18:56:41

Stavamo scaricando tutti i template di generazione sul client (risparmiando così una grande quantità di CPU), ho una lista di browser che so che l'XSLT funziona con così gli mando l'XML/XSL effettivo. Se un browser non si trova sulla lista bianca, il server esegue l'XSLT per loro e invia HTML. Grazie però, aggiungerò questo alla mia lista pro/contro. –

Non sono sicuro di essere d'accordo con l'affermazione generale che sarà _always_ essere più lento eseguire la conversione xslt/xml sul client: questo potrebbe (e molto spesso in pratica) significare meno cose da caricare sul n/w (il xsl/xml potrebbe essere più piccolo del risultante html/xhtml): a seconda di come viene confrontato il meccanismo (ad esempio la conversione XSLT JSP/ASP/lato server) - questo approccio lato client potrebbe effettivamente scaricare il tempo di elaborazione dal server al client ... e dovrebbe scalare meglio con più utenti simultanei ... – monojohnny

Ho trovato che i parametri di passaggio a xsltfiles sono difficili da mantenere in grado di eseguire il crossbrowsing. Ora supporto FF e IE ma Chrome è caduto per questo ..

fonte

2009-05-08 19:03:42 Peter

hai un codice di blocco come esempio, sono riuscito a farlo funzionare bene in chrome. –

Sì, ma Chrome non era troppo importante per noi, quindi l'ho lasciato fuori. for (i = 0; i Peter

Forse sono fuori, ma quando ho letto "XSLT lato client", ho assunto la questione sottoposta alla semplice XML -??> Traduzione XHTML con un XSLT statica collegata tramite un piuttosto che il motore XSLT JavaScript. In tal caso, il passaggio dei parametri è irrilevante poiché l'unico set di input è un documento XML. –

Il file XSLT è un altro oggetto che deve essere scaricato e il browser recupererà solo 2 o 3 elementi in parallelo. La mia esperienza è che le prestazioni complessive (download e generazione) sono notevolmente più lente.

Inoltre, a seconda della complessità e della ridondanza dei dati, è possibile che si stia scaricando molto più del necessario - vale a dire. se l'HTML era già stato reso.

fonte

2009-05-11 08:56:40 paul

Non penso che questo sia un argomento valido. Non usi CSS perché un altro file deve essere scaricato? Può essere messo in cache proprio come i CSS. –

@Chad Stai dicendo che il tuo XSLT non conserverà gli attuali standard web come i CSS? XSLT trasformerà il tuo file XML in HTML e un design basato su tabelle o userà i CSS? Questo è un argomento molto valido secondo me, dal momento che se stai prendendo XML e lo converti in HTML ma non usi gli standard web, allora potresti sbagliarti. Inoltre, se il tuo obiettivo è convertire il tuo contenuto HTML in un formato diverso, magari usando XHTML e poi trasformandolo, potrebbe essere un'opzione migliore. – JamesEggers

Utilizzerei tutte le tecnologie web. CSS (progettazione), XSL/XHTML (struttura), XML (dati), JS (comportamento). La quantità di separazione dei dati è bella. –

Sul fronte delle prestazioni ... considera che la maggior parte dei client in questi giorni ha 2 CPU e 2 GB di RAM ciascuno, e che la maggior parte dei server non ... Hanno due CPU + 2 GB per client. Quindi è certamente logico che scaricare le trasformazioni XSLT dovrebbe migliorare la scalabilità e la cache di CSS + XSLT + JS dovrebbe ridurre il traffico complessivo.

Detto questo, ho provato a utilizzare XSLT per produrre XHTML contenente SVG in passato e ho avuto un errore epico. La pagina più grande era semplicemente troppo grande (più di 3000 voci in un indice) e IE utilizza un DOM per eseguire la trasformazione XSLT, che fa in modo che inizi a cestinare. Le stesse trasformazioni fatte in xerces-j (sul server, sulla stessa finestra di sviluppo) erano circa 1000 volte più veloci.

E 'alta volta che il browser-scimmie ottenuto con il programma ;-)

una discussione interessante. Grazie per averlo sollevato.

Cheers. Keith.

fonte

2009-05-17 08:14:47 corlettk

Devo ancora provare SVG, perché non è un browser incrociato. So che c'è un plugin che Adobe fornisce, è una tecnologia così bella. http://raphaeljs.com/ <- soo cool ... –

mi chiedo come va 8 anni dopo, P –

lol, sì 8 anni dopo. XSLT esegue ancora rendering. –

ho lavorato circa 1 anno in un progetto in cui abbiamo utilizzato XSLT + XML> HTML (anche se solo sul lato server)

il grave inconveniente che ho incontrato: non ci sono buoni strumenti per la generazione di XSLT che si affacciano verso sviluppo web. nessuna anteprima di html. nessuna convalida. il xslt risultante era un disastro totale che nessuno poteva capire. non è tanto il difetto dei designer xslt, quanto piuttosto il risultato del modello di elaborazione xslt.

la stratificazione tra xslt/xml/urls diventa più complicata di quanto dovrebbe essere. non è possibile programmare programmi orientati ai componenti.

spesso erano necessari più file xslt, questo porterebbe a molti download sul lato client. altrimenti porterebbe a una massiccia duplicazione del codice durante il progetto.

lo vedrei come una forma di ottimizzazione iniziale. inizierai utilizzando una struttura web "normale" come wicket, jsf, arazzo, gwt ecc., più tardi se si scopre che la preformance dei tuoi server è legata alla cpu potresti riscrivere le parti più spesso utilizzate in questo modo.

otoh, ha reali vantaggi se è necessario fornire sia un'interfaccia xml api + un'interfaccia html.

fonte

2009-05-17 15:01:08

fondamentalmente ho sostituito smarty (un motore di template PHP) con XSLT lato client. E così facendo ho dovuto isolare completamente i dati, che è una cosa meravigliosa. Ad esempio, ora posso scrivere facilmente un'interfaccia mobile, perché tutto è separato. Fino ad ora ho detto che c'è una curva di apprendimento, ma in pratica il tuo futuro è la prova della tua applicazione se usi questo metodo. –

risposta

Problemi correlati