Tuesday, May 06, 2008

Keystroke and Field Validation with JavaScript

Yesterday, I provided a simple tool to demonstrate the differences between keydown and keypress events. Today, I'm going to apply that knowledge toward making a lightweight form validation library. This library will prevent invalid characters from being entered in form input elements which is useful toward preventing malicious data from being entered (think XSS), as well as ensuring data integrity (data is in the valid format, all required fields present, etc.).

Sample Form:



Alpha
Alphanumeric*
Date
Decimal
Digit
Email
Hostname
IP address
Integer
Punctuation
Real number
Time
Whitespace
custom
type
format


* denotes required field.




The form above should only allow valid characters in each input field - this is your keystroke validation. Furthermore, for fields that require a specific format, when you leave a field with invalid formatted data it should provide an immediate visual indication of the error by setting a fieldWithErrors CSS class on invalid fields. Additionally, a fv:onInvalid event is fired on the invalid element to allow custom events handlers to provide additional actions. For example, enter a number in the date field and tab out. The field will be outlined in red from the fieldWithErrors CSS class and the message, "Date must be yyyy-mm-dd" will be shown by the handling of the fv:onInvalid event. Note: the CSS class will be removed automatically when the field is corrected, and a corresponding fv:onValid event will be fired to allow the custom code to clean up after itself.

Validation rules are defined as Regular Expressions. If you are not familiar with Regular Expressions here is a good reference. Additionally, many predefined regex rules for various validations can be found at the regex library.

Several common data types and formats are defined by default in the library, but it also provide the mechanism to add you own data types. In the custom entry, the type entry allows you to specify an on-the-fly keystroke validation regular expression, and the format entry allows you to specify an on-the-fly field format validation regular expression.

The Validate Form button demonstrates the action you would want to perform before a form submission. It invokes a validateAllFields function which just runs all the field validations (and invokes corresponding CSS rules and issues events). It also returns an array of the invalid field names in case you want to build a list of errors (like the Rails flash messages).


Usage Instructions

Sample Usage:

<script src="javascript/formValidation.js"></script>
<script>
var vf = new FormValidation();
vf.addValidationForField("date", "date", "date");
</script>

addValidationForField requires 3 parameters:

  1. The identifer of the field to add validation for

  2. The name of the data type to use for keystroke validation

  3. The name of the data format to use for field validation

In this sample all the names are the same, but they usually wouldn't be.

Just doing the above will prevent invalid characters from being entered in the data field and can indicate when the field is invalid.

When a field is changed, the format validation is run and will do two things.

  1. It will mark invalid fields are the fieldWithErrors CSS class. This can be used to appropriately highlight the error to the user. For example, the following CSS rule will outline the field in red:

    .fieldWithErrors {
    border: 3px solid red;
    }

  2. An event will also be issued in the field to indicate whether or not the field is valid. The events to watch for are fv:onInvalid and fv:onValid. These events can be used to hide/show error messages such the following which will display a pre-defined error message:

    $$('input').each(function(inputElem) {
    inputElem.observe("fv:onInvalid", function() {
    $(this.identify() + "-error").show();}.bind(inputElem));
    inputElem.observe("fv:onValid", function() {
    $(this.identify() + "-error").hide();}.bind(inputElem));
    });

    Or any number of other actions. For example, you may wish to display a popup error message such as those provided by Prototype Window or add messages to an error flash area as commonly done in Rails apps or toggle the submit button as enabled/disabled. Using these events allows you to add whatever actions you desire when the
    validation fails (or passes).



Download
formValidation.js

Monday, May 05, 2008

keydown vs. keypress (in JavaScript)

In my next post, I intend to discuss a validation library which performs keystroke and field level validation for HTML forms using JavaScript and regular expressions. However, before you can correctly understand how the validation works, as well as when you can test for various validation conditions, you have to recognize the different behaviors between the keydown and keypress events.

In the following text fields, type whatever you like and notice the different behaviors in the table below it.




EventcharCodekeyCodeDisplayShifted?
Keydown
Keypress


Some notable problem keys when dealing with JavaScript keystroke validation are the arrow keys and other editing keys (delete, home, end, insert) which should be allowed in order to edit a field value, however they can appear to be punctuation symbols which may not be desired in the field. Function keys and number pad keys are also problematic.



