Looking for confirmation

[HightowerC]

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.

 

[Daniel Pitts]

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.

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.

 

[Andrew Thompson]

HightowerC wrote:
...

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".

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1

 

[Kenneth P. Turvey]

On Sat, 08 Dec 2007 02:21:59 +0000, Andrew Thompson wrote:

[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?

 

[Lew]

On Sat, 08 Dec 2007 02:21:59 +0000, Andrew Thompson wrote:

[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?

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.

 

[Andrew Thompson]

[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.

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).

 

[Roedy Green]

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.

 

[Arne Vajhøj]

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.

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

 

[Andrew Thompson]

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'.

 

[Arne Vajhøj]

Unfortunately, they don't.

They seems to here.

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

 

[HightowerC]

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

 

[HightowerC]

HightowerC wrote:

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

 

[Nigel Wade]

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 ;-)

 

[Andrew Thompson]

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'. ;-)

 

[Nigel Wade]

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'.


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.

 

[Andrew Thompson]

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.


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.


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:bugs.sun.com+-"not+a+bug"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:bugs.sun.com+-"not+a+bug"+"will+not+be+fixed"
I might almost have said ..

Applets are subject to a bug 'every other month'
that will *never* be fixed.

 

[Arne Vajhøj]

"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?

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.

I would expect that to be more maintenance work and worse
graphical quality than an applet.

Arne