Comment On The Long Road to Validation

All I'd have to do is turn off javascript and I can put 4@A5$)(W¤Õß+45n for my birthday!

...and watch it as the server throws an uncaught exception, because the morons thought server-side validation was unncessary, because the client can do it themselves!

All client side is good for is an extra layer of convenience (in terms of saved page hits, etc.) on top of server-side validation, where all the real action is.

where's the wtf? web services make /everything/ better. The author can also tell his boss that his code uses sophisticated SOAP AJAX web two point omg web technology to ensure the validity of dates.

I think we're being too harsh on this guy(girl.) This is an excellent example of reuse of well-tested code.

Alex Papadimoulis:

If you haven't learned firsthand, data validation is a pretty tricky thing to do in Javascript. There is no built in isDate() function, so you pretty much has to rely on your Google searching skills to find some validation code. Or, look in some Javascript book. Or, in the worse case scenario, actually write some yourself. But thankfully, there's a much more elegant solution to this and most other problems: WebServices.

Alex, you misspelled "hellbent".

This way, as the anonymous submitter discovered in a system he was maintaining, you can simply make a call over Ethernet to make a call over IP to make a call over TCP to make a call over HTTP to make a call over XML to make a call to IIS to call the .NET Runtime which calls the VisualBasic runtime to run it's built-in IsDate function.

"...that lived in the house that Jack built."

Think of how much technical knowledge was used to avoid writing a date validation routine.  As well, think of how little sense was being used.  "Penny proud; pound foolish."

Sincerely,

Gene Wirchenko

thats actually quite clever..if it wasnt so dumb

quite true, there is no isDate() function, but...

function isDate(testDate){
  if(testDate.constructor == Date){
    return true;
  } else {
    return false;
  }
}
doesn't seem to hard...

I think we're dealing with a Date represented as a String here - in which case it wouldn't have a Date constructor. Correct me if I'm wrong - I haven't "programmed" in JavaScript in a while.

There is no WTF here... this is how you do "enterprise" validation.

Anonymous:

There is no WTF here... this is how you do "enterprise" validation.

Lets not start the "enterprise" talk again.  This is plain and simple.  Google is god to programmers that don't have a clue where to begin.

What I find the worst about this function is it returns

< result >false< /result >
or
< result >true< /result >

rather than a Javascript boolean value.

What I find second worst is that if the web service is down all dates are invalid by default.

Maurits:

What I find the worst about this function is it returns

< result >false< /result >
or
< result >true< /result >

rather than a Javascript boolean value.

What I find second worst is that if the web service is down all dates are invalid by default.

Also....  what if the web service date is in a different format than the one inputted by the user?

What a bad idea, everyone knows you just create a folder on the server that contains text files, each one named for a valid date for every year going backwards and forwards for 125 years and do a string compair.

Oh, and stopping when it finds a valid match is dangerous, let it check them all "just in case."

PCBiz:

Also....  what if the web service date is in a different format than the one inputted by the user?

That could be construed as a feature.

rob_squared:

What a bad idea, everyone knows you just create a folder on the server that contains text files, each one named for a valid date for every year going backwards and forwards for 125 years and do a string compair.

Oh, and stopping when it finds a valid match is dangerous, let it check them all "just in case."

Of course.  That way when you are doing the time complexity analysis of your "date search,"  you don't have to worry about anything silly like best- or worst-case scenarios.  You just have one "all case" scenario.  That way, it runs in constant time.  :)

How's this?

  [I]function isDate(testDate) { return (new Date(testDate)!='NaN' || 'moose'); }

  alert(isDate("04/01/2006")); // returns true.

  alert(isDate("0X/01/2006")); // returns moose.

 

Anonymous:

quite true, there is no isDate() function, but...

function isDate(testDate){
  if(testDate.constructor == Date){
    return true;
  } else {
    return false;
  }
}
doesn't seem to hard...

ummm, that would be nice if the text field automatically created a Date object for you... otherwise there's still no builtin isDate to validate a string. But who does that anyways? Just make them use a javascript calendar ;)

