Looking for confirmation

Discussion in 'Java' started by HightowerC, Dec 7, 2007.

  1. HightowerC

    HightowerC Guest

    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.
     
    HightowerC, Dec 7, 2007
    #1
    1. Advertising

  2. HightowerC

    Daniel Pitts Guest

    HightowerC wrote:
    > 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.

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
     
    Daniel Pitts, Dec 7, 2007
    #2
    1. Advertising

  3. 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
     
    Andrew Thompson, Dec 8, 2007
    #3
  4. 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?

    --
    Kenneth P. Turvey <>
     
    Kenneth P. Turvey, Dec 8, 2007
    #4
  5. HightowerC

    Lew Guest

    Kenneth P. Turvey wrote:
    > 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.

    --
    Lew
     
    Lew, Dec 8, 2007
    #5
  6. Lew wrote:
    >> [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).

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

    Message posted via http://www.javakb.com
     
    Andrew Thompson, Dec 8, 2007
    #6
  7. HightowerC

    Roedy Green Guest

    On Fri, 7 Dec 2007 09:26:20 -0800 (PST), HightowerC
    <> 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.
    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Dec 8, 2007
    #7
  8. Lew wrote:
    > Kenneth P. Turvey wrote:
    >> On Sat, 08 Dec 2007 02:21:59 +0000, Andrew Thompson 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.

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


    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
     
    Arne Vajhøj, Dec 8, 2007
    #8
  9. On Dec 9, 4:29 am, Arne Vajhøj <> wrote:
    ...
    > 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
     
    Andrew Thompson, Dec 9, 2007
    #9
  10. HightowerC

    Arne Vajhøj Guest

    Andrew Thompson wrote:
    > On Dec 9, 4:29 am, Arne Vajhøj <> wrote:
    >> 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
     
    Arne Vajhøj, Dec 9, 2007
    #10
  11. HightowerC

    HightowerC Guest

    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, Dec 10, 2007
    #11
  12. HightowerC

    HightowerC Guest

    On Dec 7, 8:21 pm, "Andrew Thompson" <u32984@uwe> wrote:
    > HightowerC wrote:


    > >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
     
    HightowerC, Dec 10, 2007
    #12
  13. HightowerC

    Nigel Wade Guest

    Andrew Thompson wrote:

    > On Dec 9, 4:29 am, Arne Vajhøj <> wrote:
    > ...
    >> 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 ;-)

    --
    Nigel Wade, System Administrator, Space Plasma Physics Group,
    University of Leicester, Leicester, LE1 7RH, UK
    E-mail :
    Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
     
    Nigel Wade, Dec 10, 2007
    #13
  14. Nigel Wade wrote:
    >> ...
    >>> If used a bit conservative, then Java applets should run fine for
    >>> many years without problems.

    >>
    >> Unfortunately, they don't.

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

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

    Message posted via http://www.javakb.com
     
    Andrew Thompson, Dec 11, 2007
    #14
  15. HightowerC

    Nigel Wade Guest

    Andrew Thompson wrote:

    > Nigel Wade wrote:
    >>> ...
    >>>> If used a bit conservative, then Java applets should run fine for
    >>>> many years without problems.
    >>>
    >>> Unfortunately, they don't.

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


    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.

    --
    Nigel Wade, System Administrator, Space Plasma Physics Group,
    University of Leicester, Leicester, LE1 7RH, UK
    E-mail :
    Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555
     
    Nigel Wade, Dec 11, 2007
    #15
  16. Nigel Wade wrote:
    >>>> ...
    >>>>> 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.
    >
    >> 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


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


    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.

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

    Message posted via http://www.javakb.com
     
    Andrew Thompson, Dec 12, 2007
    #16
  17. Andrew Thompson wrote:
    > "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
     
    Arne Vajhøj, Dec 17, 2007
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. sramruttun

    Re: delete confirmation in datagrid

    sramruttun, Jul 4, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    614
    sramruttun
    Jul 4, 2003
  2. Michal A. Valasek

    Re: Server Side Confirmation pop-up...

    Michal A. Valasek, Jul 25, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    602
    Michal A. Valasek
    Jul 25, 2003
  3. S. Justin Gengo

    Re: Server Side Confirmation pop-up...

    S. Justin Gengo, Jul 25, 2003, in forum: ASP .Net
    Replies:
    9
    Views:
    535
    Daniel Bass
    Jul 28, 2003
  4. Gönen EREN

    linkbutton: confirmation with javascript

    Gönen EREN, Aug 12, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    992
    Natty Gur
    Aug 13, 2003
  5. Alek Davis
    Replies:
    1
    Views:
    6,380
    Alek Davis
    Aug 29, 2003
Loading...

Share This Page