PDA

View Full Version : a date script


GT3_fiend
07-18-2002, 03:24 PM
ok this should be simple enuff( but me me it doesnt seem to be b/c i dont usually deal w/.js beyond rollovers) i need to rig a script that will return an alert box if some one enters the current month and year or anytime previous to that;

what i have to work with is this

RightNow=new Date();
var themonth;
var month=RightNow.getMonth()+1;


var date=RightNow.getDate();
var year=RightNow.getYear();
var day=RightNow.getDay();
if (year==100){year= 2000;}
if (year==101){year= 2001;}
if (year==102){year= 2002;}
if (year==103){year= 2003;}
if (year==104){year= 2004;}
if (year==105){year= 2005;}

function checkFields()
{
form = document.forms[0]
for (i=0;i<form.length;i++)
{
thisfield = form.elements[i]
if (thisfield.name.indexOf('ponumber') != -1)
{
if(thisfield.value == "")
{
alert("you must enter a PO number for this order")
thisfield.focus()
return false
}
}
if (thisfield.name.indexOf('shipacct') != -1)
{
if(thisfield.value=="manualaccount")
{
if(form.elements[i+1].value == "")
{
alert("you must enter an account number for this order")
form.elements[i+1].focus()
return false
}
}
}
if (thisfield.name.indexOf('cmbTerms') != -1)
{
if(thisfield.value=="")
{
alert("you must choose your payment terms")
return false
}

if(thisfield.value.match(/visa/i) != null || thisfield.value.match(/cc/i) != null || thisfield.value.match(/credit/i) != null || thisfield.value.match(/mastercard/i) != null || thisfield.value.match(/discover/i) != null || thisfield.value.match(/american express/i) != null || thisfield.value.match(/amex/i) != null)
{
if (form.elements[i+1].value == "")
{
alert("you must choose a credit card type")
form.elements[i+1].focus()
return false
}
if (form.elements[i+2].value == "")
{
alert("you must enter the name that appears on this card")
form.elements[i+2].focus()
return false
}
if (form.elements[i+3].value == "00")
{
alert("you must choose an expiration month")
form.elements[i+3].focus()
return false
}
if (form.elements[i+4].value == "00")
{
alert("you must choose an expiration year")
form.elements[i+4].focus()
return false
}
if (form.elements[i+5].value == "" || form.elements[i+5].value.length < 15)
{
alert("you must enter the complete credit card number")
form.elements[i+5].focus()
return false
}

}
}
}
return true
}


can this be adjusted to includethat kind of funtion ; or does the whole thing need to be re-written? i am a newbie so please go easy on me. thx

Shift4Sms
07-19-2002, 12:45 AM
GT3_fiend,

Most of the code around the expiration date check seems like it needs a little work but I would recommend simplifying the checks to instead just check for the existence of required data and "maybe" some rudimentary checks -- has a payment method been selected, is the length of the card number at least 13 digits in length, is the expiration month between 1 and 12, is the year greater than or equal to 02 (or 2002).

All the stringent checks should be done server side, not client side. Being dependent on client side validation leaves a big hole for hackers and, depending on what report you read, anywhere from 5 to 30 percent of the people surfing the web have scripting disabled. And since server side validation needs to be done anyway, why duplicate code if you don't have to?

RadarBob
07-19-2002, 03:56 AM
Since you asked for opinions about rewriting....

You can skip all the below and just go out and buy [/list]Code Complete by Steve McConnell. Lots of good, practical advice for writing code. From my experience Mr. McConnell definitely knows what he's talking about! If anyone is bright enough to realize that coding is more than knowing the language syntax, then buy this book. :thumbsup:

------------

General Coding Principles
In general I'd have each check in it's own separate function. Then from a "main routine" I'd call each function in the desired order. The following won't make a lot of sense until you've done some coding and begin to see how good code differs from bad code, and why it's bad code - not just because it basically spits out the right answer. Good code, like a good building has thoughful design and structure.

By doing this you can have better control over your code, easily put in specialized code to handle that specific problem and can better control if, when, and how you exit for any problems your checks find.

You may say that's lots of extra code for all the function definitions and associated calls, but in the big picutre you make the code easier to understand, easier to test, easier to modifiy.

When you break out the code into functions you say "hey these are real small. That's good. Easier to read, easier to understand, easier to modify. Also the fuction is following a coding principle called "maximize cohesion and minimize coupling."

Cohesion means a function does one thing and only one thing. When you have a function that does, say, only checks for an empty field, then if you ever need to modifiy the logic of that check for some reason then you are modifying code in a small function and do not run the risk of mucking up other checks. Also when you test that change it's easy because all you have to do is run that one function. As you have the code now you have everything in one function. Therefore a change anywhere has more potential to muck up other code in the same function - because it too has to execute. Also when testing it's harder to isolate only that bit that you changed.

Coupling is kind of the other side of the cohesion coin. W/out going into tedious detail, realize that good cohesion naturally minimizes coupling. Also, if ever you make code changes to one function and it causes another function to misbehave, you've got a coupling problem.

Good function names
"checkfields()" doesn't tell me a darn thing. Of course you have so many things going on in that function it's impossilbe to give it a meaningful name. Generally use an "action verb - object" naming scheme. Also don't be lazy and use short names. Months from now you won't remember what they mean.

Pretty Printing
Good formatting of code is worth more than you can imagine. I remember a co-worker trying to find an error in a multi-thousand line program I wrote. She wasn't familiar with the code but she found the error in minutes because I had all my code lined up and she could see immediately that I had mistyped the name of an array index.

Sample:

function CheckforBlanks(thefield) {
var isBlank = new Boolean (false);

if (thisfield.value == "") {
isBlank = true;
}

return isBlank;
} // function DemoCodeFormatting()


[list]
indent everything inside the function
label the end of the function
line up code on the same level
I like to put blank lines above and below if, while, for, and other loops