You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Urs Reupke <ur...@gmx.net> on 2006/01/26 10:52:14 UTC

ECMA Script vs Java

Hello,
my ongoing project needs some refinement in it's SVG parts.
Currently, we're using Swing components rendered over a SVG image
for user input, but since the SVG images will be zoomable soon,
this is no longer an option.
Thus, I am about to create an SVG replacement for the Swing interface,
and was wondering whether I should script the visual behaviour of the 
interface using ECMA script or Java.

Here's what I need to do:
The interface consists of a row of buttons.
The user can either click on of the buttons to select all of them up to 
the clicked one.
As an alternative, one can click&hold somewhere within the bounds of the 
component to have a selection rectangle appear. This rectangle stretches 
from the left side of the component up to the x-coordinate clicked. The 
x-coordinate can be adjusted by drag and drop. After releasing the 
mousebutton, all of the buttons currently under the rectangle are selected.

It's pretty simple, for most parts, but the adjustable rectangle made me 
wondering:
Is one of the two, ECMA or Java clearly superior in terms of speed, 
capabilities or ease of development (in an Batik/SVG context, of course)?

Thanks
-Urs

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


Re: ECMA Script vs Java

Posted by Urs Reupke <ur...@gmx.net>.
Hi Thomas,

thanks for your thorough analysis.
Your assumption about no one here having working knowledge about ECMA 
script is correct.
For now, I have implemented the UI in Java, but I hope to find the time 
tomorrow to convert it to ECMA script and maybe learn a bit or two in 
the process.

> Also having
> the UI in one language and the bulk of the app in another has
> a secondary effect of ensuring a clean separation of the UI from
> the application engine. 

Luckily, that's not too much of an issue in this case. The existing UI 
is already separated from both presentation logic and the underlying 
model, and anything but re-implementing the existing UI-interfaces for 
the new component would cause more trouble than it's worth.

Working on this has brought up an idea:
 From discussions on this list, I have a rough understanding that Batik 
is able to convert SVG images to a number of different bitmap formats,
such as PNG.
Right now, our distributions come with a set of icons, that differ only 
in the colors used for a single image layer. Currently, there are 30 
icons (10 variants in 3 sizes each).
I guess it would be no big deal to re-build these icons using SVG and 
exchange the color-layer for each of them on-the-fly. This would allow 
for much simpler extension and modification in the future.

What I'd like to know is, whether the transcoder system is fast enough 
generate the images at runtime without too much of a slowdown.


Regards
-Urs

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


Re: ECMA Script vs Java

Posted by th...@kodak.com.
Hi Urs,

Urs Reupke <ur...@gmx.net> wrote on 01/26/2006 05:25:05 AM:

> We are using Batik within the confines of a single Java application,
> with no foreseeable need to port the SVG part to any other platform.
> The interactive component would not have to run anywhere except in 
> Batik's JSVGCanvas.

   This, in my mind simply makes Java an option.  Not necessarily 
the primary option.

> I assume that, given that knowledge, you would implement in Java?

   If I am correct in assuming that no one working on your project
knows much ECMA script then I would suggest sticking with Java,
it doesn't take long to transfer skills from Java to ECMA Script but
the first project you do will be a bit of a mess, and likely a 
bit frustrating.

   That said I'm a strong believer in using languages for what 
they are good at.  Java has a lot of nice rigid rules a large 
powerful class library and runs at good speed for complex tasks. 
Ecma Script is flexible and loosely typed, it is also interpreted.

   I'm personally of a mind that interpreted languages are really
best for interacting with people.  They can make it easy/quick to 
tweak the interface, track what is going on, etc.  Also having
the UI in one language and the bulk of the app in another has
a secondary effect of ensuring a clean separation of the UI from
the application engine. 

   Mitigating this Java has some aspects of an interpreted
language, 1-2min change to running time vs 10+min for typical
large C/C++ app, but changing a script in the SVG is just a 'reload'
away from being active (seconds).

   In the end, it doesn't sound like you are building a
