You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by "Arnold, Curt" <Cu...@hyprotech.com> on 2001/03/08 00:30:08 UTC

Java "scripting"

Deep background: the thoughts behind this started with the petition to drop <script> from XSLT 1.1 which lead to a comparison between the script elements in SVG, XSLT and XHTML which lead to the idea
that XSLT's concept of supporting multiple implementations (say, COM, Java and Ecmascript) of one behavior was pretty cool and would be useful in SVG.  For the later parts of those threads, you could
check the http://lists.w3.org/Archives/Public/www-svg/2001Mar/0012.html.  Though it isn't essential to the rest of the message.

Has there been any thought (or full implementation) of allowing Java classes to be loaded as "scripts" in Batik.  I would think that something like:

<script type="application/java-archive" xlink:href="jar:http://www.example.com/svgbehaviors.jar!/com/example/draganddrop.class"/>

Could be implemented as:

1) Load the class corresponding to the URL (in this case, a class in a JAR as described in java.net.JarURLConnection)

2) Find a constructor that takes one DOMElement as an argument

3) Call the constructor passing the DOMElement for the <script> element

The constructor could then interact with the DOM, adding listeners on the events it was interested in, etc.

-------

Borrowing the "implements" attribute from XSLT 1.1's script would allow multiple implementations of the same behavior to be specified in the SVG file and the viewer would choose the appropriate one
for the platform.  So you could have something like:

<script implements="http://www.example.com/svgbehaviors/dragdrop" type="application/java-archive" xlink:href="jar:http://www.example.com/svgbehaviors.jar!/com/example/draganddrop.class"/>
<script implements="http://www.example.com/svgbehaviors/dragdrop" type="text/ecmascript">
// script goes here 
</script>

would declare two implementations of the drag and drop behavior, only one of which would be loaded.

Sorry I haven't been able to get into the Batik code yet.

Re: Java "scripting"

Posted by Vincent Hardy <vh...@eng.sun.com>.
Arnold,

So far, here is what has been done for scripting in Batik:

a. UI Event propagation from the graphic (internally represented using
   our GVT OO toolkik for 2D graphics) to scripting event handlers.
   This has been validated and tested with ECMAScript, JPython and 
   Tcl.

b. Script access to the DOM.

Sam Ruby said today on this list that he will try to add more language
support through BSF.

One piece missing (that is on our next big thing on our radar screen)
is to reflect changes to the DOM, that is re-render the portions of 
the document that are impacted by DOM changes. The code is partially 
there, but we have still a fair amount of work to do (probably an
understatement :-). 

For those interested, the reason things are the way they are is
that we focused on all the static SVG features first (we are about
done, except for SVGFonts and text on a path) and linking (almost 
complete, the basic linking features have been working for quite
some time and the more advanced ones are coming soon). Linking 
required event propagation.

So, to get to your question, we have not considered using Java 
"scripting" in the way you suggest, but the timing is right to
open the discussion as we are going to do additional scripting
work. There had been discussions to use Java in a scripted manner
(similar to what is done in, say, JSP) which I thought was interesting,
which, depending on how it is done, might also allow event handlers
to contain Java code...

Vincent.

"Arnold, Curt" wrote:
> 
> Deep background: the thoughts behind this started with the petition to drop <script> from XSLT 1.1 which lead to a comparison between the script elements in SVG, XSLT and XHTML which lead to the idea
> that XSLT's concept of supporting multiple implementations (say, COM, Java and Ecmascript) of one behavior was pretty cool and would be useful in SVG.  For the later parts of those threads, you could
> check the http://lists.w3.org/Archives/Public/www-svg/2001Mar/0012.html.  Though it isn't essential to the rest of the message.
> 
> Has there been any thought (or full implementation) of allowing Java classes to be loaded as "scripts" in Batik.  I would think that something like:
> 
> <script type="application/java-archive" xlink:href="jar:http://www.example.com/svgbehaviors.jar!/com/example/draganddrop.class"/>
> 
> Could be implemented as:
> 
> 1) Load the class corresponding to the URL (in this case, a class in a JAR as described in java.net.JarURLConnection)
> 
> 2) Find a constructor that takes one DOMElement as an argument
> 
> 3) Call the constructor passing the DOMElement for the <script> element
> 
> The constructor could then interact with the DOM, adding listeners on the events it was interested in, etc.
> 
> -------
> 
> Borrowing the "implements" attribute from XSLT 1.1's script would allow multiple implementations of the same behavior to be specified in the SVG file and the viewer would choose the appropriate one
> for the platform.  So you could have something like:
> 
> <script implements="http://www.example.com/svgbehaviors/dragdrop" type="application/java-archive" xlink:href="jar:http://www.example.com/svgbehaviors.jar!/com/example/draganddrop.class"/>
> <script implements="http://www.example.com/svgbehaviors/dragdrop" type="text/ecmascript">
> // script goes here
> </script>
> 
> would declare two implementations of the drag and drop behavior, only one of which would be loaded.
> 
> Sorry I haven't been able to get into the Batik code yet.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org