GNOME.org
 

Re: Upgrade guidance

As I feared, then. It's not safe to keep a pointer to a node in a document when nodes are added to or deleted from the document.

Keeping an XPath is not safe, either. I tested by adding node->get_path() in the dom_parser example program. Some of the returned XPaths are "/example/examplechild[1]" and "/example/examplechild[2]". Which /example/examplechild is the second one may of course change if new nodes are added.

There is in fact a way to copy nodes, although it might become more involved than you want, if it's not an element node.
You can create a xmlpp::Document and add nodes to it. You can copy an element node with or without all its children from another document with xmlpp::Document::create_root_node_by_import(). xmlpp::Node::import_node() can also be useful.

Den 2015-09-22 kl. 13:02, skrev Park, Joseph:
Yes, we are using a DOM parser, sorry for that omission. 

I tried saving a pointer to the node, but when accessed from another segment of the code it seems to have invalid contents, i.e. i check that the pointer (address) is the same, but for example node->get_name() and other node functions are invalid.   Although, since the document was parsed there were nodes added to it. 

On Tue, Sep 22, 2015 at 4:32 AM, Kjell Ahlstedt <kjell ahlstedt bredband net> wrote:
I suppose from your question that use use the DOM parser. The parser creates a xmlpp::Document, and that Document with all its nodes exists as long as the DomParser object exists. Both documents and nodes are non-copyable, but you can copy a pointer to a node, and access the node later through that pointer. Of course you must be sure not to dereference the pointer after the parser object has been deleted. And I'm uncertain how safe this strategy is, if you make changes to the parsed document (adding or deleting nodes, for example).

Saving the node's XPath and later retrieving the node with rootNode->find(xpath) should also work. I don't think the node's children would be included in the NodeSet that find() returns. You can easily test, I guess. XPath is very flexible. Depending on the exact contents of the XPath string, the result of the search can be quite different.

Kjell

Den 2015-09-21 kl. 21:42, skrev Park, Joseph:
Update: the port is essentially complete...

One issue is the ability to store a reference to a node for processing later/elsewhere in the code.  To clarify:

When processing a parsed document, there are instances when a node cannot be processed (the required objects created based on the xml node information) until later when some other needed objects have been instantiated.

In the ancient code we would just allocate a copy of the node on the heap and process it later as needed. 

I apologize for the nubile question! 

Would saving the Xpath from node->get_path(), and then later accessing via rootNode->find( Xpath ) be a reasonable solution?

Although i see that find() returns a NodeSet vector... which would presumably include the node referred to by Xpath and any children?

Thanks!

JP


On Tue, Jun 16, 2015 at 12:06 PM, Park, Joseph <joseph_park nps gov> wrote:
Ladies and Gents...

I am faced with the task of upgrading a hydrological simulation model [1] from an early libxml++ (libxml++-0.15.0) to a contemporary one (target libxml++-2.38.1).  The code is quite complex and XML parsing is replete.

It appears, as one would expect, that over the years libxml++ has fundamentally changed it's class structure, i.e. XMLNode in 0.15.0 is no longer defined.

So, I'm looking for guidance and suggestions on how to approach such an endeavor, in the hopes that someone has tread this path.



_______________________________________________
libxmlplusplus-list mailing list
libxmlplusplus-list gnome org
https://mail.gnome.org/mailman/listinfo/libxmlplusplus-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]