Thomas DeWeese:
> There is one other issue which is that I would like to put
> out a 1.5.2 before making such a large change (especially if it
> is going to make things difficult for users on JDK 1.5 or less).
> One option would be to fork the code base which would allow this
> work to go in now and still allow for 1.5.2 (and more if needed).
> At the very least we should lay down a CVS tag before this work
> is checked in.
Ok. How about I make a branch for this significant change stuff.
Should I put any new SVG 1.2 code (things that require more than just
adding a new dom.svg12 and bridge.svg12 class) in there too? I'm nearly
finished the sXBL code, so that could go in there as well.
> Unfortunately, I _really_ don't like this.
It is ugly! I wonder whether W3C shouldn't have extended their
org.w3c.dom interfaces rather than replacing them.
> This will make it hard for people to develop and use Batik unless
> they are using JDK 1.5 which will be a big barrier for people. Also I
> think this would bar people from using Batik as an Applet (unless the
> recipient had JDK 1.5 applet software installed).
Oh, yes, that applet reason is a good one.
> So what to do? The best thing I could come up with is a
> "shadow" copy of the DOM3 interfaces. There would be two copies of
> this one that extended DOM3 one that extended DOM2. This would allow
> us to subclass of the shadow copy. The problem is that because the W3C
> interfaces return Node instead of 'ShadowNode' we would have to downcast
> (to our shadow interfaces) everytime we wanted to call a DOM3 method
> (otherwise it wouldn't compile or run on JDKs < 1.5).
Would you really need the one that extended the DOM 3 interfaces? If
you just extend whatever DOM interface is available, to add the DOM 3
methods, it shouldn't matter that under JDK 1.5 the DOM 3 methods appear
again on the extended interfaces.
> > [...DOM 3 methods in version "1.1" documents...]
> I tend to agree. This does raise the issue of if we do the above
> we are only "1.2 compliant" if they use a DOM3 xml-apis.
Yeah, it won't be strictly DOM 3 compliant when compiling on JDK < 1.5.
It seems a reasonable tradeoff for not having to messing with
bootclasspaths.
Also, I was writing the other night support for the mouse wheel event of
SVG 1.2, but the AWT MouseWheelEvent is only supported in JDK >= 1.4.
What do you think the strategy for including this should be? Break out
the MouseWheelEvent specific code into a helper class and compile this
in conditionally with some trickery in Ant? Or, have two different
versions of (for example) BridgeEventSupport (one extending from the
other) and then choosing which one to include in Ant. Though this
second one wouldn't work with BridgeEventSupport, being a class full of
static methods.
Cameron
--
e-mail : cam (at) mcc.id.au icq : 26955922
web : http://mcc.id.au/ msn : cam-msn (at) aka.mcc.id.au
office : +61399055779 jabber : heycam (at) jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
