The snippet below shows my new session checking code.

The trick is to intercept the call when you do your session checking at the back end. Let's say you have a fuseaction called login.login (see below and yes this is fusebox 3 :S) where you display the login form when a user is not logged in, this is where I inserted the check for an XHR request, by looking at the http headers sent along with the request. The key here is a new header attribute passed in with Prototype "X-Requested-With". If this attribute exists then I know it's an XHR request and I can create a custom JSON header with an error struct that holds a key called session with a value of timeout. All I then need to do is encode the struct as JSON and pass that encoded struct back to the browser.

Now let's jump back to the JavaScript code and take a look at the onComplete function again:

If there's a JSON object and it has a key of session then I call my setSessionExpired function which redirects the users. Now the json session key only exists in these situations since the call normally just passes back the result of the call.

IE decided to convert my number when I was using the new Option() method to populate the drop down, making the debug process even harder. I personally can't wait until we get a firebug like extension for IE, right now I'd just settle for an option to view the rendered source.

Rant over, the solution is to convert the number to a string:

On the plus side I came across a neat way to debug values in a form field using the address the browser address bar:

And to see what IE had actually written to the page:

The bottom line of this article is that 9 times out of 10 you'll want to be using encodeURIComponent() to encode vars that are to be passed as part of a URL instead of the escape() method.

I originally had installed it because it was meant to be far better at debugging JS, than the new version of the JavaScript Console that was shipped with FireFox 1.5 and that it was. So I have been using it for a while now, but yesterday I stumbled across a feature that makes it utterly invaluable now. I do a lot of Ajax based development these days and sometimes trying to figure out what is going on under the hood is a little problematic. However if you open it up and look at the options, you'll see an option to show XmlHttpRequests disabled. Enable it and make a remoting call.

Along with the usual JS/CSS debug you should now see something like this:

If you click on the Response Tab you can see what has been returned to the browser.

And if you click on the JS tab you can inspect the whole response object.

Awesome!

And since it's been so long between posts here a couple of other useful Ajax/prototype links:

• It's all over the Internet but getting started can be tricky: Painless JavaScript Using Prototype
• More prototype documentation
• Behaviour the perfect way to write unobtrusive JavaScript

• Win XP / Netscape 4.7x
• Win XP / IE 6
• Win XP / Mozilla 1.4
• Win 2K / IE 6
• Win 2K / Mozilla 1.5
• Win XP / Firefox 0.8

If you have access to ones not on the list, I'd be grateful for any feedback. The revised version with sample file can be found here.

To use it simply embed or include it into your template

Eventhough the article says this is a IE specific event/feature it also works in FireFox. You should be aware that whenever the user leaves the page, they will be prompted about their impeding data loss, which can get a little tedious while developing.

Again this became a handy feature for our AJAX apps as most of the processing is done in the background without the page reload, a user could accidentally hit the back button and loose where they were at.

From the looks of it, it's an IE only thing, but I wonder what the advantages are of using this code over a regular browser check? Is this a more reliable way than using window.ActiveXObject and, if you are specifically playing around with xmlHttpRequest, based on that condition making the correct create object call?

<script language="JavaScript" type="text/javascript">
<!--
function validate() {
   var pat_email = /^[-._&0-9a-zA-Z]+[@][-._&0-9a-zA-Z]+[.][._0-9a-zA-Z]+[a-zA-Z]$/;
   with (document.form1) {
      //validate email
      if ( pat_email.exec(txt_email.value) == null ) {
         alert("You have not entered a valid email address.");
         txt_email.focus();
         return false;
      }
   }
}
//-->
</script>

OK let's see what is going on here. First we define the pattern that we are trying to match. There we specify the characters that are accepted and the characters that need to appear in it to determine it's validity. JavaScript knows you are defining a regular expression when you use the statement var <pattern_name> = /<pattern_goes_here>$/;. If you take a look at the pattern you will notice [] (I will get to the caret in a second). These are used to group patterns together and in some cases create sub-patterns. Taking a step back you can see that we are trying to match pattern that follows these guidelines []@[].[], which is how most e-mail addresses are composed. In between the square brackets I have specified the characters that are permitted for each sub-pattern. So looking at the first set of square brackets, only values between 0-9, a-z, A-Z, "-", "_", "&" and "." are accepted. How does the script know that these are to be accepted? This is where we get back to the caret (^). This symbol inside the forward slashes indicates that it should accept only those characters specified. Move the caret outside of the slashes and you get achieve the opposite, accept any characters other than the one listed above. You may also wonder what the +[a-zA-Z] is about. We included this in order to accept domains names such as .co.uk or .com.au, hence the reason for only including letters and not numbers.

As an aside should you wish to learn more about regular expressions or pattern matching I can recommend two books. The first is what I used and it gave me an introduction to regular expressions and is the JavaScript developers bible: JavaScript from O'Reilly & Associates, Inc. The other is Perl Programming also from O'Reilly & Associates, Inc. You may be wondering why recommend a Perl book for JavaScript regular expressions. As it happens Perl forms the basis for the way in which JavaScript handles regular expressions.

Right on with the script. Once we have defined our pattern we have to match it up with something. This happens in the following line, where we inform the script to match it to form1 in our current page. Next we set the condition, where if pat_email is matched up against text_email (this is the form field we are validating) and if this returns null, then we have no match and hence the user has entered an e-mail address that does not satisfy our criteria. If this is the case an alert should be made, the focus set back to aforementioned form field and the form submission aborted.

And there you go that's the script. You invoke the script by including onsubmit="return validate();" in your <FORM> tag. As ever I hope this proved to be useful and informative. Comments and feedback always welcome!!!