Cameron McCormack wrote:
Cameron McCormack:
Also, I've changed my mind on how I think the DOM 3 interfaces should be
handled. I think it would be better not to include a copy of all of the
DOM 3 interfaces in org.apache.batik.dom.dom3 and rather just implement
and extend whichever level DOM interfaces are available.
I've tended to agree. Although the tipping factor for me is
the whole licensing issue that recently came up.
One interface that would have to be handled differently, though, is
CustomEvent. Since it extends Event, it won't have the right methods in
it if running under a JDK with DOM 2 interfaces (such as
getNamespaceURI). So the solution would be to have a
sources/org/w3c/dom/events/CustomEvent.java file which was just the same
as the standard DOM 3 CustomEvent.java file except it also has in it the
members of Event that were introduced in DOM 3.
To be clear of the issue. Someone might pass us an instance
of this interface and we wouldn't be able to find these methods
because if we cast it to the DOM Event interface it might be a
DOM2 Event interface lacking these methods, so our calls would
fail (not to mention that people compiling would have to have
the DOM3 Event interface early in the path so the methods would
appear). Is this the main concern?
As long as there is only one or two of these classes my
leaning would to create 'wrapper' classes that implements our
version of the interface and use Java reflection to call the
methods on the wrapped instance. Then we can check if the
instance passed in implements our interface if so just cast and
use, otherwise wrap it and use it.
Then, users making custom event objects would be forced to implement all
of the DOM 3 methods, which will be needed by the code in
EventSupport.
Having the CustomEvent.java file in sources/org/w3c/dom/events should
mean it is picked up before the one in the DOM 3 xml-apis.jar (according
to the class path search order specified in the sources/*.mf files).
I would strongly prefer to avoid modifying W3C classes/interfaces
especially in the W3C packages, unless it is clearly an error (and
even then preferably with working group approval).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
