Hi Urs, Urs Reupke <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
