W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2002

DOM Level 3 modules and C++

From: Christian Parpart <cparpart@surakware.net>
Date: Tue, 1 Oct 2002 00:03:39 +0200
To: www-dom@w3.org
Message-Id: <200210010003.43432.cparpart@surakware.net>

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

Hi all,

I'm implementing an XML library currently containing 
  * DOM Level 3 Core, XPath, and Load&Save
Unfortunately, this was done by documents (offline) a half year ago, and I 
must recognize that the new updated ones do have changed some things.

The Load & Save Module now depends on Traversal as well as on Events. This 
forces me to include both header files (from Traversal and Events) into my LS 
header file.Also to provide Events in the Document class (interface) I need 
to include Events on the core header, too. This is not good.

However, here is my issue: There are lots of DocumentXXX interfaces, querying 
one interface containing Core 3.0, XPath 3.0, DOM-LS, Traversal, and even 
Events, includes (in C++) to have a class derived from all these classes.

class RequestedDocumentCaseOne : public Document, 
	public DocumentEvents {
}; // requested features: Core and Events

class RequestedDocumentCaseTwo : public Document, public DocumentLS,
	public DocumentTraversal, public DocumentEvents {
}; // requested features: nearly everything

This is no good resolution for the problem. And C++ is not JavaScript
where you can test whether a function exists for given object or not:

if (myDocument.loadXML) {
	myDocument.loadXML("http://myurl.com/news.rdf");
}

Even this is not possible for good reasons. So, how to implement all this 
stuff? My suggestion is to implement a super Document class containing 
everything. But is this what the standard wants?

I do not know how Java do go around this problem. How?

Furthermore (as I hopefully did understand the Events specs right) the DOM 
Core Node Interface needs to be derived from the Events interface, so that 
(e.g. for HTML browsers) the nodes are event'able.
Is this what the standard wants?

Best regards,
Christian Parpart.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9mMo+Ppa2GmDVhK0RAlisAJ9EU5i9/0MoKu1BZZLPbW5EdVnXlwCfS4uF
pK4baTB3jlZz6L6QLUuOo54=
=iH1c
-----END PGP SIGNATURE-----
Received on Monday, 30 September 2002 18:20:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:56 GMT