by Steven J. Owens (unless otherwise attributed)
>Well, one of the advantages of using Servlets/JSP/Beans, supposedly, is the
>separation of business/data logic from presentation. I guess you are
>finding one of the downsides.
>I think the subject of effective gui in a browser is pretty big and pretty
>distinct from server-side techniques, whether done in servlets or something
>else. I think you may have to concentrate on the gui area without
>consideration of the server-side, and then work out the links to the
>back-end (via JSP, etc.). A good book on JSP should give some hints, but I
>have none to recommend.
A couple of things some folks specifically asked for:
If you need to have a dynamically generated HREF in a static page, one half-assed workaround would be to have a static HREF that points to the servlet, which would in turn generate the dynamic URL and redirect the request to the URL. This is of limited usefulness in high-security settings, of course, because you have to use GET-style variable passing to the servlet. There's no way to redirect a POST-style form submission, trust me, I know, I spent a good chunk of a year looking for a way.
The reason it's impossible has to do with the MIME types used in HTTP interactions. Basically, browsers and servers talk to each other by passing MIME-encoded chunks of information back and forth. There are two MIME types, single-line and multi-line. I suppose in theory both types could be sent back and forth, but HTTP servers and clients (browsers) are almost universally coded to only use multi-line MIME types when going from the browser to the server.
In a redirect, the browser sends the server a request for a page, and the server responds with a code saying "That's not here, but you'll find it over there." A POST is a multi-line MIME type, a GET is a single-line MIME type. In order to redirect a POST, the server would need to receive the multi-line MIME and then send it (or something similar) back to the browser.
Another possiblity people have asked about is using separate frames and/or windows to finesse various situations where you want to post to a servlet, take the response and do something with the data. This is certainly feasible. However, it is not simple to implement, and it gets even hairier if you're trying to make it work on more than one flavor of browser. I burned up a lot of brain cells and more seconds of my life than I'd care to remember proving this :-(. The various browsers have extremely different DOMs (document object models), even from browser to browser. Make it work on one, it breaks on another.
It is damn near impossible to make the above approach secure; various browsers have unreliable behavior with respect to caching and respecting pragmas, and will helpfully offer to rePOST the information when you back up to the page. You can mimize its impact by coding checks on the server side, but there's no way to nail down the browser side. I found this extremely frustrating when dealing with IE particularly, especially 4.0. There is, in fact, no way to make IE 4.0 forget the contents of a POST. I did find a way to fake it, through clever use of multiple frames and forcing a reload of the page containing the original form, but it was truly a kludge and not something I recommend.
Oh yeah, another thing about IE, 4.0, is the SSL non-Versign CA POST bug. If you're dealing with SSL servers and you're using a non-Verisign Certificate Authority, IE 3.x doesn't give you any option to accept the certificate, though you can manually install your CA for use in intranets. However, with IE 4.0 the user can click through a couple of dialogs to accept the non-standard CA... whereupon IE 4.0 continues with the POST, having forgotten the actual arguments somewhere in the process!