Newsgroup: it.comp.programmare.win32
Titolo: Il document object model dell'HTML dinamico

Mi servono maggiori dettagli riguardanti il document object model dell'HTML
dinamico ed in particolare il suo utilizzo con MFC.
Grazie

 dinamico ed in particolare il suo utilizzo con MFC.
La MSDN contiene un mucchio d'informazioni sul DOM dell'HTML.
Ad esempio, parti dall'articolo "The Dynamic HTML Object Model"
della solita, eccellente Nancy Winnick Cluts (e` sotto Backgrounders,
Internet/Intranet/Web, Authoring/Programming).  Poi, guarda
"Dynamic HTML" sotto lo "Internet Explorer Platform SDK".
Inoltre, "Should Your Next UI Be Written in Dynamic HTML?"
(la colonna del "Dr GUI" del 3 Novembre 1997), ecc ecc.
Il supporto MFC per questo non e` eccezionale... le MFC non
vengono "veramente ben aggiornate" da un pezzo (ma un
pezzo!).  Hai una CHtmlView::GetHtmlDocument che ti ritorna
l'IDispatch del documento, ma li` le MFC si fermano, piu`
o meno, sigh.
Ti conviene probabilmente usare invece le comode funzioni
di Visual C++ per l'accesso "nativo" a COM, o la piu` potente
"ATL".
Comunque, ci sono due buoni esempi di approcci alternativi
nell'MSDN.  L'esempio "Driller" accede al DOM attraverso le
funzionalita` di MFC; l'esempio "WalkAll" vi accede a livello
piu` basso, implementandosi tutto quel che serve "a mano",
in un'applicazione di console che usa MSHTML per caricare e
parsare un documento HTML, implementa lei stessa alcune
interfacce COM (per sapere dall'MSHTML quando il caricamento
e` finito, e per inibire l'esecuzione di eventuali script sulla
pagina caricata), infine "cammina" l'intero OM del documento
cosi` caricato.
Alex

 pezzo!).
A questo proposito, e` da un po' che mi chiedo: la M$ ha intenzione di droppare
lo sviluppo delle MFC? Il sospetto viene spontaneo, pensando che in diversi
anni sono passate solo dalla versione 4.0 alla 4.2 e le modifiche sono state
del tutto secondarie.
Le MFC non sono certo un capolavoro di programmazione, ma trovo che in molti
casi facciano bene il loro lavoro. Secondo me se i piani della M$ sono quelli
di far convertire tutti ad ATL, incontrera` molte resistenze. Da parte mia
senz'altro. ;-)
--
Bye! Lorenzo Lutti (
http://www.geocities.com/SiliconValley/Peaks/6258/
)

Lorenzo Lutti <lorenz...@DOHlibero.it> wrote in message
81oj54$hpc$1...@fe1.cs.interbusiness.it...


 senz'altro. ;-)
Condivido la tua valutazione di MFC, ci sono cose, come il print preview,
che ATL non mi da` e non mi sognerei neppure di implementare da zero.
Sicuramente SE MS si decide a "congelare" MFC, come Borland/Inprise
fece a suo tempo con OWL, lo fara`, ancora come Borland/Inprise, per
passare ad un altro framework piu` moderno -- per Borland fu VCL.
Il progettista e architetto capo di VCL lavora per MS da un pezzo, e
ivi ha progettato e realizzato le "WFC", le "Windows Foundation
Classes", che, egli sostiene, sono VCL migliorate da tutto quello che
imparo` facendo, appunto, VCL.  Le WFC per ora sono accessibili
solo da Visual J++ (versione 6), non da altri linguaggi, ma, come e`
chiaro, non e` difficile rendere accessibile uno stesso framework da
piu` linguaggi (come VCL, inizialmente accessibile solo da Delphi, fu
poi reso accessibile anche da C++ col prodotto Builder).
Chi vivra`, vedra`...
Nel frattempo, ATL sono e restano un eccellente framework
leggerissimo, basato su eccellenti tecniche C++ avanzate, per
la costruzione, soprattutto, di componenti (per la GUI, ecc, esse
incapsulano in pratica solo le API di Win32).  C'e` una certa
soddisfazione a scrivere un componente COM "perfetto" (dual
interface, multi-threading, auto-registrantesi e deregistrantesi,
ecc ecc), in una DLL di 28K senza bisogno di alcun "runtime
DLL", in tutto in un'oretta o due (come ho fatto di recente per
un componente "zipper" che, usando le librerie gratuite di
Infozip, permette a clienti automation di scrivere un .ZIP)...
Le applicazioni si possono sempre mettere insieme in Python
incollando componenti cosi` scritti e una GUI in HTML
Dinamico...:-)
Alex