particularly large/complex UI and mostly I think we are taking 
about a small difference in speed of development so as I said
above if you aren't already familiar with ECMA Script I
would stick to Java, but if you have some 'free time' it
might be worth your while to build some experience with
ECMA Script - for the next project (ECMA is a good
language to know, given it's pervasiveness on the web).

 
 

> 
> Regards
> -Urs
> 
> 
> Andreas Neumann wrote:
> > Hi Urs,
> > 
> > well both have advantages/disadvantages.
> > 
> > The advantage of Java might be that you can integrate with other Java 
> > components and use Batik within a standalone java program. Also Java 
is 
> > the more powerful language.
> > 
> > The advantage of ECMAScript is, that it is better portable to other 
SVG 
> > viewers and web browsers. F.e. examples scripted in ECMAScript also 
work 
> > in the Adobe SVG viewer, Mozilla SVG and in the upcoming versions of 
> > Opera 9 and Safari with native SVG support.
> > 
> > Btw:
> > at
> > http://www.carto.net/papers/svg/gui/ you can find a couple of 
> > ECMAScripts for GUI elements. Not very sophisticated, but they might 
be 
> > a starting point for further work.
> > 
> > Andreas
> > 
> > Urs Reupke wrote:
> > 
> >> Hello,
> >> my ongoing project needs some refinement in it's SVG parts.
> >> Currently, we're using Swing components rendered over a SVG image
> >> for user input, but since the SVG images will be zoomable soon,
> >> this is no longer an option.
> >> Thus, I am about to create an SVG replacement for the Swing 
interface,
> >> and was wondering whether I should script the visual behaviour of the 

> >> interface using ECMA script or Java.
> >>
> >> Here's what I need to do:
> >> The interface consists of a row of buttons.
> >> The user can either click on of the buttons to select all of them up 
> >> to the clicked one.
> >> As an alternative, one can click&hold somewhere within the bounds of 
> >> the component to have a selection rectangle appear. This rectangle 
> >> stretches from the left side of the component up to the x-coordinate 
> >> clicked. The x-coordinate can be adjusted by drag and drop. After 
> >> releasing the mousebutton, all of the buttons currently under the 
> >> rectangle are selected.
> >>
> >> It's pretty simple, for most parts, but the adjustable rectangle made 

> >> me wondering:
> >> Is one of the two, ECMA or Java clearly superior in terms of speed, 
> >> capabilities or ease of development (in an Batik/SVG context, of 
course)?
> >>
> >> Thanks
> >> -Urs
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: 
batik-users-unsubscribe@xmlgraphics.apache.org
> >> For additional commands, e-mail: 
batik-users-help@xmlgraphics.apache.org
> >>
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 


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


Re: ECMA Script vs Java

Posted by Urs Reupke <ur...@gmx.net>.
Hi Andreas,

We are using Batik within the confines of a single Java application,
with no foreseeable need to port the SVG part to any other platform.
The interactive component would not have to run anywhere except in 
Batik's JSVGCanvas.
I assume that, given that knowledge, you would implement in Java?

Regards
-Urs


Andreas Neumann wrote:
> Hi Urs,
> 
> well both have advantages/disadvantages.
> 
> The advantage of Java might be that you can integrate with other Java 
> components and use Batik within a standalone java program. Also Java is 
> the more powerful language.
> 
> The advantage of ECMAScript is, that it is better portable to other SVG 
> viewers and web browsers. F.e. examples scripted in ECMAScript also work 
> in the Adobe SVG viewer, Mozilla SVG and in the upcoming versions of 
> Opera 9 and Safari with native SVG support.
> 
> Btw:
> at
> http://www.carto.net/papers/svg/gui/ you can find a couple of 
> ECMAScripts for GUI elements. Not very sophisticated, but they might be 
> a starting point for further work.
> 
> Andreas
> 
> Urs Reupke wrote:
> 
>> Hello,
>> my ongoing project needs some refinement in it's SVG parts.
>> Currently, we're using Swing components rendered over a SVG image
>> for user input, but since the SVG images will be zoomable soon,
>> this is no longer an option.
>> Thus, I am about to create an SVG replacement for the Swing interface,
>> and was wondering whether I should script the visual behaviour of the 
>> interface using ECMA script or Java.
>>
>> Here's what I need to do:
>> The interface consists of a row of buttons.
>> The user can either click on of the buttons to select all of them up 
>> to the clicked one.
>> As an alternative, one can click&hold somewhere within the bounds of 
>> the component to have a selection rectangle appear. This rectangle 
>> stretches from the left side of the component up to the x-coordinate 
>> clicked. The x-coordinate can be adjusted by drag and drop. After 
>> releasing the mousebutton, all of the buttons currently under the 
>> rectangle are selected.
>>
>> It's pretty simple, for most parts, but the adjustable rectangle made 
>> me wondering:
>> Is one of the two, ECMA or Java clearly superior in terms of speed, 
>> capabilities or ease of development (in an Batik/SVG context, of course)?
>>
>> Thanks
>> -Urs
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
> 
> 


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


Re: ECMA Script vs Java

Posted by Andreas Neumann <ne...@karto.baug.ethz.ch>.
Hi Urs,

well both have advantages/disadvantages.

The advantage of Java might be that you can integrate with other Java 
components and use Batik within a standalone java program. Also Java is 
the more powerful language.

The advantage of ECMAScript is, that it is better portable to other SVG 
viewers and web browsers. F.e. examples scripted in ECMAScript also work 
in the Adobe SVG viewer, Mozilla SVG and in the upcoming versions of 
Opera 9 and Safari with native SVG support.

Btw:
at
http://www.carto.net/papers/svg/gui/ you can find a couple of 
ECMAScripts for GUI elements. Not very sophisticated, but they might be 
a starting point for further work.

Andreas

Urs Reupke wrote:

> Hello,
> my ongoing project needs some refinement in it's SVG parts.
> Currently, we're using Swing components rendered over a SVG image
> for user input, but since the SVG images will be zoomable soon,
> this is no longer an option.
> Thus, I am about to create an SVG replacement for the Swing interface,
> and was wondering whether I should script the visual behaviour of the 
> interface using ECMA script or Java.
>
> Here's what I need to do:
> The interface consists of a row of buttons.
> The user can either click on of the buttons to select all of them up 
> to the clicked one.
> As an alternative, one can click&hold somewhere within the bounds of 
> the component to have a selection rectangle appear. This rectangle 
> stretches from the left side of the component up to the x-coordinate 
> clicked. The x-coordinate can be adjusted by drag and drop. After 
> releasing the mousebutton, all of the buttons currently under the 
> rectangle are selected.
>
> It's pretty simple, for most parts, but the adjustable rectangle made 
> me wondering:
> Is one of the two, ECMA or Java clearly superior in terms of speed, 
> capabilities or ease of development (in an Batik/SVG context, of course)?
>
> Thanks
> -Urs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>


-- 
----------------------------------------------
Andreas Neumann
Institute of Cartography
ETH Zurich
Wolfgang-Paulistrasse 15
CH-8093  Zurich, Switzerland

Phone: ++41-44-633 3031, Fax: ++41-44-633 1153
e-mail: neumann@karto.baug.ethz.ch
www: http://www.carto.net/neumann/
SVG.Open: http://www.svgopen.org/
Carto.net: http://www.carto.net/


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