Re: [Libxmlplusplus-general] Re: has_content()

[Christophe de Vienne <cdevienne alphacent com>]

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

On Mardi 3 Décembre 2002 18:26, Murray Cumming wrote:
> On Tue, 2002-12-03 at 16:50, Christophe de VIENNE wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi murray,
> >
> > I've just realised that in node.cc version 1.8, you commited this:
> >         - Rename is_content() to has_content(), because that's what it
> > tells us. Removed _is_content member bool - we can check _content.empty()
> > instead.
> >
> > Well, my anderstanding of that is different : the accessor had, for me,
> > the right name. If we look at the tree generated by libxml, the
> > correponding node has a particular type, XML_TEXT_NODE, and cannot have
> > any attribute/children. A xml code like "<name>foo</name>" will generate
> > 2 nodes. One named "name", and another which IS the content ("foo").
>
> I agree that a is_content() might be useful, but I don't think that's
> how libxml++ works at the moment. Content nodes (text nodes) are not
> provided separately - the content is associated with other nodes.
>

not for me... If you try to read and write a single file, you will see some 
extra nodes with "text" as name around contents (that's what led me to this 
problem). Moreover, in the dom_parser example, we can see them (see at the 
end of the message. In fact it's even worse, I may have done a mistake 
somewhere in Node::read).
So we have to make a decision, either to put the content in the parent node, 
either to take it in consideration at write time (I did a small patch for 
that, but I prefer to go directly to the final solution).

> Your idea would make sense, and I might be completely wrong anyway, but
> if you change anything then you should demonstrate that the concept
> works in an example.

Indeed...

>
> > Do you agree or did I get something wrong ?
> >
> > Anyway I'm thinking of creating a special class for content nodes.
> >
> > The thing I don't know yet is : can 'normal' node has both content node
> > AND 'normal' children ?
>
> No, I don't thinks so.

Neither I do, so I'll have to put extra checking in the add_child, add_content 
and stuffs to forbid such freaks since libxml will not be able to write them.



extract of the output of the dom parser example :

      Node name=Contact
        Node name=text
  content=

        Node name=Person
          Node name=text
  content=Nathan Clemons
        Node name=text
  content=

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

iD8DBQE97PEHB+sU3TyOQjARAmSUAKCIcyL1Ew0NysAuVJ8iSBn68L0ShQCeLqiC
5jlg6vQWuM/z9PW6SXJZP60=
=gh3K
-----END PGP SIGNATURE-----