Re: [Libxmlplusplus-general] resume of one day's work
- From: murrayc t-online de (Murray Cumming)
- To: libxml++ <libxmlplusplus-general lists sourceforge net>
- Subject: Re: [Libxmlplusplus-general] resume of one day's work
- Date: 04 Feb 2003 09:34:42 +0100
On Tue, 2003-02-04 at 08:21, Stefan Seefeld wrote:
> hi there,
> I'v just checked in the latest bits and pieces of today's round
> of enhancements. Here is a list:
I haven't looked at this yet, but didn't I say that you shouldn't take
cvs access as permission to just check in whatever you like? The need to
revise your patch 6 times should have shown you that you probably need
to go a bit slower. Your arrogance is beginning to astound me.
> * 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
Who gave you permission to make these major API changes? As far as I
know we have not branched yet. Now we will have to do a lot of work to
branch and revert these changes in the 1.0 branch.
> 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
Let's patches for all the other stuff please, and let's apply them until
> * 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 ?
Yes. It's organisation.
> 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
> Oh, and can we take out the call to './configure' from the autogen.sh script ?
No, I'd rather that we didn't.
> I'd like to be able to configure (and build) in a separate build tree, which
> currently isn't possible.
Feel free to make your own autogen.sh locally.
> Any comments concerning the new code (please look into the examples/dom/ demo !)
> are highly appreciated...
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> Libxmlplusplus-general mailing list
> Libxmlplusplus-general lists sourceforge net
murray usa net
] [Thread Prev