From: Daniel Veillard (Daniel.Veillard@w3.org)
Date: Tue Oct 05 1999 - 18:14:14 EDT
Hi Kristian,
> I've been working with the HTML parser that comes with gnome-xml, and
> after debugging my own code for a while because of some weird nesting
> of lists, I realized that the HTML parser doesn't infer </li> when
> current element is <li> and a new <li> is seen. Shouldn't it do so?
> I added "LI" to the "LI" entry in the htmlStartClose array in
> HTMLParser.c, line 302, and it all worked allright.
Ah, maybe I forgot it, thanks for the tip,
> By the way, I would really like to use the HTML parser with the SAX
> interface, however this isn't possible, since the parser looks at the
> currently open element to infer close tags, and the element stack is
> maintained by the DOM building default SAX handler. On the other hand
> I cant maintain the element stack in my SAX handler, since I dont have
> access to the parser context there.
Ouch, right, I need to move those data structure to the parsing
context ...
> But actually I need the DOM tree later on anyway, so I would be happy
> if I could just add a SAX handler, instead of replacing to default
> one. An elegant way to implement multiple SAX handlers could be to do
> a meta SAX handler, that has a list of SAX handlers and just
> propagates the callback to each of the handlers in the list.
I would rather suggest that you provide your own SAX handler which
then call all the original SAX handler function, then do your own
processing. I would not have to change data structures which would
break binary compatibility :-\
> Finally, how about a way to attach custom data to xmlNode? The
> application I'm thinking of is that, suppose you have an xmlDoc and a
> visualisation using some interface objects (canvas items, widgets,
> whatever). What I'd like to do, is to have pointers from the xmlNodes
> to the interface objects, so that when the xmlDoc changes I can follow
> the pointer and change the visualisation accordingly. I suspect this
> is the kind of functionality you'd have to support if you were to
> export the DOM tree using gdome (I haven't studied this in detail,
> though). Is there something I'm missing, how is this usually done?
There is a couple of fields dedicated to that and present at the
beginning of most exportable data structures. Corba can be implemented
withnonly one poiter but there is two so you should be able to use at
least one of those:
---------------------------------
void *_private; /* for Corba, must be first ! */
void *vepv; /* for Corba, must be next ! */
---------------------------------
Daniel
-- Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks : Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind, Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML, http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe. ---- Message from the list xml@rufus.w3.org Archived at : http://rufus.w3.org/veillard/XML/messages to unsubscribe: echo "unsubscribe xml" | mail majordomo@rufus.w3.org
This archive was generated by hypermail 2b29 : Wed Aug 02 2000 - 12:29:48 EDT