Extend EntityResolver, override resolveEntity() and use pParser->setEntityResolver()
Adam Heinz
Development Consultant
Exstream Software
[EMAIL PROTECTED]
317.879.2831
connecting with the eGeneration
www.exstream.com
-Original Message-
From: Andreas B. Thun [mailto:[EMAIL PROTECTED]
Sen
nope. You have to create one.
-Original Message-
From: Andreas B. Thun [mailto:[EMAIL PROTECTED]
Sent: 29 August 2003 13:33
To: [EMAIL PROTECTED]
Subject: Re: Validation with another DTD than specified in XML file
> // EsXml4cDomEntityResolver.h: interface for
// EsXml4cDomEntityResolver.h: interface for the EsXml4cDomEntityResolver
class.
Is this interface part of the normal XERCES distribution?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECT
Following code would do what you want
EsXml4cDomEntityResolver* entHandler = new EsXml4cDomEntityResolver();
parserInstance_->setEntityResolver(entHandler);
// EsXml4cDomEntityResolver.h: interface for the EsXml4cDomEntityResolver
class.
//
///
Hi,
The proposed patch would not resolve a compiler error.
What header files are you including? Do you have #include
?
Regards,
David A. Cargill
Here is an example where if the user asks for my DTD, I make sure that I always use
the one in the installation directory. There is no reason why you could not ignore
the DTD requested by the user and return an InputSource for whatever DTD you like.
InputSource* SAXResolver::resolveEntity(const
I can't speak from direct DOMParser experience, but with my SAXParser, I am able to
set pParser->setEntityResolver(SAXEntityResolver*) and a brief glance shows a similar
DOMEntityResolver*. You should be able to override resolveEntity(...) to get whatever
behavior you desire.
Adam Heinz
Develo
