Today's Episode:
Pop Goes the Modal
The ad-hoc SQL query application which was the subject of my most recent expedition into the world of Strange Code had one more surprise left for me just as I was about to declare victory and go home. If you remember from the example page I had prepared last time, there was a sizable <TEXTAREA> set aside for the where-clause of your query. In the previous version's GUI, a button was provided next to this field that popped up a clause editor, which the SQL-challenged could then use to point-and-click their way into assembling a where-clause. Since making some minimal level of competence with SQL a prerequisite to use the new version was out of the question, guess what I had to do.
The obvious solution for popping up another window from a page isn't quite JavaScript 101, but it's pretty close. I use it all over the place over in the Road Geekery section of this website, and it goes something like this:
<SCRIPT>
function showEditor() {
var url = "where_clause_editor.html";
var editor = window.open(url,"editor","width=500,height=160");
}
</SCRIPT>
What I didn't point out about the Obvious Solution© are its ramifications for your web server. Each time the luser clicks the "Show Editor" button, s/he requests the file where_clause_editor.html from the server. The server, in addition to all its other tasks at that moment (such as parsing form inputs, firing SQL calls off to the backend database, and formatting the database output), has to find the time to map their request to the appropriate file and send it back to their browser. While not wrong, it's still a lot of effort for a file less than 1K in size.
Making the Browser Work For You
There is a sneaky way of not having to ask for the where-clause editor from the server -- you include it with the original page that will request it. Consider the following:
<div id="vi">
<!-- script block to be loaded into clause editor window -->
<script>
// -- these scripts don't contribute to this demo.
// -- they have been deleted for brevity's sake
</script>
<!-- display title for clause editor -->
<h3 style="border: outset 3px; background: black; color: white; text-align: center">
Select a relational operator and criteria value
</h3>
<!-- form to catch luser inputs -->
<form name="editor" id="editor">
<table>
<tr>
<td><input name="field" id="field" type="text"></td>
<td>Popup menu of operators goes here</td>
<td><input name="val" type="text"></td>
<td>
<input name="caps" type="checkbox"> All CAPS<br>
<input name="num" type="checkbox"> Is a Number
</td>
</tr>
<tr>
<th align="right" colspan=2>Select a logical operator:</th>
<td colspan=2>Radio buttons with connecting logicals go here</td>
</tr>
<tr>
<td align="center" colspan=2>
<button style="width: 100" onclick="addClause()">OK</button>
</td>
<td align="center" colspan=2>
<button style="width: 100" onclick="window.close()">Cancel</button>
</td>
</tr>
</table>
</form>
</div> <!-- end storage block for clause editor -->
This <DIV> block will supply the content for our popup window. To keep it from showing up before we need it, do the following in the <STYLE> block of the page header:
#vi { visibility: hidden; }
Our window popup function from earlier this episode now becomes:
<SCRIPT>
function showEditor() {
var editor = window.open("","editor","width=500,height=160");
editor.document.write(vi.innerHTML);
}
</SCRIPT>
Instead of specifying a source URL for the window, we leave that parameter blank and let the browser open an initially empty window. The next line writes the contents of the <DIV id="vi"> block into this empty window. Voila! Instant popup clause editor! Your web server and luserbase will thank you for the resulting increases in performance.
To see this technique in action in a more-or-less real application, go here. As always, I encourage you to use the View Source command of your browser liberally to appreciate the Strangeness.
BUGS FEATURES
The contents of the <DIV id="vi"> block would not get written to the popup when running in a Galeon browser (version 0.13 for Linux). However, it worked perfectly in Mozilla 0.9.3+ and Galeon 1.0+. I'm wondering if I hit an obscure bug in the JavaScript implementation for that version of Galeon.
It doesn't work in IE 5.0 for the Macintosh. As near as I can figure, it's because the rendering engine IE/Mac uses can't (or won't) properly render the <BUTTON> tag. Funny how every UNIX and Windows browser I tried never had this problem...
The title of this episode is lame even by my standards. I used it because of all the alternatives I ran past my family and co-workers, it induced the most pain.