I guess I had assumed that deferred parsing was just an added capability and that the standard XMLCStdFactory would still be able to load the classes, albeit without deferred parsing. This would make it so you could compile with the possibility of deferred parsing, but then when you didn't need deferred parsing turned on, the classes would be loaded like normal which, I assume, is a bit less overhead.
Shouldn't there be a fallback; backward compatibility, if you will? Was this just not considered and so it wasn't implemented, or is it not implementable? Just wondering if I'm going to have to worry about recompiling each time I want to change XMLC factories? If so, this means I have to both remove the option in my options.xmlc file and make sure to change the DOMFactory to the appropriate one that won't blow up when loading XMLC classes. Hmmmm...... Any solutions, or am I just going to have to live with a bit of extra maintenance?
The StdFactory won't be able to load document class generated for deferred parsing. Fallback sounds reasonable thing to do but it's just not high on the ToDo list, I guess. I have ran into the issues recently with our app here and I just demand to do the recompilation whenever a factory change is necessary.
The class for the StdFactory has a bunch of codes for assembling a DOM tree and for the deferred parsing, the codes are done by the parser so they don't have to be in the generating classes. Deferred parsing offer everything of StdFactory without shortcoming and I think the intention now would eventually to replace the std factory with the deferred parsing.
So, I guess there are two solutions here:
1. Implement the backward compatible document class generating. This shouldn't be very hard but tedious. It requires merging the std class generating codes with the deferred parsing generating codes.
2. Just forget about the existing of StdFactory and start thinking Deferred parsing as the only factory. ;)
| 