[cliche]The real WTF here[/cliche] is that he didn't do client-side VB in javascript to do date validation.



And to make sure it's a doubly-validated date, insert it into a table
and see if the DB accepted it as a date (so long as you aren't running
like SQLite that doesn't give a flying hoot about types) as well.

Granted, this code could use a little improvement, but its not really that bad of a WTF.  What if this was in a web app that could be deployed in various places and the standard date format differs?  i.e. - If they deployed it in the U.S. they might want U.S. format dates - mm/dd/yyyy, but if they deployed in Europe they may want dd/mm/yyyy.  This allows the client to be format flexible without lots of extra JS.  Of course, you would still need to do server side validation as well.

Aa

CAPTCHA: paycheck (and it's payday!  w00t!)

This is not a WTF.  It's stupid, but not a WTF.

If the web service is down, most likely the web server that also served the crappy Javascript code is also down.  Now, the error will be hard to trace, but chances are with IIS monitoring you'll know that anyway.

For internationalization, this would be great... but would you indicate what culture the user is from strictly in the Javascript???   Does ASP.NET have a culture detector you can use so you Date.Parse() correctly based on your User-Agent header?

Anonymous:

For internationalization, this would be great... but would you indicate what culture the user is from strictly in the Javascript???

You would not, and culture is irrelevant since individual preference trumps that anyway.  The international standard (ISO 8601?) is YMD format.  The U.S. company that I work for happens to use YMD, and in the client billing system that I wrote and maintain, that format is set with one command: set date ansi, but if we wished to change it, it would be just that one command that would change.  I save the date setting in a system information table, so that it can be changed by the operator if desired.  There is no need to go to horrible lengths that are difficult to debug.

Sincerely,

Gene Wirchenko

What if you're working with different string formats... Different languages.. Different business logic (weekdays, or holydays, and so on).. Many of these cases are quite common on many "enterprise applications" that you guys make fun of.

You probably already have all this developed on your business layer, so why not expose this on the UI to give faster feedback about what's being entered? Would you prefer to code all that again in JS ??

Using WS for simply checking the isDate on the server is a big WTF.. but using webservices for validation on the client is not a completely stupid idea.

Alex Papadimoulis:

This way, as the anonymous submitter discovered in a system he was maintaining, you can simply make a call over Ethernet to make a call over IP to make a call over TCP to make a call over HTTP to make a call over XML to make a call to IIS to call the .NET Runtime which calls the VisualBasic runtime to run it's built-in IsDate function.

Wrong, and so is the punctuation. Once again the article is also a WTF.

Anonymous:

How's this?

  [I]function isDate(testDate) { return (new Date(testDate)!='NaN' || 'moose'); }

  alert(isDate("04/01/2006")); // returns true.

  alert(isDate("0X/01/2006")); // returns moose.

 

Can you get it to return FileNotFound?

rob_squared:

What a bad idea, everyone knows you just create a folder on the server that contains text files, each one named for a valid date for every year going backwards and forwards for 125 years and do a string compair.

Oh, and stopping when it finds a valid match is dangerous, let it check them all "just in case."

No no no no no! You have a folder on the server that contains text files, each one named for every invalid date!  That way you can still use different date formats (mm/dd/yy, mm-dd-yy) without having to create more text files!

Alex Papadimoulis:

.. simply make a call over Ethernet to make a call over IP to make a call over TCP to make a call over HTTP ...

Hmmm, I think we're really stretching things a bit here...

This is pretty much standard operating procedure.  The rest is just RPC.



Now if there was an 'eval( )' call in there somewhere, then we'd have something!

Alex Papadimoulis:

...you can simply make a call over Ethernet...

Actually, they were using a Token-Ring network.

Anonymous:

How's this?

  [I]function isDate(testDate) { return (new Date(testDate)!='NaN' || 'moose'); }

  alert(isDate("04/01/2006")); // returns true.

  alert(isDate("0X/01/2006")); // returns moose.

 

I take it that you've never actually TRIED to return moose in a
production environment. Even with the original store receipt, it's a
cast-iron bitch.

Why would I pray for a tighter bomb pattern anyways?

 I don't know where they are getting the date from in the first place, but if they used drop down menus it wouldn't matter the internationality because you say month, day, year!

April 13, 2006

Then you don't need validation.

Anonymous:

Why would I pray for a tighter bomb pattern anyways?

Ask Yossarian.

Oh, I see the problem now.  A valid date on the server may not be a valid date on the client.

 

John McEnroe:

You cannot be serious man!

John Bigboote:

Anonymous:

How's this?

  [I]function isDate(testDate) { return (new Date(testDate)!='NaN' || 'moose'); }

  alert(isDate("04/01/2006")); // returns true.

  alert(isDate("0X/01/2006")); // returns moose.

I take it that you've never actually TRIED to return moose in a production environment. Even with the original store receipt, it's a cast-iron bitch.

You need the handy isNAMoose() function available to JavaScript 1.7 and later:

// Safe way to cast meese.

function ObjToMoose(mayBeAMoose)

{

   var couldBeAMoose;

   couldBeAMoose = Moose.parse(maybeAMoose);



   if ( isNAMoose(couldBeAMoose) )

   {

      return null;

   }

   return couldBeAMoose;

}

Anonymous:

 I don't know where they are getting the date from in the first place, but if they used drop down menus it wouldn't matter the internationality because you say month, day, year!

April 13, 2006

Then you don't need validation.

What if the culture is not on the Gregorian calendar?  What if the client is Jewish, wouldn't you want that to be localized?  Why even bother with validation at all?  Data validation is silly and outdated!</sarcasm>

Moosey fate!  Say moosey fate!

At least you can replace the code inside there and fix it in one place.  It could have been far worse with the code pasted all over the place.

April 13, 2006

Then you don't need validation.

Oh, come on. Modifying the values of a drop-down is easy. Here's one of the harder ways to do it:

var monthSelector = document.getElementById("month"); //or some other trivial method

var opt = document.createElement("option");

opt.value = "foo-vember";

opt.appendChild(document.createTextNode("Foo-vember"));

monthSelector.appendChild(opt);

monthSelector.selectedIndex = monthSelector.length - 1;

" All I'd have to do is turn off javascript and I can put 4@A5$)(W¤Õß+45n for my birthday!"

Client side validation is for YOUR benifit, not the web-devs. It means we don't have to send 10 transactions back and forth just to figure out that, yes, some people are as stupid as dilbert implies.

For instance, if this @#$(*&(* msg board did client side enabling of the post method, I wouldn't have to re-enter the worthless CAPTCHA everytime I forget to bang on the keyboard to create a name.

lizardfoot:

Anonymous:

Why would I pray for a tighter bomb pattern anyways?

Ask Yossarian.

This is a fun page to read when bored at work...er, I mean when you have a free moment at home.

http://www.generationterrorists.com/quotes/catch-22.shtml

 

bullseye:

John Bigboote:

Anonymous:

How's this?

  [I]function isDate(testDate) { return (new Date(testDate)!='NaN' || 'moose'); }

  alert(isDate("04/01/2006")); // returns true.

  alert(isDate("0X/01/2006")); // returns moose.

I take it that you've never actually TRIED to return moose in a production environment. Even with the original store receipt, it's a cast-iron bitch.

You need the handy isNAMoose() function available to JavaScript 1.7 and later:

// Safe way to cast meese.

function ObjToMoose(mayBeAMoose)

{

   var couldBeAMoose;

   couldBeAMoose = Moose.parse(maybeAMoose);



   if ( isNAMoose(couldBeAMoose) )

   {

      return null;

   }

   return couldBeAMoose;

}

Can you pass multiple moose into this function?  Mabye a linked list of meese that need validation sorted in decreasely antler size?

This WTF has inspired me; I have an idea how to use the network as the computer.

 

You create a www. .com with an http handler that handles all request.

Then you call it with /<CalendarType>/<Culture-Code>/<date parts>.ashx  (eg /julian/en-us/dd.mm.yyyy.ashx ) and the page returns true or a 404 if the date is not found :P. Don't make any mistakes and set the headers to allow caching everywhere forever.

The you can just check your date by checking the that the url is valid.

 

I hereby give this to everyone, free as in beer, not free as in speech.

 

 

 

 

 

The only thing bad I see here was that the validation function isn't more general. Something like:

function validate(formObj) {}

Where the entire form is validated at once on the server-side.

The dilemna is that client-side validation is stupid, because you know the server is going to have to re-validate anyway, so why repeat the code in the client at all? You can't trust client-side validation. But it turns out it is nice to alert the client before a full round-trip on form submission of a potential problem so you don't have to re-draw the entire form with all their values in place and some retarded red "this field sucks" error.

Still, since you know the server has to validate, why not just keep all the validation code on the server and call it from the client for pre-validation? Do you enjoy writing twice the code? Javascript is fun ... but not that fun.

There's no WTF here.  That's a perfectly reasonable hack for code that they probably wanted to throw together in a hurry.  Sure it's inefficient and ought to be replaced eventually, but for a 1.0 it's fine.

Digitalbath:

bullseye:

John Bigboote:

Anonymous:

How's this?

  [I]function isDate(testDate) { return (new Date(testDate)!='NaN' || 'moose'); }

  alert(isDate("04/01/2006")); // returns true.

  alert(isDate("0X/01/2006")); // returns moose.

I take it that you've never actually TRIED to return moose in a production environment. Even with the original store receipt, it's a cast-iron bitch.

You need the handy isNAMoose() function available to JavaScript 1.7 and later:

// Safe way to cast meese.

function ObjToMoose(mayBeAMoose)

{

   var couldBeAMoose;

   couldBeAMoose = Moose.parse(maybeAMoose);



   if ( isNAMoose(couldBeAMoose) )

   {

      return null;

   }

   return couldBeAMoose;

}

Can you pass multiple moose into this function?  Mabye a linked list of meese that need validation sorted in decreasely antler size?

I'm sure that we could do a Vector of moosen.

This is not a WTF. This is really not much different than Google
Suggest - there's not even a database hit, and the function call acts
as sufficient API that if performance ever became a problem, it could
be re-implemented purely client-side without affecting other code.



The closest thing to a WTF is the whole "call to Ethernet to call to
TCP to call to IP blah blah" jazz. Come on, haven't we gotten used to
the idea that there's thing think called the "Internet" and that we can
generally depend on it working?

 

Nowhere does this sample code reference ETHERNET... so it reads like
the article summary in a fark.com article... funny but not particularly
relevant.

Free:

T hereby give this to everyone, free as in beer, not free as in speech.

Cool sig ... I never stopped and thought about the W.T.F. cause that is always how my week ends!!! I should really only work two days a week, that is the only time my work has my interest! [8-|]

Isn't that what you new-fangled types call a "composite application"? [:S]

Anonymous:

There's no WTF here.  That's a perfectly reasonable hack for code that they probably wanted to throw together in a hurry.  Sure it's inefficient and ought to be replaced eventually, but for a 1.0 it's fine.

The idea of releasing such junk as a 1.0 is ridiculous.  What ever happened to doing it right the first time?  Validating a date is not particularly difficult code to write.  BTDT, wore out the T-shirt.

Sincerely,

Gene Wirchenko

You're kidding, right?  Seriously, dude.  That's funny...

I mean, I hope you're kidding.  Right?

Anonymous:

How's this?

  [I]function isDate(testDate) { return (new Date(testDate)!='NaN' || 'moose'); }

  alert(isDate("04/01/2006")); // returns true.

  alert(isDate("0X/01/2006")); // returns moose.

 

Unfortunately, this solution works for IE, but it does not work for browsers that properly implement the ECMAScript specification.