 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2007Looking for confirmation
Hello all, I'm just looking for confirmation that the following is horrible application design. We have an application (web-based) that contains a JSP which contains an applet which calls some VBScript which activates an ActiveX control which kicks off a TWAIN driver for scanning. Needless to say, the above is very fragile. The slightest change on the client machine(machine which accesses the JSP/applet) or the server (running Apache Tomcat 5.0) causes the appliation to fail. Does anyone have any ideas on how to simplify the above system? HightowerC P.S. Don't blame me for the above program design. I inherited it from other programmers. > Hello all, > I'm just looking for confirmation that the following is horrible [quoted text clipped - 14 lines] > P.S. Don't blame me for the above program design. I inherited it from > other programmers. My suggestion. Consolidate as much as possible into one language. If you're using ActiveX to handle the TWAIN drivers, my suggestion is on the client side use ActiveX exclusively. As for the rest of it, the JSP should be fine.  SignatureDaniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> ... >I'm just looking for confirmation that the following is horrible >application design. > >We have an application (web-based) that contains a JSP which contains >an applet ... You can stop right there. Applets embedded in web pages are subject to a new bug 'every other month'*. They are high maintenance, and therefore (in my perspective) bad design. * Though "applets embeded in web pages that interact with.." might raise that to "a new bug every other week". SignatureAndrew Thompson http://www.physci.org/ [Snip] > You can stop right there. Applets embedded in web pages > are subject to a new bug 'every other month'*. They are high > maintenance, and therefore (in my perspective) bad design. [Snip] OK, I'll bite. Why are applets prone to more bugs than other Java applications? SignatureKenneth P. Turvey <kt-usenet@squeakydolphin.com> > [Snip] >> You can stop right there. Applets embedded in web pages [quoted text clipped - 4 lines] > OK, I'll bite. Why are applets prone to more bugs than other Java > applications? Short version - because browsers are so widely variant in their support for applets. Sometimes "support for applets" is at best a vague hand wave and a hope. SignatureLew >> [Snip] >>> You can stop right there. Applets embedded in web pages [quoted text clipped - 4 lines] >Short version - because browsers are so widely variant in their support for >applets. Sometimes "support for applets" is at best a vague hand wave and a hope. Yes. OTOH - Launching applets via web start removes a lot of that 'browser variance', but makes little sense, since a JWS launched applet can no longer interact with JS, or other applets. Once you go to web start, you might as well look directly to (J)Frames, which can at least be resized (more easily). SignatureAndrew Thompson http://www.physci.org/ >>> You can stop right there. Applets embedded in web pages are subject >>> to a new bug 'every other month'*. They are high [quoted text clipped - 6 lines] > for applets. Sometimes "support for applets" is at best a vague hand > wave and a hope. If used a bit conservative, then Java applets should run fine for many years without problems. If you write the applet assuming that: two applets on the same page will be running in the same JVM, that the applet will run before the JavaScript function foobar, that the display is 1280x1024, that the PC is single core and that the path to the default mail program is always xxxxx, then it will break every month. A nice little applet that displays a graph based on some params tags should not break. Arne ... > If used a bit conservative, then Java applets should run fine for > many years without problems. Unfortunately, they don't. ... > A nice little applet that displays a graph based on some > params tags should not break. a) If it is that simple, why not insert a GIF of the graph and be done with it? b) That 'nice little applet' is still subject to the bug that appeared in FF some months ago, where the entire applet is reloaded if the user scrolls 'up'. That is not 'entirely broken', but it sure is not 'working smoothly'. -- Andrew T. PhySci.org >> If used a bit conservative, then Java applets should run fine for >> many years without problems. > > Unfortunately, they don't. They seems to here. >> A nice little applet that displays a graph based on some >> params tags should not break. > > a) If it is that simple, why not insert a GIF of the > graph and be done with it? You may think GIF's can read param tags. But they can not. Arne > ... >> If used a bit conservative, then Java applets should run fine for >> many years without problems. > > Unfortunately, they don't. Mine have. They have been since 1.4.2. One is running at this very moment, downloading and displaying real-time data on a triple-head, non-interactive display system. The data is downloaded from a servlet running in a Tomcat server. It's a bad workman that blames his tools ;-) SignatureNigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 >> ... >>> If used a bit conservative, then Java applets should run fine for [quoted text clipped - 3 lines] > >Mine have. Where? Your browser? How do you get error reports from your users? Who are your users (a limited group of corporate users - all using IE, or 'anybody on the internet')? How do you *encourage* those users to report problems? Without that information, I regard such claims as so much 'huff and puff'. >..They have been since 1.4.2. One is running at this very moment, >downloading and displaying real-time data on a triple-head, non-interactive >display system. The data is downloaded from a servlet running in a Tomcat >server. > >It's a bad workman that blames his tools ;-) It's an even poorer workman that presumes the applet is fine, simply because it 'works in my browser' and you hear nothing from the users. I will brook no crap about 'my applet is fine', until somebody puts up a freakin' URL to one such 'fine' applet for my (and the world's) scrutiny. I will be particularly interested in hitting this URL with a browser using Java 1.2*, and with JS disabled, just to see/report what happens. * And yes, that is entirely valid for checking a '1.4' applet. That the page deals with that gracefully, in terms of.. - reporting something logical back to the user, or - a link/redirect to a page that explains the problem, or - link/redirect to 'support'. And to Arne: "You may think GIF's can read param tags. But they can not." I am under no such illusion. But if you have an active server writing the pages 'with params', it might also generate GIFs dynamically. And if the params were being written 'client side' using JavaScript? Using a few simple GIFs in an appropriately styled table, and using JS to stretch a 1x1 pic for the 'bars' - you can draw a pretty decent bar graph. No time to wait for the JVM to load, no 'entire applet reload' when the FF user scrolls 'up', no need for the IE user to click the 'run this applet' thing.., but OTOH lightweight, with textual labels that can easily be made to adopt the natural font-family and size of the site, or as needed, the user's custom stylesheets or size choices, and with easier customization (via print stylesheets) for printing. Oh go on. Say you wanted a 'pie chart'. ;-) SignatureAndrew Thompson http://www.physci.org/ >>> ... >>>> If used a bit conservative, then Java applets should run fine for [quoted text clipped - 21 lines] > > It's an even poorer workman No, it isn't. The "poor workman" is the one who blames the tools, rather than himself. > that presumes the applet > is fine, simply because it 'works in my browser' and > you hear nothing from the users. I know it works. It runs 24/7 on a display in the corridor for everyone to see. I don't need any "users" to tell me if it stops working. > I will brook no crap about 'my applet is fine', until > somebody puts up a freakin' URL to one such 'fine' > applet for my (and the world's) scrutiny. I doubt you have the ability to be objective on this matter. Perhaps you would first care to backup your assertion that "Applets embedded in web pages are subject to a new bug 'every other month'" with verified bug reports from every other month. SignatureNigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 >>>> ... >>>>> If used a bit conservative, then Java applets should run fine .. ... >> It's an even poorer workman > >No, it isn't. The "poor workman" is the one who blames the tools, Do you include 'the' browser as a tool? >...rather than himself. > [quoted text clipped - 3 lines] > >I know it works. It runs 24/7 on a display in the corridor Getting one applet to run on one instance of 'the' single (possibly 'locked in') browser on a PC (presumably) controlled by you, is *trivial*. I cannot understand why you bothered to mention it. But that is not how I think of applets.* My first question in that situation, would be .. why bother with an applet at all, for this 'Kiosk like(?)' installaion, why not just run it as a Frame or Window? * To my way of thinking, an applet lives on the internet, and is available to users of the vast majority of OSs and browsers... >..for everyone to see. ..for everyone to surf to. Anything less is a (largely) pointless use of applets... >I don't need any "users" to tell me if it stops working. > [quoted text clipped - 3 lines] > >I doubt you have the ability to be objective on this matter. For a publicly available URL, my objectivity is largely irrelevant, since others can also report their own experiences and thoughts that might be contrary to my own. So - what is your point? >Perhaps you would first care to backup your assertion that "Applets embedded in >web pages are subject to a new bug 'every other month'" <http://www.google.com/search?as_q=applet&as_filetype=&as_sitesearch=bugs.sun.com 3,410 hits 1997(?)-2007 = 10 years, or 120 months 3,410/120 = 28.42/month But that is 'hits', as opposed to bug reports specifically.** (And in case anybody is wonderring, Sun's own search facility is altogether too slow from here - I use Google) But we can argue 'statistics' all day - and get nowhere. My original assertion 'one every other month' was neither carefully measured, nor meant to be definitive. Did I forget to put it in quotes earlier? >..with verified bug >reports from every other month. ** As to how many of those hits are bug reports? How many of those bug reports are *verified*?*** (shrugs) I have better things to do. Feel free to check them yourself, though, if it takes your fancy. I am more interested in seeing any one single URL of the 'infallible (web) applet'. *** Of course.. <http://www.google.com/search?hl=en&q=applet+site%3Abugs.sun.com+-%22not+a+bug%22 shows 1,460 hits - knocks almost 2,000 off. OTOH this is rather disturbing, 77(?) bugs that 'will not be fixed'.. <http://www.google.com/search?hl=en&q=applet+site%3Abugs.sun.com+-%22not+a+bug%22 +%22will+not+be+fixed%22 I might almost have said .. Applets are subject to a bug 'every other month' that will *never* be fixed. SignatureAndrew Thompson http://www.physci.org/ > "You may think GIF's can read param tags. But they can not." > > I am under no such illusion. But if you have an active > server writing the pages 'with params', it might also > generate GIFs dynamically. True. But then every user interaction manipulating the display would require a server roundtrip. > And if the params were being written 'client side' using > JavaScript? [quoted text clipped - 9 lines] > stylesheets or size choices, and with easier customization > (via print stylesheets) for printing. I would expect that to be more maintenance work and worse graphical quality than an applet. Arne > >We have an application (web-based) that contains a JSP which contains > >an applet ... > > You can stop right there. Applets embedded in web pages > are subject to a new bug 'every other month'*. They are high > maintenance, and therefore (in my perspective) bad design. I knew you would said something like that! :) HightowerC On Fri, 7 Dec 2007 09:26:20 -0800 (PST), HightowerC <chris.hightower@gmail.com> wrote, quoted or indirectly quoted someone who said : >Does anyone have any ideas on how to simplify the above system? It is not clear if the twain scan is happen on the client or the server. If the client, use JAWS. See http://mindprod.com/jgloss/javawebstart.html if the server, call the twain directly from a Servlet. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Thanks everyone for your replies. I'll forward this thread to my "higher up's", and hopefully this will push them towards a rewrite of this part of the application. Much appreciation to all. HightowerC Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.