Craig wrote, concerning the use of JavaScript from Struts:
> The challenge with doing this is that the JSP tags run on the server (as
the page is being generated), while the JavaScript runs on the client side.
To integrate the two, you need your tags (and other JSP code) to dynamically
generate the JavaScript functions themselves -- sort of having a program
write a program --so that the JavaScript is customized to your particular
need on this particular page.
>
But wait! That's trivial JavaScript. This is a very large can of worms we
are opening with JavaScript. Lets take this one step further.
Real JavaScript programmers write pop-ups, not just menu widgets.
Making a pop-up involves having the JavaScript code create a child
("secondary") browser window on your screen whose initial content is
concocted by the launching JavaScript program, client-side. And, as Craig
says, that concocting JavaScript program was itself concocted server-side,
although it runs client-side.
So we need to contemplate a program writing a program writing a program.
Have a headache yet. Okay, consider this. There can be more than one such
child browser.
But, its worse still. Of course, you could have the JavaScript write
straight HTML into the subordinate browser(s), but we want to run
subordinate Struts applications, right?. Not just sissy HTML. Note,
however, that you cannot just write Struts markup into a sub-browser
directly from the JavaScript program like it was a JSP. The JavaScript
runs client-side (no JSP here) and the sub-browser would choke on
unprocessed Struts tags. To run a subordinate Struts application, the
JavaScript running in the parent browser has to write another JavaScript
program into the child browser. (Four levels now.) This will redirect the
child browser to a child Struts application JSP, which brings in its own
Javascripted page. Whew!)
When I first considered this possibility, I was sure it would break Struts.
Now I'm not so sure, since each of the browsers has its own request/response
context. (Unless there is session sharing .....)
On pages 106-108 of Danny Goodman's book "Dynamic HTML: The Definitive
Guide" (O'Reilly), you will find HTML code for making a pop-up with
JavaScript. Its pretty trivial itself, and trivial to convert this to a
Struts JSP.
Has anyone tried this???? Well, its only the first step because we want
only Struts applications in the subordinate browsers, right?
So, now, add the following new JavaScript code to the HTML that's written by
the parent browser's JavaScript into the sub-browser document:
<script LANGUAGE="JavaScript">
function redirect()
{
window.location = "http://StrutsHost/someStrutsApp/index.jsp"
}
setTimeout("redirect();", 500) // you might have to play with the
number
</script>
Now you must have a headache.
No? Well consider this: Each parent-child pair has access to the other's
document context, client-side of course, but not server-side . Okay,
confusing as this is, I still don't think any of this would break Struts.
But I'm just dying to try it.
