gregs

I have been updating a bunch of code recently to make use of the new features in Prototype 1.6 and one of the great additions in this release was the introduction of Automatic JavaScript response evaluation. This allowed me to improve on my session checking code without having to fuff around with the response information sent back to the client. The problem was with XHR requests: i.e. if the user initiated such a request when his session had expired, then usually the response would fail or worse just hang.

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.

Or more appropriately what is it? Fascinating...

A while back I posted about using the data:image/jpeg;base64 to directly embed the image in to the source attribute of an image tag, however this did not work with IE. Today I stumbled across this JavasScript solution. Certainly an option, though in my case it was overkill, however I thought others might find it useful.

I just spent the best part of 45 minutes trying to figure out a weird issue with a value I was pulling out of a select box (using $F(element)). The value in question was a long number: 1000002229651626, which IE converted at the time of writing the value to the page (this was an AJAX call) to: 1.00000222965163e+15.

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:

I just stumbled across this post from the Red Balloon guys, which reminded me that I wanted to blog about this great little resource about the subtle differences of URL encoding and JavaScript.

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.

Now I can't remember where I stumbled across this little gem of a plug in for FireFox: FireBug, but yesterday it completely surprised me.

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

A few weeks back someone on the CFDJ list enquired about JavaScript form validation and pointed them in the direction of my script, however I only just realised that the script itself was no longer working. Oops... so apologies, but I have fixed up the problems and done made it sure it works for the following browsers.

• 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.

I found myself having to trap a user attempting to refresh a page for one of our web apps. After a little bit of digging I stumbled across this solution:

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.

What with the buzz going on around xmlHttpRequest, I decided to have a little play with the technology (yes I know very me too of me). One tutorial/example site I stumbled across "Guide to Using XMLHttpRequest (with Baby Steps)" used some interesting JavaScript: Conditional Compilation. Here is an example:

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?

I made my first venture in regular expressions, when I had to create a JavaScript that checked the validity of an e-mail address. By checking it's validity, I mean that I wanted to make sure that users submitted an address that followed your_name@domain.com and not simply entered a whole bunch of garbage. The best way to do this is to match a pattern or as it is known use regular expressions. Before we set off here is the script that we are going to work through:

<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!!!