Errore con i tag XmlWriter in gb.xml

[md9327]

A parte quanto sopra scritto, penso che questa discussione possa chiudersi qui, se tutti sono d'accordo.
Ho provato ad avviare pgDesigner3, e sembra che ora tutto sia tornato al suo posto.

La soluzione è stata trovata, anche se per quanto riguarda la libreria gb.xml c'è ancora da discutere.

Che ne dite?

La lasciamo aperta per quest'ultima libreria?

[sotema]

Secondo me si potrebbe aspettare che Adrien scarichi i sorgenti ed analizzi il bug. Potrebbe quindi postare qui la soluzione o eventuali richieste. Sarebbe un grosso contribut allo sviluppo di Gambas.

@Adrien
Seems that md9327 finally found the solution.
if ya agree we can keep this thread open waiting for your analisys.

[Prokopy]

I haven't finished my analysis, but I noticed one error in your code :

(PgXmlDocument.class, line 79)

Codice: gambas [Seleziona]

Select Case oXml.Node.Type
      '[...]
Case XmlReaderNodeType.EndElement

EndElement is not a node type, but a state, so Node.Type will never return this. You should use the State property instead :

Codice: gambas [Seleziona]

Select Case oXml.State
      '[...]
Case XmlReaderNodeType.EndElement'Ok

And, another question, are all your files encoded in UTF-8 ?

[sotema]

I haven't finished my analysis, but I noticed one error in your code :

(PgXmlDocument.class, line 79)

Codice: gambas [Seleziona]

Select Case oXml.Node.Type
      '[...]
Case XmlReaderNodeType.EndElement

EndElement is not a node type, but a state, so Node.Type will never return this. You should use the State property instead :

Codice: gambas [Seleziona]

Select Case oXml.State
      '[...]
Case XmlReaderNodeType.EndElement'Ok

And, another question, are all your files encoded in UTF-8 ?

Welcome Adrien,
I am here just to avoid a basic misunderstanding.
When md9327 starts writing pgDesigner3 the component available in Gambas to treat xml file was gb.xml. It was based on libxml library.
When you introduced the new component for xml management the old one was renamed into gb.libxml and the new one named gb.xml
The code in pgDesigner3 works perfectly with gb.libxml, but fails with gb.xml
Obviously something changed in the way xml documents and their structure is treated by gb.xml.
That has broken the project.
what I suspect is md9327 needs to switch the component into the project properties from gb.xml to gb.libxml. Otherwise he must implement a different methods and code.

Xmlreader.State does not exists in gb.libxml

this means that the components are not equivalent and md**** have to make a lot of correction to use the new component

[md9327]

Perdonatemi, in particolare perchè scrivo solo in Italiano... 

Come indicato da sotema, pgDesigner3 funziona perfettamente con gb.libxml, mentre con gb.xml NON funziona.

Quando contenuto nel codice di pgDesigner, è derivato da un'analisi approfondita della libreria gambas, e già all'epoca avevo riscontrato problemi quando un tag veniva chiuso direttamente senza un valido contenuto. Una volta capito come aggirare il problema, ho scritto il codice presente in pgDesigner. I controlli sulla proprietà ".Node.Type", in particolare il controllo di "XmlReaderNodeType.EndElement", è dovuto proprio dalla verifica dell'apertura/chiusura dei vari elementi, in modo da catturare correttamente eventuali valori.
"EndElement" viene scatenato proprio dall'intercettazione di un tag di chiusura dopo una serie di subelementi.
I file xml che sono usati nel programma sono stati adattati in base alle possibilità della libreria, e cercando di semplificare il più possibile la loro gestione.
Sempre riguardo alle strutture xml, giornalmente tratto svariate tipologie, spesso molto complesse rispetto a quelle usate in pgDesigner, questo per dire che ho ben presente le particolarità di questo tipo di file.
XmlReader e XmlWriter semplificano molto la gestione di file xml non eccessivamente complessi, come quelli utilizzati in pgDesigner.
Per attività più complesse sarebbero invece molto utili le classi contenute nella nuova libreria gb.xml, che rispecchia molto la logica usata in altri linguaggi. Spero quanto prima venagno rese stabili. Mi complimento per il lavoro che si stà facendo su questa libreria.

Comunque, capito che il problema era la libreria, ho effettuato uno switch della stessa, e ora pgDesigner funziona nuovamente.

Riguardo al contenuto dei file, uso stringhe puramente ASCII, codificando opportunamente i caratteri fuori intervallo, più o meno come viene fatto per HTML.

[Prokopy]

Sotema,
no, the two component are not fully equivalent. New properties and methods were added. But the component should behaves as libxml with the same code.

This is the reason why these changes were commited on the development version. So you may expect bugs until the stable version is released.

The State/NodeType problem has been solved in the last revision.

It seems there are other problems, with XmlWriter, but I need more precisions !

