1 Reply Latest reply on Mar 16, 2011 12:04 PM by gimbal2

    Major lacks in deployJava.js

      I was initially excited when I discovered the Deployment Toolkit.
      Especially I liked:
      1. The thorough browser- and JRE version-checking, and the automatic redirecting to download if JRE wrong or lacking.
      2. The not having to hand-code the JavaScript for generating the correct tags.

      However, upon further inspection I find major flaws and lacks!
      (I am assuming the [clear-text version of deployJava|http://www.java.com/js/deployJava.txt] is up-to-date

      1. The actual applet is embedded using using applet-tags!
      (I started a [seperate thread on this issue|http://forums.oracle.com/forums/thread.jspa?threadID=2191949]. )

      2. Deferred loading:
      In many cases you may want to defer loading the applet until some later time - such as an explicit user interaction, or some other JS event.
      Inline print-statements is useless in this case. I would rather have a function which would return to me complete html-tags as a string, which I would then print to i.e. a div, or a function which I would pass a target div to which the html-tags should be printed.

      3. mayscript, scriptable, id, name, class:
      I must also be able to pass in some critical additional tag parameters - for differentiating multiple instances of applets in the same page, for controlling privileges, intercommunication between applets and JS, and for visual control via CSS.

      4. configuration file:
      Why the separate XML-file? At worst, this is then something that might also have to be generated server-side.
      There should at least be an option to inline all necessary values in the applet-containing HTML-page.
      And if you wanted to do something really useful, in stead use HTML for the configuration-file, so that it could double as an Appletviewer start-file, for quick and easy development and testing. And then make sure that the loading and parsing of this file is done in a separate step by JS, so that you can overwrite and add to any hardcoded testvalues in HTML-config-file, before passing it on to the JS-function which would use it as a basis for loading the applet.

      5. versioning and offline usage:
      How old is the current deployJava.js? Has it been updated since the 2006 copyright?!?
      Surely it has, as there are references to Java 1.6 and to Chrome.
      How about a version number? And/or a last-updated date?!
      The samples suggest that one access deployJava.js directly from Oracles java.com-server. How can we trust that the script is current and "live" - and won't just disappear without notice?
      Also, as I sometimes work offline, I need to run a local copy anyways. So then I would need a version number/date so I can check that I am using the most current and up-to-date version.

      In conclusion.
      I love the idea of a well written JS to handle the tricky Java applet embedding problems.
      But the script has to be really god, up to date.
      There are many providers of JS-libraries that handle this really well. Look around ... jquery, Google, Yahoo, ...
      Come on, Oracle. You can do it to!

      The markup for URLs doesn't work!

      Edited by: 844820 on Mar 16, 2011 4:31 AM
        • 1. Re: Major lacks in deployJava.js
          844820 wrote:
          The markup for URLs doesn't work!
          As stated in your previous rant-thread, Oracle doesn't care. They acquired Sun and adopted Java in the process. If you want to get anything done related to Java right now, do it yourself. You seem to know very well what is wrong, so fix it!