On the FormatterWalker - I have to ask a stupid question (:<). I can base it on the XercesTreeWalker class, but I need
to implement the various FormatterListener start/create calls. The problematic one is startElement as I need to wrap the
DOM_NamedNodeMap in a wrapper that implements the SAX parser AttributeList. Does such a thing exist, or do I need to create a new XercesDeprecatedNamedNodeMapAttributeList (the names just keep getting better) and then use a string pool to map the old DOMString objects to XMLCh?
Work mail is difficult to get to on the weekend, so will check out first thing tomorrow.
(Another) question for you. The issue with -fno-elide-constructors raises an interesting question in regards to compilers and makefiles. Is there any scope for testing these kinds of things in the configure script? That's the real power of autoconf, but I notice the preference seems to have been to go down the path of options in various header files. I've played a bit with autoconf in the past (I use it heavily in the build process for xml-security), and if we can do a programatic test for it (which could just be a matter of trying to compile something with the STL in it), we can build the option into the autoconf script.
The downside is it complicates the configure script and it means that whenever _anything_ changes in the OS, you need to re-run configure. At the moment, you simply re-run make and it works everything out automatically.
The up-side is it simplifies the makefiles and the header files and means that when new compilers and versions come along, there is a good chance the configure script can "work out" the correct options for the given compiler.
Cheers,
Berin
David N Bertoni/Cambridge/IBM wrote:
Hi Berin,
I got the code. I also sent a reply to your work email, so you might want
to check it if you can.
Do you want to add the FormatterWalker for the deprecated DOM for
completeness? It seems OK to me, even thought that stuff will be
disappearing soon. I agree we should not add it to the sample -- I'd
rather not encourage use of that DOM.
That's good new you got the doc to build. We should probably document the
documentation process at some point, so we anyone can produce it. To
update the web site, we usually tar up the the files for the web site, the
ship them over with scp, since ftp is not supported.
I had the same STL problem with 2.95.3, and didn't make the connection that
it might be related to the no-elide-constructors option. Good catch! That
whole thing has me mystified, but I suspect there is a bug in gcc with the
implementation of the return value optimization.
When we moved up to gcc 3.1, I noticed there were problems with XObject
derivates, because they're used with smart pointers. For some reason, the
reference counts were not being decremented. Even more strange is that it
would happen in non-optimized builds! Finally, I did a Google and I ran
across that option, which is not in the documentation regarding
optimization settings. Adding that option fixed everything, but I still
don't understand why even non-optimized builds were broken, or why adding
it to the 2.95.3 command line would break the STL.
Dave
|---------+--------------------------->
| | Berin Lautenbach|
| | <[EMAIL PROTECTED]|
| | om.au> |
| | |
| | 02/08/2003 01:30|
| | AM |
| | Please respond |
| | to xalan-dev |
|---------+--------------------------->
>--------------------------------------------------------------------------------------------------------------------------------|
| |
| To: [EMAIL PROTECTED] |
| cc: (bcc: David N Bertoni/Cambridge/IBM) |
| Subject: Deprecated Node Support |
>--------------------------------------------------------------------------------------------------------------------------------|
David,
Following on from previous e-mails.
1. Have implemented the FormatterToDeprecatedXercesDOM. (Will send
direct rather than to list.)
2. Started looking at also doing a XercesDeprecatedDOMFormatterWalker,
but decided that the value is not there.
3. Did another version of TransformToDeprecatedXercesDOM just for
testing purposes and in case we want to add another sample. (I think
not - better to use as input for a usage pattern.)
4. Have managed to re-create all documentation from the CVS repository.
Had to fix a few minor problems in the XML files, but can now build
HTML. So will look tomorrow at updating some of the usage samples for
wrapper classes.
On the last point - what's the easiest way to transport the HTML?
I also found that on my Debian box, the cvs code no longer compiles,
complaining of errors in the STL headers. I found removing the
-fno-elide-constructors switch from the makefile fixed the problem, and
I remember seeing someone else has been having the same issue? (gcc
2.95.4)
Am not sure why this is an issue - from the man pages,
no-elide-constructors is the default, so removing this should have no
impact. Most strange.
Cheers,
Berin
