Thread: [Sax-devel] Should an ExtendedDefaultHandler be added?
Brought to you by:
dmegginson
From: Jeff R. <jef...@de...> - 2001-10-18 00:29:33
|
I have noticed that several packages (including AElfred) create a default handler class that does nothing but implement the extension interfaces. Would it be helpful to create an ExtendedDefaultHandler class and add it to the org.xml.sax.ext package? It could be based upon the DefaultHandler class that already exists and simply implement the interfaces with // no op as we have already seen. This is a fairly innocuous addition, no? While existing packages may not use it-- it would save the reinvention of the wheel for others... Just a thought... Jeff Rafter Defined Systems http://www.defined.net XML Development and Developer Web Hosting |
From: David B. <da...@pa...> - 2001-10-18 01:34:45
|
> I have noticed that several packages (including AElfred) create a default > handler class that does nothing but implement the extension interfaces. > Would it be helpful to create an ExtendedDefaultHandler class and add it to > the org.xml.sax.ext package? It could be based upon the DefaultHandler class > that already exists I tend to think so. It adds a dependency of "ext" on "helpers", but that's OK in my book. David Megginson didn't like the idea of making such an dependency go the other way around, by the way; feels a bit too much like "core" depending on "extension". Though I'll say I don't like the "Extended*" naming convention, or the variant used by MSFT: "*Ex". That starts to get weak after the first iteration or so. I just posted a note about some of the extensions I just put back to CVS, that should let us close the "missing XML infoset data" RFEs. That lets me morph this suggestion: package org.xml.sax.ext; public class DefaultHandler2 extends org.xml.sax.helpers.DefaultHandler implements DeclHandler, LexicalHandler { public DefaultHandler2 () { /* NOP */ } // stubs for all DeclHandler and LexicalHandler methods // ... override two ContentHandler methods to delegate // to these, so apps can always expect the newer APIs // even when DefaultHandler2 is wrapping the old APIs: public void setDocumentLocator (Locator2 locator) { } public void startElement (String uri, String local, String qName, Attributes2 atts) { } } I'm not 100% sure those two new methods are the way to go, but doing it that way would maintain full compatibility and push casts into infrastructure (vs application code). Code using them would likely remember in advance whether to expect the new infoset data to be available. - Dave p.s. Jeff, feel like filing an RFE at SourceForge for this? |
From: Jeff R. <jef...@de...> - 2001-10-18 03:29:10
|
Here is another one of those items I am sure has been discussed-- I just wanted to point it out "just in case". Within XMLFilterImpl.Java the implements declaration reads: implements XMLFilter, EntityResolver, DTDHandler, ContentHandler, ErrorHandler Lower in the file we see that the XMLReader methods are also implemented: //////////////////////////////////////////////////////////////////// // Implementation of org.xml.sax.XMLReader. //////////////////////////////////////////////////////////////////// So why is XMLReader omitted from the implements declaration? Is this intentional? If this is a bug I can submit it-- this is more of a question than a bug right now : ) Thanks, Jeff Rafter Defined Systems http://www.defined.net XML Development and Developer Web Hosting |
From: David B. <da...@pa...> - 2001-10-18 03:33:08
|
> So why is XMLReader omitted from the implements declaration? Is this > intentional? If this is a bug I can submit it-- this is more of a question > than a bug right now :) It's implied by "implements XMLFilter". Look at the javadoc, you'll see XMLReader in the list of "All Implemented Interfaces". - Dave |
From: Jeff R. <jef...@de...> - 2001-10-18 03:38:27
|
> It's implied by "implements XMLFilter". Look at the javadoc, you'll > see XMLReader in the list of "All Implemented Interfaces". Ahh, Pascal on the brain-- that'll teach me. : ) Jeff Rafter Defined Systems http://www.defined.net XML Development and Developer Web Hosting |