- From: Christian Parpart <cparpart@surakware.net>
- Date: Tue, 1 Oct 2002 00:03:39 +0200
- To: www-dom@w3.org
-----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 UTC