You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Gerald Richter <ri...@ecos.de> on 2001/03/08 08:28:03 UTC
Overrideing XalanDOM
Hi,
at http://archive.covalent.net/xml/xalan-dev/2000/12/0109.xml I found same
discussion about overriding XalanDOM to access an already build in-memory
tree, instead of letting Xalan C++ setting up his own one. Unfortunately the
archive stops at december, so I can't check out if there any newer
discussion on this topic.
Since I have a similar problem, I like to know which class(es) I have
exactly to override, so that the source tree can provided by this overridden
classes? Has anyone done this before and can provide some sample code? If
there is any documentation that deals about this topic, that I have missed
let me know.
Thanks
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
RE: Overrideing XalanDOM
Posted by Christian Aberger <Ch...@Aberger.at>.
David,
I think this discussion thread should be merged with "Working with DOM input
and output destroyed, XalanSourceTreeParserLiaison::createDocument has now
void argument list."
First of all I want to say that I do not want to critisize anybody, no, the
opposite is the case, I am absolutely delighted about the high quality and
professional way of implementation etc... but we all know that so I will not
waste your time more. I read again some of the mails I sent and I see that
some can easily be misunderstood as impolite. I appologize for that, this is
often a problem of my mails, you can't see that I had a smile in the face
when I wrote most those tings, joking.
Ok, well then back to the topic.
<These five classes seem to be the minimum you can get away with using the
current Xalan. >
Sorry, I can't understand what you write here. Peter Murphy sent on Friday
in an attachment a sample how he did this without deriving from anything
(with one remaining problem, you must set
domInput->setToCreateXMLDeclTypeNode(false); instead of true (or not set it
at all). This needs no overriding of any class and seems to work on my
installation. Maybe you want to say that your version will also compile with
a newer future release of xalan without changes, is this what you want to
say? Well I think this is a lot of work now for something we do not yet
know, isn't it?
For an example how soon upwards compatibility can be destroyed, please see
as an example my remark and Dave's reply to it that XML_DECL_NODE is not
implemented in the Xalan Document bridge:
<<As far as I can see from the source code
in XercesDocumentBridge.cpp the implementation of XercesDocumentBridge is
incomplete.>>
<XML_DECL_NODE is not a standard DOM node type. We have no plans to support
it since it will be replaced by a standard mechanism.>
Well, I suppose there are 2 (out of many) aspects of softwarequality
concerned in this point: conformance and correctness. I agree that
XML_DECL_NODE is not a standard. Still, when Xerces is used as inner
implementation of an outer interface, there is among all other allowed
enumeration values of "NodeType" also the value XML_DECL_NODE. This is a
valid value of a membervariable. Parsing a valid input document with XMLDecl
set to "true" is a valid operation that transits to a valid program state.
In a correct program valid states have transitions to the set of all valid
states only. So not implementing XML_DECL_NODE is, in my personal opinion,
not correct although it is conforming (well I think we can open a separate
mailing list why adding a catch(...) handler does not make an incorrect
program correct).
Correct programs save a lot of time to all of us, and I like correct
programs. Ok, I agree that there are companies that make good money with
incorrect programs, because the users pragmatically accept that they loose a
lot of time with these.
wfR ChrisA
-----Original Message-----
From: David Braaten [mailto:david.braaten@multiactive.com]
Sent: Samstag, 10. März 2001 03:55
To: xalan-dev@xml.apache.org
Subject: Re: Overrideing XalanDOM
Keep David Bertoni's comments about the future changes possible
to Xalan and its DOM base classes... And you don't mention if
your 'already built in-memory tree' is some application specific custom
tree or of it's a DOM tree...
The classes you have to override depend on what you want to do.
In my case, I just needed read-only access to some application data
to use for some transformations.
I derived classes from:
XalanDocument
XalanElement
XalanAttribute
XalanText
XalanNamedNodeMap
The derived classes I made basically map requests for data from thier
DOM interfaces to the data already supplied by my application.
These five classes seem to be the minimum you can get away with using
the current Xalan. (well, I suppose you don't need Attribute or NamedNodeMap
if
you don't need to provide any attributes) There are no namespaces in my
custom tree.
Also, you can get away with only implementing some of the Node interface
methods fully.(And just return NULL or whatever is appropriate for those you
don't implement)
Those methods are:
getNodeName
getNodeValue
getNodeType
getParentNode
getOwnerDocument
hasChildNodes
getLocalName
isIndexed
getIndex
(for Text nodes)
getData
getLength
_
----- Original Message -----
From: "Gerald Richter" <ri...@ecos.de>
To: <xa...@xml.apache.org>
Sent: Wednesday, March 07, 2001 11:28 PM
Subject: Overrideing XalanDOM
> Hi,
>
> at http://archive.covalent.net/xml/xalan-dev/2000/12/0109.xml I found same
> discussion about overriding XalanDOM to access an already build in-memory
> tree, instead of letting Xalan C++ setting up his own one. Unfortunately
the
> archive stops at december, so I can't check out if there any newer
> discussion on this topic.
>
> Since I have a similar problem, I like to know which class(es) I have
> exactly to override, so that the source tree can provided by this
overridden
> classes? Has anyone done this before and can provide some sample code? If
> there is any documentation that deals about this topic, that I have missed
> let me know.
>
Re: Overrideing XalanDOM
Posted by David Braaten <da...@multiactive.com>.
Keep David Bertoni's comments about the future changes possible
to Xalan and its DOM base classes... And you don't mention if
your 'already built in-memory tree' is some application specific custom
tree or of it's a DOM tree...
The classes you have to override depend on what you want to do.
In my case, I just needed read-only access to some application data
to use for some transformations.
I derived classes from:
XalanDocument
XalanElement
XalanAttribute
XalanText
XalanNamedNodeMap
The derived classes I made basically map requests for data from thier
DOM interfaces to the data already supplied by my application.
These five classes seem to be the minimum you can get away with using
the current Xalan. (well, I suppose you don't need Attribute or NamedNodeMap
if
you don't need to provide any attributes) There are no namespaces in my
custom tree.
Also, you can get away with only implementing some of the Node interface
methods fully.(And just return NULL or whatever is appropriate for those you
don't implement)
Those methods are:
getNodeName
getNodeValue
getNodeType
getParentNode
getOwnerDocument
hasChildNodes
getLocalName
isIndexed
getIndex
(for Text nodes)
getData
getLength
_
----- Original Message -----
From: "Gerald Richter" <ri...@ecos.de>
To: <xa...@xml.apache.org>
Sent: Wednesday, March 07, 2001 11:28 PM
Subject: Overrideing XalanDOM
> Hi,
>
> at http://archive.covalent.net/xml/xalan-dev/2000/12/0109.xml I found same
> discussion about overriding XalanDOM to access an already build in-memory
> tree, instead of letting Xalan C++ setting up his own one. Unfortunately
the
> archive stops at december, so I can't check out if there any newer
> discussion on this topic.
>
> Since I have a similar problem, I like to know which class(es) I have
> exactly to override, so that the source tree can provided by this
overridden
> classes? Has anyone done this before and can provide some sample code? If
> there is any documentation that deals about this topic, that I have missed
> let me know.
>