xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From xml-batik-...@apache.org
Subject [XML Graphics - Batik Wiki] New: SVG12Branch
Date Tue, 22 Feb 2005 14:42:27 GMT
   Date: 2005-02-22T06:42:27
   Editor: CameronMcCormack
   Wiki: XML Graphics - Batik Wiki
   Page: SVG12Branch
   URL: http://wiki.apache.org/xmlgraphics-batik/SVG12Branch

   no comment

New Page:

##language:en
#pragma section-numbers off

= The svg12 Branch =
There is a branch in the Batik CVS called 'svg12', which will contain major code additions
for SVG 1.2 support.  Currently, it has support for:

  * DOM Level 3 Core, Events and X``Path
  * Mouse wheel events

===== Checking out the svg12 branch =====

To check out the svg12 branch, use:

{{{
cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
password: anoncvs

cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic checkout -r svg12 xml-batik
}}}

===== Using DOM 3 features =====

JDKs < 1.5 include the DOM 2 interfaces and this can cause problems when
trying to use the DOM 3 versions of these same interface files (org.w3c.dom).
To work around this, the package org.apache.batik.dom.dom3 contains interfaces
with the same names as the DOM 3 interfaces, which can be used instead of
the org.w3c.dom inerfaces when you want to use some DOM 3 functionality.

This is because, for example, referring to org.w3c.dom.Node in a 1.4 JDK
will get you the DOM 2 Node interface, and you won't be able to access the new
DOM 3 methods.  The org.apache.batik.dom.dom3 interfaces all extend their
org.w3c.dom counterparts and then add the DOM 3 methods and constants.
In a 1.4 JDK, this will result in an interface with the DOM 2 methods supplied
by the org.w3c.dom interface and the DOM 3 methods from the org.apache.batik.dom.dom3
interface.  Under a 1.5 JDK, the org.w3c.dom interfaces will already include
the DOM 3 methods, and including them again on the org.apache.batik.dom.dom3
interfaces causes no harm.

Thus, if you want to write code using DOM 3 functionality that will work on all
JDKs supported by Batik, you should cast DOM objects to the interfaces in
org.apache.batik.dom.dom3.

An example:
{{{
  import org.apache.batik.dom.svg.SVGDOMImplementation;
  import org.w3c.dom.DOMImplementation;
  import org.w3c.dom.Document;
  import org.w3c.dom.Element;

  public class C {
      public void f() {
          // Create a new SVG document
          DOMImplementation impl = SVGDOMImplementation.getDOMImplementation();
          Document doc = impl.createDocument("http://www.w3.org/2000/svg", "svg", null);

          // Create a 'g' element and append it to the root 'svg' element
          Element e = doc.createElementNS("http://www.w3.org/2000/svg", "g");
          doc.getDocumentElement().appendChild(e);

          // Cast the document object to org.apache.batik.dom.dom3.Document,
          // so that DOM 3 methods will be guaranteed to be visible
          org.apache.batik.dom.dom3.Document document
              = (org.apache.batik.dom.dom3.Document) doc;

          // Now a DOM 3 method can be used
          document.renameNode(e, "http://www.w3.org/2000/svg", "text");
      }
  }
}}}

If this casting to the org.apache.batik.dom.dom3.Document interface was not done,
the code would only compile on JDK 1.5.  (It is possible to use the DOM 3
org.w3c.dom interfaces directly on earlier JDKs, but this requires messing with the bootclasspath.)

Note that using these org.apache.batik.dom.dom3 interfaces is only needed for
the DOM 3 Core and DOM 3 Events interfaces.  There were no earlier versions of
the DOM XPath interfaces to conflict with, so these can be used directly
(org.w3c.dom.xpath).

Of course, none of this matters if you are just using the DOM 3 functionality
in ECMAScript, as the matter of interfaces is hidden from the scripting
environment.

''[I am considering changing the names of the org.apache.batik.dom.dom3 interfaces
so they don't conflict with the standard org.w3c.dom interfaces.  This would then
allow both to be imported, and avoid the ugly long class name references in
the code.  Comments on this are welcome.]''

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org


Mime
View raw message