Parsing xml: DOM vs SAX

[Nuke]

Salve a tutti, premetto che ho gia cercato in modo infruttuoso un po' ovunque, ma volevo chiedere se qualcuno di voi sa darmi delle informazioni riguardo il modo di gestire il parsing di un file xml da flash.
Ho capito che esistono due modi differenti il DOM e il SAX per "leggere" e interpretare i dati da un file xml, ora volevo sapere se con flash è possibile scegliere una di queste due modalità di "lavoro" oppure è gia predefinito un sistema senza possibilità di scelta.
Da quanto ho provato e ho avuto esperienza credo che il funzionamento del parsing con flash sia di tipo DOM.

Qualcuno ha notizie in merito o sa darmi informazioni maggiori?
Grazie a chi saprà darmi una mano.



P.s la piattaforma flash è inifluente per me: ho a disposizione da flash 4 a flash mx 2004 pro.

[flash_mx2]

no, in flash puoi solo usare DOM (e sottolinerei "per fortuna"... ma io sono di parte, il SAX lo odio con tutto me stesso).

questo anche perchè in flash il caricamento del file è unico, non c'è modo di caricare il file ed effettuare un parsing durante il suo caricamento (base essenziale per il funzionamento di SAX).

[Nuke]

grazie mille per la risposta,
Al di la di considerazioni di quale sistema sia meglio, ne approfitto allora per chiedere se qualcuno conosce un metodo efficace per gestire una grossa quantità di dati in formato xml (diciamo con file da dimensioni di 2 mega in su..) su un sistema "stand alone"... tipo cd autoavviante.
In pratica sto cercando di capire come realizzare cataloghi multimediali con flash o director usando un "pseudo-database" in xml.

Attualmente il mio grosso problema è gestire il blocco che avviene regolarmente quando tento di elaborare cosi tanti mega di dati.. la soluzione attuale è stata quella di dividere in blocchi piu piccoli i vari file xml... ma dovendo prevedere grosse quantità di dati la cosa non è ne agevole e nemmeno troppo professionale (a mio avviso)

Immagino che la risposta al mio quesito sia quella di non usare flash o director per un simile progetto, ma volendo raggiungere un risultato accettabile quali altri "escamotage" posso provare?
grazie come sempre in anticipo..

[flash_mx2]

al di là cmq delle considerazioni sull'uso di un file XML così grosso... non sarebbe utile dividerlo?

cmq... alla fine puoi "spezzare" il parsing di flash, altrimenti collasserebbe.. quindi fargli fare il parsing di TOT nodi alla volta

[Nuke]

La soluzione che sto usando attualmente è di dividere gia il file in piccoli xml, diciamo che esporto in xml gia delle "query" di dati prese dall'xml principale.
Ovviamente dovendo aggiornare i dati, mi tocca ogni volta rivedere e ricreare i vari xml, se è l'unica soluzione farò cosi.

Una cosa invece non saprei come farla: tu hai scritto:

cmq... alla fine puoi "spezzare" il parsing di flash, altrimenti collasserebbe.. quindi fargli fare il parsing di TOT nodi alla volta

come faccio a dire, tecnicamente parlando, a flash di fare questa cosa?

[flash_mx2]

con un semplice counter sui nodi letti... quando il counter arriva ad un certo numero interrompi il parsing e lo riprendi dopo un tot di tempo (basta anche un millesimo, solo per impedire al player di bloccarsi)

[Nuke]

Ok, grazie per le dritte.. ci lavorerò su

ciauz

[panta]

dici che basta un delay così basso?

[flash_mx2]

certo... perchè non è quello il problema.. (magari non un millesimo ma 50), l'importante è spezzare la routine prima che possa rallentare il processo

il problema è quanto si stressa la CPU nei vari processi di parsing. se si riesce a non farla impallare mai allora il parsing sarà indolore (ovviamente più lungo come tempi)

c'è cmq da tener conto delle diverse CPU su cui girerà il sistema..

[panta]

certo, ho capito

p.s.: ho iniziato a studiare il php... fico!! mi sa che l'asp lo sbatto in cantina

ciauz