cftopper.com

Using the with keyword is considered bad javascript programming style
because the javascript engine has to do a lot of work to interpret what you mean.

So don't use


Instead use:

...without resorting to an annoying CAPTCHA.

Those bloody form spam bots were driving our clients crazy with hundred of bs emails arriving every day. I came up with this simple but effective method to beat these form spam-bots.

Part 1 - Duping New Bots

Warning: This method assumes needs JavaScript enabled and is thus not blah-blah compliant.

1. Change the action of your form to "about:blank". (Remember the real action for later.) Robots indexing this will now go to "about:blank" instead of your action handler page.
   
2. If your form has a JavaScript validation function, add this line just before the form is OKed or submitted:
   
   document.[form name].action = "[path to form handler page]"
   
   Otherwise just stick in something like this in the form:
   
   onsubmit="this.action='[Path to handler page here]'"

It's pretty simple, but since implementing this at the crew, we haven't encountered any robots smart enough to figure out that we are duping them with the about:blank. If the robots evolve, then so will we.

Part 2 - Blocking Old Bots (they're using Form Caching!)

Part 1 will prevent robots indexing your form action URL; but what about the robots who have already indexed your form and are storing the form details in their database? Here's how to block them:

1. Add this line to your form:
   
   
   <input type="hidden" name="formSecurity" value="<cfoutput>#Hash( DateFormat( now(), "dd/mm/yyyy" ) & "YOUR_SECRET_KEY" )#</cfoutput>"/>
   
   
2. In your handler page insert the following at the start:
   
   
   <!--- FORM SECURITY --->
   <cfif NOT isdefined( "FORM.formSecurity" ) OR ( FORM.formSecurity IS NOT Hash( DateFormat( now(), "dd/mm/yyyy" ) & "YOUR_SECRET_KEY" ) )>
       <cfabort>
   </cfif>

Tada! Your done. Welcome to zero-spam.
Alternative method: Cut the internet cable running out of Nigeria.

I am considering dropping AjaxRequest (which is excellent) and switching over to prototype.js for the comments part of this site (I will be loading both the comments and comment posts via Ajax).

Shit. I search and searched and can't see if prototype.js supports easy submitting of form data via Ajax like AjaxRequest does. You see I'm a lazy developer and like my frameworks to do this sort of form serialisation grudge-work for me. Hmmm... to use AjaxRequest which has easy form submission via Ajax or to oppose and suffer the slings and arrows of prototype.js making me do it for myself. I could use both but AjaxRequest is 9K and prototype.js is 46K and I'd rather stick with one. Decisions, decisions.

Update

Ok ok, I thoroughly examined prototype.js Ajax abilities and actually posting form data is absolutely simple. And so the winner is... prototype.js.

This Prototype javascript library that everybody is talking about looks to be fantastic but where the hell is the documentation? I mean apart from the Sitepoint article and a few others theres no official documentation (or even a promise of documentation en-route)!

I've just done a big of digging and have just found that Sergio Pereira has just written "Developer Notes for Prototype.js" which is an excellent introduction to the prototype library. In his notes, I found a good overview of the main reason I am thinking about using prototype.js at the moment - it's easy-to-use but powerful Ajax framework.

I have to say I am very impressed with the Ajax.Updater class which will just shunt a bit of HTML returned from the server into place on your existing page with almost no developer effect:

var myAjax = new Ajax.Updater(
'placeholder',
url,
{
method: 'get',
parameters: pars

});

I like it!!