--------------21459155CD759AD7F8281563
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Germano Rizzo wrote:
>
> Non hai tutti i torti, anzi hai ragione! Via, via, via i punti 2 e 4,
> via, via, via! Cmq, lo stesso credo sia utile avere un tool di conversione
> che tutti possano usare, non basato su server web... insomma, io voglio
> "vedere come viene"! E' vero che porta ad abusi... ma se strutturiamo i tag
> in maniera corretta, beh... poi sta alla coscienza di ognuno! E ci siamo
> sempre noi a correggere!
>
> > Anziche' sull'anteprima preferirei invece concentrarmi sulla validazione
> > del documento, decisamente piu` utile a mio modo di vedere :-)
> Approvato! :) Aggiungiamo alle specifiche?
> Un saluto,
> Mano :)
>
Io non credo che l'anteprima possa generare degli abusi. Il nostro non è html
con l'aggiunta di estensioni proprietarie valide per un browser e non per gli
altri, è un insieme di tag che devono essere utilizzati secondo le regole
stabilite nel DTD. Se il documeto xml è ben formato e valitato allora perchè non
mostrarlo in anteprima? Tra l'altro il codice html per l'anteprima verrebbe
generato dagli stessi filtri xsl utilizzati per la composizione finale del
journal.
Sono daccordo sul fatto che la visualizzazione della pagina dipenda dal browser,
ma, alla fine, comunque con un browser vanno visualizzate. In anteprima vedrei
solo la pagina per come mi verrà poi mostrata. Lo sfizio dell'anteprima (se
approvato) non dovrebbe essere difficile da realizzare, secondo me potrebbero
esserci 2 alternative (simili).
* libxslt (+ libxml):
l'articolo è salvato in xpj (che è xml), viene processato tramite le
libxslt applicando i filtri del journal e convertito in html e mostrato (magari
tramite geko)
* utilizzare direttamente geko (magari chiedendo l'aiuto agli sviluppatori
originali), pathcarlo per fargli processare internamente i file xml/xsl (e fare
come IE, che se non sbaglio, è l'unico browser che al momento processa e
visualizza file xml/xslt)
Nicola
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Germano Rizzo - mano@pluto.linux.it
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Pluto FSUG member - www.pluto.linux.it
> Linux Registered User #120637
> PGP/GPG Public Key at
> http://gnomermind.sf.net/pubkey.txt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> An rud is annamh is iontach
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> _______________________________________________
> pluto-devel mailing list
> pluto-devel@lists.pluto.linux.it
> http://lists.pluto.linux.it/mailman/listinfo/pluto-devel
--------------21459155CD759AD7F8281563
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Germano Rizzo wrote:
Non hai tutti i torti, anzi hai ragione! Via, via,
via i punti 2 e 4,
via, via, via! Cmq, lo stesso credo sia utile avere un tool di conversione
che tutti possano usare, non basato su server web... insomma, io voglio
"vedere come viene"! E' vero che porta ad abusi... ma se strutturiamo
i tag
in maniera corretta, beh... poi sta alla coscienza di ognuno! E ci
siamo
sempre noi a correggere!
> Anziche' sull'anteprima preferirei invece concentrarmi sulla validazione
> del documento, decisamente piu` utile a mio modo di vedere :-)
Approvato! :) Aggiungiamo alle specifiche?
Un saluto,
Mano :)
Io non credo che l'anteprima possa generare degli abusi. Il nostro non
è html con l'aggiunta di estensioni proprietarie valide per un browser
e non per gli altri, è un insieme di tag che devono essere
utilizzati secondo le regole stabilite nel DTD. Se il documeto xml è
ben formato e valitato allora perchè non mostrarlo in anteprima?
Tra l'altro il codice html per l'anteprima verrebbe generato dagli
stessi filtri xsl utilizzati per la composizione finale del journal.
Sono daccordo sul fatto che la visualizzazione della pagina dipenda
dal browser, ma, alla fine, comunque con un browser vanno visualizzate.
In anteprima vedrei solo la pagina per come mi verrà poi mostrata.
Lo sfizio dell'anteprima (se approvato) non dovrebbe essere difficile da
realizzare, secondo me potrebbero esserci 2 alternative (simili).
* libxslt (+ libxml):
l'articolo è salvato
in xpj (che è xml), viene processato tramite le libxslt applicando
i filtri del journal e convertito in html e mostrato (magari tramite geko)
* utilizzare direttamente geko (magari chiedendo l'aiuto agli sviluppatori
originali), pathcarlo per fargli processare internamente i file xml/xsl
(e fare come IE, che se non sbaglio, è l'unico browser che al momento
processa e visualizza file xml/xslt)
Nicola
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Germano Rizzo - mano@pluto.linux.it
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pluto FSUG member - www.pluto.linux.it
Linux Registered User #120637
PGP/GPG Public Key at
http://gnomermind.sf.net/pubkey.txt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An rud is annamh is iontach
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
pluto-devel mailing list
pluto-devel@lists.pluto.linux.it
http://lists.pluto.linux.it/mailman/listinfo/pluto-devel
--------------21459155CD759AD7F8281563--