Hi, Another related question :
Can Xalan be built with VC8 using *xerces 2.8 *instead of xerces 3.0 ? I'm getting the following errors : 1>Linking... 1>ICUResHandler.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static int __cdecl xercesc_2_8::XMLString::compareString(wchar_t const * const,wchar_t const * const)" ([EMAIL PROTECTED]@xercesc_2_8@@[EMAIL PROTECTED]) 1>ICUResHandler.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual void __thiscall xercesc_2_8::DefaultHandler::internalEntityDecl(wchar_t const * const,wchar_t const * const)" ([EMAIL PROTECTED] @xercesc_2_8@@[EMAIL PROTECTED]) 1>MsgCreator.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static char * __cdecl xercesc_2_8::XMLString::transcode(wchar_t const * const)" ([EMAIL PROTECTED]@xercesc_2_8@@[EMAIL PROTECTED]) 1>MsgCreator.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static wchar_t const * const xercesc_2_8::XMLUni::fgXercesDynamic" ([EMAIL PROTECTED] @xercesc_2_8@@2QB_WB) and 25 odd other such errors . Anything I can do to correct these ? Thanks Dyut On Fri, Dec 5, 2008 at 11:51 AM, Hans Smit <[EMAIL PROTECTED]> wrote: > Question: Is it possible to use the XPath support without making use of >>> the ParserLiason and DomSupport classes? >>> >> Unfortunately, the XPathEvaluator class doesn't encapsulate all of these >> details, although it should be possible to do that as an enhancement. >> > > That's the beauty of C++ - encapsulation. That's also what I've done. When > I come across a awkward/complex construct, my mind starts screaming "do not > repeat - encapsulate". But, at times I wonder if I'm doing it right, that's > when your explanations and your performace hints are very much appreciated. > Thanks. > > Cheers, > > Hans > > ----- Original Message ----- From: "David Bertoni" <[EMAIL PROTECTED]> > To: <xalan-c-users@xml.apache.org> > Sent: Thursday, December 04, 2008 23:50 > Subject: Re: Xalan with VC++8 > > > Hans Smit wrote: >> >>> Hi Dave, >>> >>> Your points 2) + 3) are interesting. Right now I'm loading XML files into >>> memory via xercesc. I cache my XML islands in memory (xercesc::DOMDocument). >>> If the user manipulates the data via my user interface, I simply serialize >>> and save to file, but retain an in-memory reference (without reload). I also >>> use this xercesc::DOMDocument as input to my precompiled XalanTransformer >>> (which I also cache). I guess you could look at this as a in-memory XML >>> database. >>> >> If you allow users to edit documents, then the Xalan-C source tree will >> not work for you. Much of its performance advantages come from the fact >> that it's read-only, as the source tree is immutable in XSLT, >> >> >>> So my question is: can I skip the xercesc interface aurll together, and >>> just make use of xalanc? This may simpify my code somewhat, and hopefully >>> give me a performance boost. The only aspects of xercesc I use are the W3C >>> DOM interface , the serializer (for writing), and the XercesDOMParser (for >>> reading). >>> >> Not if you need a mutable DOM implementation, unfortunately. >> >> >>> Next Item: the only reason I make use of the xalanc::XercesDOMSupport and >>> xalanc::XercesDOMSupport are because I need to use XalanDocument for XPath >>> expressions. >>> >>> Example, >>> xalanDocument = parserLiaison.createDocument(domDoc, false, true); >>> >>> followed by a selectNodeList call. >>> >>> Question: Is it possible to use the XPath support without making use of >>> the ParserLiason and DomSupport classes? >>> >> Unfortunately, the XPathEvaluator class doesn't encapsulate all of these >> details, although it should be possible to do that as an enhancement. >> >> Dave >> >> >
