Ever Wonder Why Commenting Every Piece of Code You Write is Important?

I am trying to figure how some JavaScript I wrote  several years ago for the ScopeRoller website works.  Not enough comments, and I don't remember what tools I used to debug this with.  Some browser with built-in debugger?

Enabling Servlet Reloading

You can tell Tomcat to enable servlet reloading (based on whether the modification date of the class file is newer than the version currently loaded), but the instructions on p. 26 of Hall & Brown's Core Servlets and JavaServer Pages, vol. 1, do not seem to be correct.  Apparently the updated instructions are here.

Can't Control Applet Close Window?

I spent way too many hours trying to find the answer to this question, so in the event that someone else runs into the same problem, a search for WindowListener or JApplet or Applet will probably bring them here.

I am writing a popup applet to replace the Javascript prompt function--but with more caller control over the size of the text that the user can enter.  (It uses the JTextArea component.)  The way it works makes it easy to replace existing calls to prompt--instead, it has methods like this:


/**
* Replaces the Javascript prompt function.  It displays text in a text box, OK and Cancel buttons
* and returns a String if the user hits OK.
* @param msg: the prompt to the user
* @return: String
* @throws InterruptedException
* @throws BadLocationException
*/
 public String editableTextBox(String prompt, String defaultText, int rows, int columns);

/**
* Replaces the Javascript prompt function.  It puts up an empty text box, OK and Cancel buttons,
* and returns a String if the user hits OK.
* @param msg: the prompt to the user
* @return: String
* @throws InterruptedException
* @throws BadLocationException
*/
 public String inputTextBox(String prompt, int rows, int columns);


A little weird, but the way that this works is that it pops up a window containing these components, and then goes into a sleep loop until the user hits the OK or Cancel button.  This worked just fine, but the problem was what to do if a user hits the close window box on the popup, instead of hitting the Cancel button?

I thought that I could turn on the WindowListener interface, and catch the window closing or window close events, and from there, set the flags that simulated the user hitting Cancel--but that did not work.

 So I put the same code in the stop and destroy methods of the applet--but there was no way to force that looping thread to get control and see that we were simulating Cancel.  So I took what might seem like the least beautiful approach.  In the popup window (which is a JFrame):

     setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);

The user can hit the close button all day, and nothing will happen.  He has to hit OK or Cancel.

An Interesting JavaScript Field Validation Problem

I've spent a bit of time trying to figure out how to combine keystroke level and field level validation with autocompletion in JavaScript.  The idea is that for each field in a form, you want to identify invalid inputs as early as possible.  You don't want to wait for the user to hit the Submit button before checking the values that he has entered.  So you really want keystroke checking, field level checking, and checking at submit time.

You check the keystrokes with the onkeyup event: onkeyup="numericOnly(this)".  It calls a JavaScript function that sees if the field contains only digits.  If you just added a non-numeric key, you remove the last character from this, then window.status="numeric only keys allowed in this field" to set the status bar of the browser, letting the user know that this wasn't okay.

You check the overall field for syntactic or semantic errors by using onblur="validateAreaCode(this, nextField)".  This function gets called when you leave the field by hitting tab, or using the mouse, or hitting enter.  Do whatever checking you need to, then use alert() to warn the user that there is something wrong with the input, and set focus back to this.  If everything worked, you set focus to nextField so that field gets control next.

Oh: but there is one other case where the onblur event happens: if you have autocompletion enabled in Internet Explorer.  As soon as you enter the field, autocompletion's menu pops up--and you probably do not want to validate your inputs yet, because you really haven't left the field--you are waiting to make a decision from the autocompletion choices.

The solution?  Add onfocus="saveRecent(this)" for this field.  The saveRecent function saves the name of the field and its value in global vars.  Then, your onblur function (validateAreaCode in the example above) calls a function mostRecentChanged(this), which compares the name of the field and the value saved by saveRecent.  If the name of the field matches, and the value matches, then you have reached onblur because of the autocompletion menu.  Only if the value has changed do you perform your validation check, because that means that you completed the field, or left the field, and that is why you are now calling onblur.

UPDATE: Dreadfully ugly.  Even if autocomplete does not bring up a menu of choices, onblur event is firing.  It turns out that the best solution was to turn off the onblur event, and do everything through onkeyup instead.  The onkeyup event calls the validation function.  Depending whether the passed in field is full length or not, we either display a complaint in the status bar, or use alert to warn the user, and set focus back to this field.  If there is no error, we set focus on the nextField instead (unless the key event causing this was Shift Tab).  However: since a user might mouse over to another field, I am now having the onclick event invoke the onkeyup validation function by saving the current field from the validation function.  The onclick event then picks up the last field, and does obj.fireEvent("onkeyup") to force the validation function to be executed for the last field before we take action in the new field.