Re: [libxml++] node iterators

[Christophe de VIENNE <cdevienne alphacent com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Vendredi 23 Mai 2003 08:38, Murray Cumming Comneon com a écrit :
> > From: Christophe de VIENNE [mailto:cdevienne alphacent com]
> > void do_something(xmlpp::Node & node) {
> >
> > 	for( xmlpp::NodeIterator i = node.children_node(),
> > 		i_end = xmlpp::NodeIterator();
> > 		i != i_end;
> > 		++i)
> > 	{
> > 		std::cout << i->get_name() << std::endl;
> > 		do_something(*i);
> > 	}
> >
> > };
>
> - I don't see begin() or end().

For begin(), just a mistake of me. What I wanted to write is :

   for( xmlpp::NodeIterator i = node.children_begin(),

As far as end(), I firstly considered that xmlpp::NodeIterator default 
constructor would play that role.

Anyway I agree with you about using another class. I'll try doing something 
like this to see how it works.

The same thing can be done with Attributes BTW.


> - Maybe xmlpp::NodeIterator should be xmlpp::Node::iterator or
> xmlpp::Node::Children::iterator.

I prefer better xmlpp::Node::Children::iterator, since we can make the 
Children type a STL-like container.

> I'm fairly convinced that the only way to do this is via another class,
> like we do in some gtkmm widgets, such as Gtk::Model, Gtk::Container,
> Gtk::Toolbar, and Gtk::ComboBox:
>
> xmlpp::Node::ChildrenList& list = node.children();
> for( xmlpp::Node::ChildrenList::iterator iter = list.begin(),
>      iter != list.end();
>      ++iter)
> {
>   std::cout << i->get_name() << std::endl;
>   do_something(*i);
> }
>
> It's not just the implementation, but the interface itself. I don't think
> we should mix an STL-style container API in with an unrelated API in one
> class. The need for a children_ prefix seems to suggest that it should be a
> separate class.
>

As I said before I agree with this approach.

> >  - Should we wait for the next major version to add this feature ?
>
> Yes. We can freeze and branch soon if you like, though there are maybe
> these open issues:
> http://sourceforge.net/tracker/index.php?func=detail&aid=724953&group_id=12
>9 99&atid=312999

Yes. It would be nice if Ephraim could finish it, or at least say if he wants 
to or not.

We should also normalize the file header comments (I'm not specialist of these 
things). What about :

 /*
  * <filename>
  *
  * libxml++ and this file are copyright (C) 2003 by libxml++ Development
  * Team, and are covered by the GNU Lesser General Public License, which
  * should be included with libxml++ as the file COPYING.
  *
  */

Fell free to criticize this.

> http://sourceforge.net/tracker/index.php?func=detail&aid=708826&group_id=12
>9 99&atid=312999

About this one I don't know what to do.
Could somebody using on_get_entity() callback in SaxParser tell me what he 
thinks about it ?



What do you think about this one ? If you're OK I'll implement this 
additionnal protected constructor I'm speaking about.

http://sourceforge.net/tracker/index.php?func=detail&aid=690193&group_id=12999&atid=312999


> Also, we should wait a little to let the recent changes settle in. I
> haven't had a chance to test the new release yet.

Of course. I'm not that hurry, I just wanted this to be discussed. Moreover I 
know that last changes on blanks will force some adaptation of client code (I 
had to do some for my application).

>
> > The patch (which concerns only the 'nodes' directory) also
> > includes a little
> > change : it uses pimpl idiom so that no libxml header is
> > included by the
> > libxml++ user.
>
> I like not including the libxml headers. That's an aim of gtkmm too, re.
> GTK+ headers.

I'll try to do this in the whole library in the next days.


Cheers,

Christophe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+zd7+B+sU3TyOQjARAkynAKCdst9+VB9jZvdvEYV75+dsDeLSnwCeJtkz
RTsQ0EA42Kl6rgN5gpHfQYE=
=XaUk
-----END PGP SIGNATURE-----