Steve Buonincontri <[EMAIL PROTECTED]> 03-Jan-00 asks:
> >1) Why does the server repaint the intial html window, even
> >with a dummy html page when a post to a servlet does not
> >respond with IO?
Nic Ferrier responds:
> The browser repaints the page after nearlly every request, the only
> server response (that I am aware of) that doesn't cause a page repaint
> is NOT_MODIFIED.
Yup, I tried this one on another project and it worked. But I
seem to recall that n some browsers this causes undesirable behavior
(dialog boxes popping up).
> >That is, I want to click, click, click, click on the check boxes
> >and have servlets do there thing without hangin up the client
> >html front end.
>
> tricky...
>
> This is not really a problem with servlets... it's a general web
> architecture thing. The web is designed around batch dispatch of
> interaction data (eg: forms) not live update (like you might have in
> an old client-server type app).
>
> It sounds to me like you should redesign your system to take heed of
> this.
Also yup. There are some workarounds you can try, but the only
way is to use javascript, and you will quickly find that unless you
can restrict the range of clients you need to support, you're opening
a very large, very messy can of worms. The different versions and
flavors of browsers have radically different document object models.
Anytime you try to do anything beyond the trivial with javascript,
you're on thin ice.
> >3) What is the best way to invoke servlets in the backround
> >and have the most interactive front end as possible?
>
> This is really not how servlets are used. But you could use an applet
> on the web page to talk to a servlet (or any other kind of server type
> thing, eg: CORBA) and that would give you a little more
> flexibility....
Assuming changing the design is not an option, an applet is your
best bet. I have messed around a lot with using hidden frames and
javascript to fake things like this. As long as you keep your
requirements very rudimentary, this may suffice, but quite likely
you'll end up in a quagmire of browser compatibility issues that can
only be resolved by an excruciatingly painful and tiresome
code/test/recode cycle.
For example, you could have a hidden frame on the page (it won't
be truly hidden, it'll be about one pixel wide, you'll have to tweak
the appearance of the page to hide it further). Now on the form you
can have the form target the hidden frame (<FORM TARGET="myhiddenframe">
and the servlet results will go to that window. This will fulfill your
basic requirement.
However, there are some gotchas.
First, this won't work with checkboxes as you've described. You
could have a bunch of forms, each one with its own checkbox. It won't
be pretty, and it won't work quite the way you wanted it to, but it'll
work and without too much javascript. Or you could make each checkbox
an image with a bit of javascript that swaps in a "checked" image and
sets the window.location of the hidden frame to the appropriate
servlet, using a GET style query.
Of course, doing it this way means you'll be mucking around with
a lot more javascript, which introduces many more opportunities for
javascript incompatibilities and document object model differences to
crop up. But you can solve those with a few hundred hours of tweaking
the javascript and trying out the page under different browsers.
Which brings us to gotcha #2, what if the user clicks on too many
buttons too quickly? When you re-set the window location, the browser
conveniently kills off the first request and starts a new request. So
you'll have to set up an individual hidden frame for each form, so the
output from each form goes to a separate window. How many checkboxes
were you planning to have, anyway?
> But as I say, usually when people ask these questions (IMHO) it's
> because they've got the design wrong, change the design to fit in with
> web architecture and everything gets better.
Sound advice, Steve, I suggest you take it! Getting too wrapped
up in UI nuances on the web is a sure route to disaster. Either write
an applet and implement your own GUI, or just use the web's standard
interface and architecture.
Steven J. Owens
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
