I want to use the same XMLDocumentHandler implementation in a number of places in both the parser pipeline as a filter , as a parser subclass, and also being driven by a serialize of the DOM Tree.
Using version 2.0.2 , I used the DOMNormalizer class to walk the dom
by extending an XMLDocumentHandler implementation and implementing Revalidation
Handler
and by subclassing DOMNormalizer as follows
public class DNValidationHandler extends MyXMLDocumentHandler
implements org.apache.xerces.impl.RevalidationHandler
{
public void setCurrentNode(Node node){
myCurrentNode = node;
// myCurrentNode defined in MyXMLDocumentHandler
}
}
public class DOMNormalizerSubclass extends org.apache.xerces.dom.DOMNormalizer
{
protected org.w3c.dom.Node
normalizeNode(org.w3c.dom.Node node) {
validator.setCurrentNode(node);
}
protected void setValidationHandler(org.apache.xerces.impl.RevalidationHandler
validator) {
this.validator = (DNValidationHandler) validator;
super.setValidationHandler(validator);
}
}
I know this is a rather unorthodox way of using the DOMNormalizer code but we do not want to use multiple DOM Serializers.
I dont want to use the org.xml.serialize package to serialize as there is no support for XMLDocumentHandler...
We need a way to serialize the DOMTree through XMLDocumentHandler and pass-through the current node in the tree, either as a variable or as an augmentation.
Although not intended for its original purpose, it works like a charm, making all DOMNormalizer methods as protected FINAL as in the latest CVS Version 1.7 will put a stop to this.
Please can you explain the reasons for changing these methods to FINAL
??
Do you really need to do this ???
Maybe an alternative is to factor out the Normalizer code (also non
DOM-L3)
so that it can be used for other general serialization purposes (using
XMLDocumentHandler) as well as for Re-validation.
Bottom Line - need to serialize DOM via XMLDocumentHandler.
Thanks
Ray Grimmond
[EMAIL PROTECTED]