Here are some key observations regarding keypress events:

  • Firefox sends regular keys as charCodes and special keys as keyCodes

  • Safari sends both charCode and keyCode for regular keys but does not issue keypress events for special keys

  • Internet Explorer does not send charCodes, only keyCodes, and does not issue keypress events for special keys

  • Opera does not send charCodes, only keyCodes, but also issues keypress events for special keys making it impossible to distinguish between some keys such as '-' vs. Insert and '.' vs. Delete

  • Konqueror will send both charCode and keyCode for regular keys, but only keyCode for special keys


Friday, May 02, 2008

Bluetooth Proximity Monitor (improved)

About a month ago, a friend of mine pointed out a bluetooth proximity program for windows which would lock your desktop when you walked away by polling your mobile phone's proximity to your computer. I thought that sounded fun to try as I have a bluetooth enabled phone and laptop, however, I'm running Linux, not Windows. After a quick search on Google I found a Bluetooth Proximity Monitor script for Linux. It worked pretty well as it was, but I've made a few adjustments to it to improve it for my purposes.


  1. The original script is written for KDE or other window managers that use xscreensaver. Since I'm currently running in Gnome, I had to switch the commands to use gnome-screensaver instead.

  2. While changing the screensaver commands, I also added the ability to toggle my instant messenger (Pidgin) from 'available' to 'away'

  3. The original script has a single THRESHOLD value to toggle between being near and far. I decided I needed separate NEAR and FAR thresholds. This is due to the wide variance of proximity I can have while I'm sitting at my desk. Just turning in my chair so that my body was between the phone and the laptop could change my RSSI (proximity value) from -1 to -18, so I need a fairly high threshold to prevent that. On the other hand, setting the threshold high could allow my system to unlock when I'm still 30 feet away. So making separate thresholds allows the proximity monitor not to trigger just because I turned in my chair, but also not unlock until I've actually returned to my desk.

  4. With the higher away threshold, it's possible (though uncommon) to totally leave the bluetooth range before it triggers that you've gone away. So, I also added a little logic to trigger the change in proximity if you were previously in near proximity, but now your bluetooth can no longer be pinged (out of range, turned off, etc).

  5. Finally, I alter the proximity check interval depending on if you're near or far. The motivation for this was an attempt to reduce power demands a little in order to prolong the battery life. I haven't done any actual tests to determine if it helped or not. Basically, if you're at your desk, it only checks every 5 seconds to make sure you're still there. If you've walked away it switches to check every 2 seconds in order to be more responsive to when you return.



In the end, my version of the bluetooth proximity monitor script looks like:

#!/bin/sh

DEVICE="00:1A:8A:61:6C:FE"
CHECK_INTERVAL=5
NEAR_THRESHOLD=-1
FAR_THRESHOLD=-22
PID=0
START_CMD='/usr/bin/gnome-screensaver'
FAR_CMD='/usr/bin/gnome-screensaver-command -l && purple-remote setstatus?status=away '
NEAR_CMD='/usr/bin/gnome-screensaver-command -d && purple-remote setstatus?status=available'
HCITOOL="/usr/bin/hcitool"
DEBUG="/var/log/btproximity.log"

connected=0

function msg {
echo "$1" >> $DEBUG
}

function msgn {
echo -n "$1" >> $DEBUG
}

function check_connection {
connected=0;
found=0
for s in `$HCITOOL con`; do
if [[ "$s" == "$DEVICE" ]]; then
found=1;
fi
done
if [[ $found == 1 ]]; then
connected=1;
else
# msgn 'Attempting connection...'
if [ -z "`$HCITOOL cc $DEVICE 2>&1`" ]; then
# msg 'Connected.'
connected=1;
else
msg "ERROR: Could not connect to device $DEVICE."
fi
fi
}

function check_xscreensaver {
PID=`ps -C gnome-screensaver --no-heading | awk '{ print $1 }'`
if [ "$PID" == "" ]; then
$START_CMD &
fi
}

check_connection

while [[ $connected -eq 0 ]]; do
check_connection
sleep 1
done

name=`$HCITOOL name $DEVICE`
msg "Monitoring proximity of \"$name\" [$DEVICE]";

state="near"
while /bin/true; do

check_xscreensaver
check_connection

if [[ $connected -eq 1 ]]; then
rssi=`$HCITOOL rssi $DEVICE | sed -e 's/RSSI return value: //g'`

