Cameron McCormack wrote:
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?
Yes, I would think so (doesn't a lot of that stuff need/want
some of the DOM 3 stuff).
I'm nearly finished the sXBL code, so that could go in there
as well.
Also very cool. You have been busy.
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.
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.
This is mostly true, except that I presume DOM 3 adds some new
classes and for things to work right they need to subclass the DOM3
class in the DOM 3 shadow, and nothing in the DOM 2 shadow. I
suppose if we really wanted to we might be able to include those
interfaces (well really all of DOM 3 xml-apis, but only the new
classes would "show through" because the others would be hidden by
the JDK classes - I don't know for sure if that would work but I
think it would...).
[...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.
We will need a FAQ but I agree that it is probably the best
that can be accomplished.
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?
FOP has a code structure of src/java, src/java-1.4, so they
can multiple versions of the same class for different JDK builds.
For a case like this it would probably be best to move most of
the code up into a baseclass and then try and have only one
or two methods that are split across JDK versions (like
addGVTListener, in the 1.3 version it would just create
the baseclass Listener, in the 1.4 it would create a subclass
of the baseclass Listener which also handled mouse wheel events -
this is just off the top of my head as an example I haven't looked
at the code enough to know if this is a complete solution).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