Faccio notare che anche XmlWriter funziona piuttosto male, aggiunge spazi indesiderati, interpreta male i tag, gli elementi e le properties.

I note that XmlWriter works pretty bad, adds unwanted spaces, misread tags, elements and properties.

This is not enough for understanding where is a bug.

[sotema]

The State/NodeType problem has been solved in the last revision.

Do you mean #4838?

I note that XmlWriter works pretty bad, adds unwanted spaces, misread tags, elements and properties.

This is not enough for understanding where is a bug.

Only md**** can provide help about it. I dont know which tests he made before write the code for xml write/read inside pgdesigner.

[Prokopy]

The State/NodeType problem has been solved in the last revision.

Do you mean #4838?

Yes.

[md9327]

I test che ho fatto, a seguito del malfunzionamento riscontrato, sono inserite in questa discussione.

Per le prove ho anche usato il codice che ho trovato nei sorgenti di gambas3 (#4838), in particolare la lettura del semplice file trovato sempre nei sorgenti test.xml. Già il test ha riportato i problemi che ho descritto, ovviamente usando la libreria gb.xml.

Una volta modificato l'elenco delle librerie nel progetto, passando da gb.xml a gb.libxml, il tutto ha ripreso a funzionare. Questo vuol dire che in realtà esistono differenze tra le due librerie, e in particolare con le classi XmlReader e XmlWriter.

Per riassumere i test con la libreria gb.xml, e le anomalie riscontrate:

a) la classe XmlReader sembra leggere il file, senza dare errori, ma poi nel loop di lettura non rileva nulla. Solo una cosa ho notato, ovvero che Read() ritorna il valore di 7, che corrisponde al fine documento, ovvero ad eof.
b) la classe XmlWriter aggiunge spazi indesiderati nel contenuto dei tag (o elementi), formattando inoltre il file in maniera completamente diversa da come mi aspettavo, ovvero inserisce il carattere di LF dopo lo StartElement, dopo il valore dell'elemento (aggiungendo spazi in testa e in coda), e dopo lo EndElement.

Queste anomalie non accadono con le stesse classi contenute in gb.libxml !

I test sono stati effettuati sia utilizzando il codice di esempio e il file xml contenuti nei sorgenti di Gambas3 (build #4838), sia utilizzando il codice che utilizzo in pgDesigner3. Lo stesso codice e la stessa logica è stata adottata in tutte le release di pgDesigner (1, 2 e 3), e dopo vari studi per trovare il miglior modo per utilizzare la libreria.

Devo però dire, e credo di averlo già accennato, che il cambiamento di nome di una libreria, a prescindere se il codice di alcune classi sia uguale o meno, può portare a svariate conseguenza, com'è appunto e puntualmente accaduto. Questo è ovviamente un mio pensiero, ma è adottato in tutti i linguaggi conosciuti. Al massimo, se una libreria và ad implementare in todo le funzionalità di una esistente, aggiungendo magari ulteriori proprietà, credo sia più opportuno renderla obsoleta, segnalando la cosa a caratteri cubitali... 
Questo è ovviamente un mio pensiero, ma credo sia il caso di prenderlo in considerazione, onde evitare problemi a chi segue questo bel linguaggio che è Gambas! 

[sotema]

I note that XmlWriter works pretty bad, adds unwanted spaces, misread tags, elements and properties.

This is not enough for understanding where is a bug.

In order to make your analisys easier i'll try to face one problem at a time
by launching the very simple program attached, once with gb.xml and once with gb.libxml component you can see the different way the file is formatted. With gb.xml the format is very ugly.
Into the tar i putted also the output produced by both gb.libxml and gb.xml

[md9327]

Grande sotema, vedo che hai testato anche tu la cosa... 

[sotema]

Speriamo che Adrien legga il topic, altrimento la invio alla Mailing list
 

[sotema]

aggiornamento,
ho inoltrato la segnalazione alla mailing-list.
Durante le prove ho però notato che aprendo i file con applicazioni che interpretano xml (ad esempio firefox) il testo è formattato correttamente. 

[md9327]

Se parli di XmlWriter, il file lo crea corretto, nel senso che tutti i tag sono aperti e chiuso nel modo corretto. Il fatto che Firefox legga correttamente il file, significa solo questo.

Se però dai un'occhiata al contenuto (cosa che hai testato anche tu stesso), vedi la differenza tra i file creati dalle due classi delle due librerie.
La vecchia libreria crea un file corretto, pulito, e non introduce nulla oltre a quello che inserisci tu da codice. La formattazione, se selezionata, viene effettuata bene, indentando correttamente i tag, seguendo la gerarchia.

[Prokopy]

Hi,

sorry for the time I took to reply, I have a lot of work this week (exam period).

I'm still looking for where is the bug on XmlWriter.
But for XmlReader, I still have no idea. Did you try the piece of code you gave me outside your application ?