Newsgroup: it.comp.programmare.win32
Titolo: Farsi un DOM o usare MSHTML o MSXML?

Vorrei creare un editor HTML intelligente, ovvero non un notepad molto
avanzato ma uno che interpreta tag html e li tiene in memoria non come unica
stringa ma come oggetti di un b-tree molto avanzato. Per fare ciò devo crearmi
un DOM.
Vedendo che Microsoft ne ha già fatti tanti e li ha anche integrati (a forza?)
nei sistemi di tutti, tramite COM potrei avere accesso a quei 4 oggetti e
quelle 4 interfacce che sono sufficienti a manipolare in grande stile
documenti XML. Parlo di MSXML.DLL, accedibile tramite il comodo msxml.h
scaricabile gratuitamente.
Però ho bisogno di un editor HTML, non XML, e per quanto l'HTML sia simile non
mi va bene (l'XML, per esempio, non supporta tag "unici" come <IMG SRC="xxx">
ma ha bisogno sempre di un tag di chiusura </IMG> o di un <IMG /> che
contrasta con gli standard e l'uso comune dell'HTML.
Esiste poi però, implementato in MSHTML e accedibile, credo, tramite COM, il
DOM che usa IE per caricarsi le pagine, già compreso di parser (grande cosa,
immagino la cosa più difficile da implementare a mano). Ma è troppo vasto! A
me interessano soltanto gli elementi "documento", "nodo", "attributo", "testo"
e "commento", in quanto sarà poi il mio editor html a lavorarci sopra e farli
diventare <IMG>, <H1>, <HREF>, <OBJECT>... In quel dannato MSHTML ci sono
funzioni specifiche per ogni tipo di tag, a me servono solo le generiche. E
poi, soprattutto, non capisco se si tratta il DOM creato utilizzabile
dall'utente per permettere agli script di lavorare sul documento html
correntemente caricato in IE oppure di determinate API per includere una
gestione intelligente degli HTML in qualsiasi programma che ne richieda l'uso,
senza chiamare in causa IE.
La terza alternativa, che mi risolverebbe poi il problema di come gestire
altri formati di file tipo i css, sarebbe quella di crearmi delle interfacce
semplici universali, tipo IUNIDOMDocument, IUNIDOMNode, IUNIDOMAttribute,
IUNIDOMText e IUNIDOMComment, e poi crearmi svariati oggetti che supportano
queste interfacce, solo che uno crea documenti XML (magari è solo un wrapper
verso MSXML), un altro gestisce i css, un altro ancora gestisce un b-tree in
formato proprietario binario, ecc... ecc...
È la soluzione che mi affascina di più, e che probabilmente adotterò, sarà
anche utile in futuro con programmi che non c'entraranno nulla con l'editor
html che sto pensando a avranno bisogno di salvare documenti.
Il problema, a questo punto, sarebbe solo l'implementare un parser, e non ho
conoscenze per farlo :-(
--
Stefano Pettini
Risposte solo sul newsgroup, please.

 conoscenze per farlo :-(
E allora, riusa MSHTML (o altre implementazioni simili, se ne esistono),
incapsulandolo (contenimento e delegazione) nelle tue "affascinanti"
astrazioni di livello superiore.
Alex

 di interoperabilita` con altre applicazioni)
Infatti penso userò sempre un formato XML per i miei documenti, ma, per
esempio, ci sono formati già definiti incompatibili con la sintassi XML. Gli
Style Sheet, per esempio, e lo stesso HTML!
Utilizzare MSXML è una buona idea, visto che è un DOM come si deve (al
contrario di MSHTML che, come ti ho detto e ne sono sempre più convinto,
altro non è che un sistema di interfacciamento a un documento di IE
correntemente caricato, ed infatti non sono riuscito a trovare nessun
comando save, che invece c'è nell'MSXML). Il fatto rimane sempre lo stesso.
Per questioni sintattiche non posso usarlo per lavorare su HTML!
Questo spiega anche perchè esiste il Microsoft XML Notepad (molto carino) ma
non esiste il Microsoft HTML Notepad.
