Stefan Seefeld
Janusz Piwowarski wrote:
Stefan Seefeld wrote:
Now I hope that someone will actually start to send comments about the actual API / code I propose. ;-)
I not sure why you do not use of overloaded append and insert members. And,
Assuming you are talking about the element class and its methods to add various child node types, I don't quite see how I could overload the function name 'append' and 'insert', as most versions have the same signature. E.g. 'insert_element("foo")' will add (and return) the element
<foo/>
node.insert( element( "foo" ));
while 'insert_comment("foo")' will add (and return) the comment
<!--foo-->
node.insert( comment( "foo" ));
I'd like to change begin_children and end_children to std::pair<children_iterator, children_iterator> children (the same with attributes).
...or add a container proxy so one would write element->children().begin() instead of element->begin_children(). I'm not sure there is any gain. It seems to be a purely esthetical issue.
I prefer the container proxy as it is more familiar to STL users - ( children.first, children.second ) is harder to understand what is meant by first and second. I would like to see STL techniques (like the children and attributes types being Container-like types), that would allow the leverage of existing STL and boost code. Since an XML document is a tree structure, it might be useful to have a generic tree library first (using STL principles) so you could do something like: typedef nary_tree< xml::node > document_fragment; or even leverage the Boost.Graph library. - Reece