if (( $rssi <= $FAR_THRESHOLD )); then
if [[ "$state" == "near" ]]; then
msg "*** Device \"$name\" [$DEVICE] has left proximity (signal: $rssi)"
state="far"
$FAR_CMD > /dev/null 2>&1
CHECK_INTERVAL=2
fi
elif (( $rssi >= $NEAR_THRESHOLD )); then
if [[ "$state" == "far" ]]; then
msg "*** Device \"$name\" [$DEVICE] is within proximity (signal: $rssi)"
state="near"
$NEAR_CMD > /dev/null 2>&1
$START_CMD &
CHECK_INTERVAL=5
fi
fi
# msgn "RSSI = $rssi, "
elif [[ "$state" == "near" ]]; then
msg "*** Device \"$name\" [$DEVICE] is no longer detectable"
state="far"
$FAR_CMD > /dev/null 2>&1
CHECK_INTERVAL=2
fi
# msg "state = $state, PID = $PID, sleep = $CHECK_INTERVAL"

sleep $CHECK_INTERVAL
done

Wednesday, April 30, 2008

Using JavaScript in blogs without <script> support

At one point, Blogger (which is used for this blog) did not allow the <script> tag in blog entries so some people came up with interesting work-a-rounds. This post will showcase two techniques which work well together to provide JavaScript capabilities to your blogs. The first technique supports inline JavaScript with a make-shift <script> tag, while the second technique supports loading external JavaScript files specific to each blog entry which can still be useful even with <script> support.

These techniques work well together and almost need to be used together. The inline technique is only handy for adding a line or two of code because Blogger will try to be smart regarding the formatting of your blog entry and add <br/> tags between all your lines of code making the JavaScript interpreter choke. Additionally, Blogger also tries to format any < or > symbols as &lt; and &gt; which don't work too well in your code. The second technique allows you to load as much JavaScript code as you want, however you'll probably want to use the first technique to invoke the included JavaScript functions.

Testing inline JavaScript: failed. (wait for page to complete loading)

Technique 1 - Allowing Inline JavaScript

That previous test line tested my ability to add inline JavaScript to my blog following these instructions from ecmanaut.

To use JavaScript in this blog without any <br/> tags, I added the following code to my blogger template:

<script type='text/javascript'>
Event.observe(window, 'load', function() {
var c = document.getElementsByTagName('code'), s, i;
var junk = /^\s*\46lt;\133\133CDATA\133|]]\46gt;\s*$/g;
for( i=0; i &lt; c.length; i++ ) {
s = c[i].getAttribute('style') || '';
if( s.match( /display[\s:]+none/i ) ) {
eval( c[i].innerHTML.replace( junk, '' ) );
}
}
});
</script>

I made a couple of slight variations to the original code snippet on the instruction page. First of all, before I added that code, I also included prototype.js in my template to have access to it's handy extensions. I was then able to utilize protype's Event.observe function to execute this code when the page is loaded without messing up and other onload actions. Executing this code during the onload is recommended in the instructions, but not explained how to do it. Finally, since the template requires valid XML, the i < c.length line isn't valid until you change the < to &lt;

Then, in order to run this JavaScript test, I added this line to the bottom of this blog entry:

