[Libxmlplusplus-general] resume of one day's work

[Stefan S. <se...@sy...>]

hi there,

I'v just checked in the latest bits and pieces of today's round
of enhancements. Here is a list:

* create a 'Document' type
* make 'Attribute' a subclass of 'Node'
* enhance the tree manipulation API, adding a Node::child_iterator
   type, as well as new 'insert_child', and 'append_child' methods
   (in accordance with the usual STL nomenclature)
* remove more memory leaks (SaxParser now has its own 'AttributeMap',
   independent from Node types
* new 'Node::find' and 'Node::get_path' methods for use with xpath lookup

All this is illustrated in a new example in examples/dom/. The example takes
an existing docbook 'article' and modifies it, and does a simple (xpath
based) validation test.

Here are some further enhancements I'd like to work on:

* add a 'Visitor' class to get rid of all the dynamic_casts in the existing
   examples
* clean up the tree access/modification API. In particular:
   - get rid of all methods involving NodeLists. Use iterators instead.
   - get rid of [add,get] *_content (iterators, again...)
   - define what 'get_content' should do if this isn't a text (etc.) node.
* decide who can create Nodes, who owns them if they are taken out of a document,
   etc. May be a 'Store' object may help...

What is the reason for the libxml++ code to be split over a set of subdirs ?
Is that really necessary ? Now that 'Attribute' is a node, it is also inconsistent.
I would suggest to put all libxml++/nodes/ source files into a single place with the
rest.

Oh, and can we take out the call to './configure' from the autogen.sh script ?
I'd like to be able to configure (and build) in a separate build tree, which
currently isn't possible.

Any comments concerning the new code (please look into the examples/dom/ demo !)
are highly appreciated...

Regards,
		Stefan