Hi Cameron,
Cameron McCormack wrote:
I'm still working on sXBL support for Batik and again I'm wondering
about how separate code for 1.2 features should be. A few particular
issues:
Yes, all good questions. See answers inline. I'm still thinking
about possible alternate options, but right now they all seem pretty
horrible...
- What should be done for DOM 3 support? Should the existing classes
in org.apache.batik.dom be updated with DOM 3 methods and so on?
As you point out below the way W3C is doing it's interfaces I
don't think we have any choice here we will have to have DOM3 on
everything. It would have been nice if they had added the DOM3
methods by 'sub-interfacing' into a org.w3c.dom3 package. Since all
they specify is interfaces they could have used multiple inheritance.
I don't think it's a good idea to try and get 'tricky' with
classloaders (although as I understand it this can be done fairly
cleanly).
One option we do have available is to have DOM 3 methods
throw exceptions if we are processing a 1.1 document. This still
isn't great since you really want to pick these things up at compile
time (at least for Java - for JavaScript it doesn't matter much).
I suppose one could bundle DOM2 and SVG 1.1 jars that people could
compile against. What do you think?
BTW the xml-apis in JDK 1.5 is DOM 3 :/
should separate DOM 3 objects only be created for version="1.2"
documents and DOM 2 objects created for version="1.1" documents? I
guess there will only be one set of org.w3c.dom interfaces, those
being the DOM 3 ones. (Isn't this going to make it difficult for
people to run Batik without messing around with bootclasspaths or
"endorsed standards override" jars, like with Xalan[1]?)
- I don't think I can properly separate sXBL DOM (such as all elements
having to implement NodeXBL) from the SVG DOM classes without much
code duplication. The easist thing (and what I've done so far) is
to extend from the Abstract* classes in org.apache.batik.dom to
sXBL capable DOM classes in org.apache.batik.dom.xbl. Then, I have
org.apache.batik.dom.svg.AbstractElement extend
org.apache.batik.dom.xbl.XBLElement. This does mean though that
version="1.1" documents will have sXBL DOM functionality.
This is in fact potentially more manageable as ANT could be
used to create two copies of dom.svg one where classes inherit from
XBLElement and one where they inherit from AbstractElement (assuming
that there is little or no XBL-ness in the SVG subclass). However
I suspect that in the fullness of time it will be best to just add
NodeXBL to the 1.1 impl (*sigh*).
- Since event flow works differently in the presence of sXBL, I found
the need to modify org.apache.batik.dom.events.AbstractEvent to
handle things like event retargetting and stopping, so that the
EventSupport class wouldn't be polluted with sXBL specific things.
If I were to keep this properly separate for version="1.2" documents
I would have to have different classes for DOMEvent, DOMUIEvent,
etc.
I'm a little less sure here, but given we added 1.2 to
everything else unless there are significant 'incompatibilities'
I'd be tempted to just have one set of event classes. I'm a little
surprised that you don't need XBL stuff in EventSupport anyways.
- In light of this message
http://lists.w3.org/Archives/Public/www-svg/2005Jan/0029.html
I think it would be difficult to handle documents whose version
changes if there is a particular DOMImplementation that is chosen at
document parse time.
I think the proposal that the 'version' attribute can be
change (and modify document behavior) is ridiculous. What is the
usecase? If it were free then fine but it will be far from free for
all implementations (at the very least requiring a walk of the tree -
looking for now invalid things) and there really isn't a single good
usecase I can think of.
Let's take the case of an existing reference to a node it
suddenly needs to lose/gain it's SVG 1.2ness? seems silly to me.
Any thoughts?
Thanks,
Cameron
[1] http://xml.apache.org/xalan-j/faq.html#faq-N100CC
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