<code style="display:none"> <[[CDATA[ $('jsTestResult').innerHTML = 'passed'; ]]></code>

which changes the word failed to passed in my test line above.
<[[CDATA[ $('jsTestResult').innerHTML = 'passed'; ]]>

Technique 2 - Loading External JavaScript Files

In order to load JavaScript files, you could edit your Blogger template to include all the files you want as I did for prototype.js and script.aculo.us. However, then every view of your blog will load ALL your JavaScript files. That's fine if you have some JavaScript library that you want to be able to utilize in many/all your blog entries, but if you're adding entries like mine which are just showcasing various JavaScript techniques in separate blog entries, you only want to load the specific blog entry JavaScript if it's being viewed. Enter Dynamically Loading External JavaScript Files.

Right after the previously mentioned code, I added the dhtmlLoadScript function. However, since I have prototype.js loaded, I modified it a little bit. Here's my version:

function dhtmlLoadScript(url) {
var e = new Element("script", {src: url, type: "text/javascript"});
document.getElementsByTagName("head")[0].appendChild(e);
}

So, in any blog entry which I want to use an external JavaScript file I simply add the line:

<code style="display:none"> <[[CDATA[ dhtmlLoadScript('http://some.domain.com/jsfile.js'); ]]></code>

and I can use any of the included function. Furthermore, since the inline script won't be evaluated until the onLoad event it triggered, I don't have to worry about registering it for an onLoad event itself.

Friday, February 22, 2008

busyProcess: a visual indicator for long JavaScript tasks

Some time ago I wrote an article to demonstrate a simple method of displaying a processing/loading indicator for Ajax requests using prototype. That works great for Ajax requests, but let's assume you have some CPU intensive task that will be processed on the client side in JavaScript. This task will take several seconds to complete and you want to add some sort of visual indicator to the page while it's working so the user knows something is happening. enter the busyProcess function.

You could code your particular JavaScript task to display a processing indicator itself and remove it when it's done, however there are two problems you'll encounter. First, you'll probably never see the processing indicator since your task will immediately do its thing and not give control back to the browser in order to display the indicator before the task finishes and your code removed the indicator. Second, you'll end up adding the same code over and over around each function that may take a while to complete (DRY - Do not Repeat Yourself!).

busyProcess handles both of these situations. It is a flexible wrapper for any function passed in to it so that it can be used for any task, and it defers the execution of the function in order to allow the browser to render the visual indicator.

Example

Click this to be busy for 3 seconds.

Get to the code already!


/**
* busyProcess
*
* Add a busy indicator over an element while running the function it invokes
* @param {Object} element clicked on to invoke the task
* @param {Function} function to invoke after adding visual indicator
*/
function busyProcess(element, func) {
var busyIndicator = new Element("div", {id: "busy"});
busyIndicator.setStyle({zIndex: "100",
position: "absolute",
fontWeight:"bold",
height: "16px"});
Position.clone($(element), busyIndicator, {setWidth: false, setHeight: false});
busyIndicator.innerHTML = ' Processing...';
document.body.appendChild(busyIndicator);

// function needs to be deferred in order for the browser to render the
// busy indicator, but we need to wrap it in order to remove the busy indicator
// when it's done
func = func.wrap(
function(proceed) {
proceed();
busyIndicator.remove();
});
func.defer();
}



Ok, so how does it work?

The function takes in two arguments. The first is the element clicked on. This is used as the location of the popup processing indicator as the item clicked on is what invoked the action for the user. Since the prototype $() function is used, this can be an element id as well. The second argument is the function to invoke.

busyProcess starts by building the processing indicator. This can be customized to your preferences. Just be sure the indicator has a z-index greater than anything other layers on the screen, and that is has absolute positioning. I then utilize the prototype Position.clone to position the indicator over the element clicked on.

Now we get to the more interesting part. The indicator needs to go away when the task is done. But how do we know when it's done? You could make the task issue a custom event and register an event listener here to catch it in order to remove the processing indicator. However, then any function you use busyProcess with will need to issue that event when it's done. That could get messy, and easy to forget. So, instead we wrap the original function to have it remove the processing indicator when it's done.

So, how do you use this?

For a simple example, let's assume we want to sort some large table by different columns when the user clicks on little triangle icons indicating ascending or descending.
For simplicity I'm just going to add the code inline on an onclick attribute in the HTML. As a general practice I usually try to register event handlers in my JavaScript code so that the HTML has no JavaScript in it.


<td id="zipcode">Zip Code
<img src="images/sort-asc.gif" alt="ascending sort icon"
onclick="busyProcess(this, function() {sortTableBy(this.up('td').identify());}.bind(this));" />
</td>


I intentionally made that a little more complicated than it had to be just to demonstrate that you can use inline anonymous functions as well.

Optional (but useful) addition

In order to give a more obvious indication that work is being done and to prevent the user from clicking on anything else until it's done you may want to either darken or lighten the rest of the page. To do this, add another layer at the beginning of the busyProcess function like:

var lightenScreen = new Element("div", {id: "lightenScreen",
'class': "lightenBackground"});
document.body.appendChild(lightenScreen);

where the lightenBackground class is defined in CSS as:

.lightenBackground {
background-color: white;
opacity: 0.5; /* Safari, Opera */
-moz-opacity: 0.50; /* FireFox */
filter: alpha(opacity = 50); /* IE */
z-index: 20;
height: 100%;
width: 100%;
background-repeat: repeat;
position: fixed;
top: 0px;
left: 0px;
cursor: wait;
}

or the corresponding darkening version:

.darkenBackground {
background-color: black;
opacity: 0.2; /* Safari, Opera */
-moz-opacity: 0.20; /* FireFox */
filter: alpha(opacity = 20); /* IE */
z-index: 20;
height: 100%;
width: 100%;
background-repeat: repeat;
position: fixed;
top: 0px;
left: 0px;
cursor: wait;
}

Just be sure to remove this layer as part of the wrap by adding the line: lightenScreen.remove();