In my comapny we have an grpahic editor which displays and animates the values of the variables of a PLC. Now my goal is study different technologies based on following criterias to enhance(or replace) the current editor.
1. Very good Look and feel 2. small size 3. connectivity with jar files.
Can anyone of you suggest me some technologies to go through. Please help me out.
SCJP 1.4<br /> <br />preparing for SCWCD
author and iconoclast
I don't know what a "PLC" is, and you haven't told us what features of the existing editor you need to improve upon. Given that Swing's look-and-feel is swappable, and given that "connectivity with jar files" is a fundamental property of Java which doesn't seem relevant to the problem, we're left with "small size." What's "small?" Memory use? Lines of code? Footprint on disk? Simple API? And how "big" is the existing tool?
Hi, thanks for your reply. Dont worry about PLCs. They are here just means of sending data to the GUI editor.
We have an editor that we need to launh on web. the editor (toolbar of the editor) has some widgets like progressbar, spinner etc which needs to be dragged into the editor. Using those values sent by PLC the widgets are to be animated (like showing progress on progress bar). Now we are doing that with the help of Applets.Now my area of concern are,
1. The editor take much time to get launched on the web. I need to minimize this time. 2. Improve the look and feel of the editor 3. The current size of whole application is aroung 600 kb. I am asked to make it around 300 kb. 4. The editor needs to get some files from .jar file. SO i need to make sure that the new editor also can access contents of that jar.
In this regard they have asked to me to enlist some technologies that address the above points. I think now you got the point. I am confused as to where to begin. Help me if you can.
author and iconoclast
Well, you mentioned AJAX, and that's definitely a way to write nice-looking, interactive web applications that have tiny download sizes. The problem is, of course, that they won't be able to use your jar files on the client; there's no client-side Java in an AJAX application. In an AJAX application, all that sort of code goes on the server.
Of course, it might be possible to do that with your applet-based application, too -- move a lot of the code to a servlet, and let the applet communicate with it. That would make it smaller. It wouldn't affect the appearance, though.
If you're currently using an AWT Applet, you could use a JApplet (Swing applet) instead -- this would help it to look much better. So one overall strategy could be move the applet to Swing, and move as much code up to the server as possible to get the download size down.
Yet another alternative would be to use Java Web Start. The nice thing about this is that the user has to download the app only once -- after that, it runs off the local hard disk. You could give it a Swing GUI so it looks nice.