Yes, that is how it will probably work in the final product but I'm in a evaluation phase now. Key to this evaluation is getting applets and struts to work together and the login applet is an easy one to test with. We have other applets that are far more complex and far more critical to the application. These applets *must* be able to seemlessly return control to the browser. For example, there are database index and query screens (often complex) created and viewed on fat clients that we can also render in Swing applets. There's no problem opening these applets but if they can't return control to the browser we're left to render the hitlist in an applet which is an non-starter. We also have a TIFF image viewer applet that must interact with the server or image and annotation data.
This stuff works without Struts and HTTPClient. I would, however, like to rework it for Struts because I think Struts will be more flexible as the application grows. On Saturday 20 December 2003 23:30, Michael Becke wrote: > ... > Even if you can get things working using this system I would suggest > something different. In particular I suggest handling the > authentication within the browser and then passing the cookie to the > applet. You can pass the cookie to the applets via a parameter in the > applet HTML. The JSPs have access to the session ID of the request and > can write it into the applet page. > ... -- Thad Humphries "...no religious test shall ever be required Web Development Manager as a qualification to any office or public Phone: 540/675-3015, x225 trust under the United States." -Article VI --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
