Ciao , apprezzo il contributo. La strategia del javascript e del parsing direttamente nella pagina del browser e' cosa nota.
Se cerchi in mezzo alle slides, la troverai da me citata nella mia presentazione di qualche anno fa' a Bologna (convegno gfoss). Questo solo per dirti che la conoscevo e in partenza avevo pure ipotizzato di andare per quella strada. Ma poi la ho esclusa perche' era troppo complicata per un utente normale. Io cercavo roba ancora piu' semplice e a massimo risultato e compatibilita'. Se ti interessa tale strategia, in tale slides troverai una citazione e dei links interesanti. Infatti nella nostra infrastruttura ioho impiegato la strategia del parsing al volo del XML su browser in javascript che te citi. Per generare una pagina html di risposta a partire da una query syu un server WFS che come saprai risponde in GML che e' a tutti gli effetti un XML e quindi parserizzabile con un processore xslt. Parserizzare un GML e' un po' difficile per tutti i namespaces che ha, pero' alla fine deisalmi e' solo una lista di valori in fila indiana. Uno dei quali e' una geomatria. QUindi abbastanza semplice da processare in xslt e riportare in forma tabellare (in html). Ma soprattutto un GML e' sempre uguale a se stesso. Invece la scheda xml di metadato e' tutta una altra storia. Puo' non essere mai uguale, a seconda della sua provenienza e prevede tantissimi tags in piu', tra loro anche nidificati e anche con svariata molteplicita' e a volte cisono o non ci sono. Un bel puzzle in cui districarsi con un xslt. NOn ho comunque supportato il 100% dei possibili tags diuna scheda dimetadato, ma son sceso abbastanza in profondita, studiandomi sia le schede che avevano noi (tra le piu' complicate), sia alcune riprese da RNDT e anche alcune generate dall'editor Inspire el JRC. E in alcuni casi ho pure customizzato l'xml per inserirci dei tags che volevo supportare per avere un xslt che fosse in grado di masticare quanto piu'possibile tutti i tags piu' che immaginavo avrebbero mai potuto comparire in una scheda compilata che ci poteva ritornare. In merito alla funzione "position": Certamente te saprai che la funzione position non e' un contatore, ma riporta invece la posizione del tag. Il che puo' coincidere con il valore di un contatore se i tags del xml sono in fila indiana uno dopo l'altro e tutti al medesimo livello. Ma la scheda XML di una scheda di metadato puo' non essere cosi'. Anzi non lo e' quasi mai. A meno che uno non compili solo quei 4-5 valori che sono nel primo livello e che pero' sono sempre uguali. Per semplificare il discorso per i non addetti: Se il file XML e' semplice il comando position riporterebbe: 2, 3, 4, 5 e quindi rappresentando un progressivopoteva anche andare bene. Ma poi in qualche caso , (quasi sempre in realta0) salta fuori una qualche nifdificazione che fa saltare la posizione del tag interferendo nel valore del progressivo. Per intendersi in una scheda di metadato il position ritornerebbe qualcosa di questo genere: 2, 6, 13, 34, 45 Certamente vi e' la progressivita' , ma non mi piaceva mostrare un progressivo dopo il 2 mostrava il 6 e non il 3. : Per cui ho soprasseduto all'uso del position. Un vero progressivo si riesce ad avere con l' xslt 20 che purtroppo non e' molto diffuso e a quel che so' non esiste un processore in forma di eseguibile su piataforma windows ps: Il Java lo avevo escluso a priori per tutta una serie di altre considerazioni. A. Il 13 novembre 2015 17:35, ptagliolato <paolo.tagliol...@gmail.com> ha scritto: > Perché non usare direttamente il processore xslt del browser? > Non sono riuscito a vedere il tuo codice in github, ma se si tratta di un > xslt e in particolare in versione 1, penso sia la strategia più "light". > Con quasi tutti i browser, tra l'altro, se un documento xml specifica uno > "stylesheet" (ossia: un documento xslt) il contenuto viene automaticamente > convertito con il foglio di stile xsl. > La direttiva va all'inizio del documento xml, per intenderci dopo la prima > riga > <?xml version="1.0" encoding="UTF-8"?> > ed è: > <?xml-stylesheet href="md2html.xsl" type="text/xsl"?> > > A questo punto si potrebbe anche fare a meno di salvare l'html prodotto e > basterebbe avere una copia dei file originali in xml con questo preambolo. > Basta in tal caso lavorare con un processore di file di testo (penso a awk, > per esempio). > > In alternativa si può accedere al motore xslt del browser via Javascript. > > P.S. per la numerazione delle righe io penserei alla funzione position() che > è compatibile con xslt 1 e che puoi usare sia se applichi dei template > (apply-template) o se realizzi dei cicli su delle liste di nodi (for-each). > > > > -- > View this message in context: > http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Procedura-XSLT-per-convertire-una-scheda-metadatao-XML-in-HTML-tp7594995p7595038.html > Sent from the Gfoss -- Geographic Free and Open Source Software - Italian > mailing list mailing list archive at Nabble.com. > _______________________________________________ > Gfoss@lists.gfoss.it > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non hanno relazione diretta con le posizioni > dell'Associazione GFOSS.it. > 786 iscritti al 30.9.2015 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Gfoss@lists.gfoss.it http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 786 iscritti al 30.9.2015
