Example: Password validation
A website that involves user accounts would probably want to specify certain requirements for passwords (i.e.  it must contain both a letter and a number, but must contain no spaces). Normally (without the validation plugin), if the password entered does not meet the requirements, there will be a lag before the server realizes that the password is invalid. However, with client-side validation, there would be no wait time; passwords could be verified without sending information to the server.

Why the problem is hard:
Many of the fields that are generally checked for validity have flexible formats that would be difficult to check on a case-by-case basis. Also, creating the mechanism for showing and hiding error messages by modifying the DOM is a task in itself.

Why the problem is worth solving:
Most websites contain some sort of form that requires user input – whether it be a user account signup form or an elaborate search function – and form validation can be tedious and clunky if not for a validation plugin (in jquery). While similar plugins do exist, we will be addressing certain features that the other plugins do not include.

Part 2: A similar problem
We studied a similar implementation of form validation, done in javascript (linked at http://developer.apple.com/internet/webcontent/validation.html). This validation script contains a javascript function that checks for correct input of form fields. Below is an example of the code that checks for passwords:

function checkPassword (strng) {
var error = “”;
if (strng == “”) {
error = “You didn’t enter a password.\n”;
}
var illegalChars = /[\W_]/; // allow only letters and numbers
if ((strng.length < 6) || (strng.length > 8)) {
error = “The password is the wrong length.\n”;
}
else if (illegalChars.test(strng)) {
error = “The password contains illegal characters.\n”;
}
else if (!((strng.search(/[a-z]+/) > -1)
&& (strng.search(/[A-Z]+/) > -1)
&& (strng.search(/[0-9]+/) > -1))) {
error = “The password must contain at least one
uppercase letter, one lowercase letter,
and one numeral.\n”;
}

The above code essentially limits password creation to be a specific subset of the language of all strings. In particular, the first few lines of code checks that the password is not the empty string (i.e. a passowrd must be entered into the form), while the next two ‘if’ blocks ensures that the password is between 6-8 characters long and does not contain any whitespaces or underscores. In the last ‘if’ block, the code searches the input with regexes to specify the password to contain at least one lowercase letter, one uppercase letter, and one digit.

The implementation
All the code is in a file called validate.js, which can be called by an HTML ‘script’ tag at the top for the webpage with the form in it. The main function is shown below:

function checkWholeForm(theForm) {
var why = “”;
why += checkEmail(theForm.email.value);
why += checkPhone(theForm.phone.value);
why += checkPassword(theForm.password.value);
why += checkUsername(theForm.username.value);
why += isEmpty(theForm.notempty.value);
why += isDifferent(theForm.different.value);
for (i=0, n=theForm.radios.length; i<n; i++) {
if (theForm.radios[i].checked) {
var checkvalue = theForm.radios[i].value;
break;
}
}
why += checkRadio(checkvalue);
why += checkDropdown(theForm.choose.selectedIndex);
if (why != “”) {
alert(why);
return false;
}
return true;
}

This function acts as a wrapper function which calls the subfunctions, each of which performs checks on a field (the example above described checkPassword(), which was one such subfunction). For instance, the username field on the webpage would be checked by the checkUsername() function, which simply checks that the username is not the empty string. Some of these subfunctions, such as checkUsername(), checkRadio(), and checkDropdown() were pretty straightforward – regular expressions were used to match the input to the appropriate specifications. For checkPhone() (code shown below), there was an additional library function call to strip parentheses, spaces, and dots from phone numbers:

var stripped = strng.replace(/[\(\)\.\-\ ]/g, ”);
//strip out acceptable non-numeric characters
if (isNaN(parseInt(stripped))) {
error = “The phone number contains illegal characters.”;
}
if (!(stripped.length == 10)) {
error = “The phone number is the wrong length.
Make sure you included an area code.\n”;
}

The implementation does have its limitations. For example, the checkEmail() function does not check for email addresses that are RFC-compliant (this would require much more additional code). Furthermore, the code provides no support for AJAX requests, such that url’s could only be checked for correct formatting, but not existence. Also, this particular implementation was clunky in that each field check was hardcoded in javascript and there was no leeway for flexibility in the formatting of the fields – this resulted in code that was hard to reuse or update.

Part 3: Features Our Library Will Support
Here you will do your initial language design. Perhaps your language is a new standalone language; perhaps it is a library – either way, here you need to ask these question:

The domain of our language:
With our jQuery validation plugin, we wish to allow html programmers validate input forms without too much of a hassle. In particular, we want these programmers to be able to specify validation rules easily without having to specify the inner details of the checking function, or worse yet, hardcode checks against each input field.

To be more specific, we want users to have access to these functionalities:
-do a simple form.validate() call to validate the target form with defaults rules
-specify default text for input fields
-specify own rules (i.e. regexp’s to match against)
-specify own checking functions
-specify own error messages

Validation will happen:
-every time the submit button is clicked
-after the first click of the submit button, validation will happen on all ‘keyup’ and ‘focusout’ (aka blur) events

Our programming model:
Our jQuery library will adhere the jQuering programming model, or an object-oriented approach. More specifically, in our library we will be extending the jQuery object with a wrapper method called validate(options). This method will encapsulate all the details needed to handle field checking, as well as optional arguments to allow for customization. Thus, the user only has to call validate() with from the “form” element in the html page to perform validation. A few additional details:
-Validation is invoked inside a ‘<script>’ block inside the html file, and validate() is called after the document is ready. For example we want to write (in pseudocode):
<script> (document).ready(function () {(form).validate(~myoptions~)}) </script>
-Default text is set on an element-by-element basis. That means each input field needing default text should call the DefaultValue(~default message~)
-In order to specify which elements of a form need to be validated (and against which validation type), the user must modify the “class” attribute of his element tags. For example, say the user has a input field named “firstname” which he wants to make a required field. To do this, the user will set ‘firstname.class = “required”‘. In another example, if the user wants to set an input field named “myemail” to be both required and in proper email format, he will write ‘myemail.class = “required email”‘

Calling validate() without any arguments invokes the default validation rules that we have included in our plugin (i.e. required, email, and url), but users obviously might want to specify their own validation rules, such as for dates, credit card numbers, etc. To do this, the user passes in an (optional) argument to validate(); This argument will be in the form of a dictionary that maps field types to corresponding regexps. For example, say you want to validate the input type “idnum” to a five-digit number, then you would include
idnum : /\d\d\d\d\d/
in the argument dictionary. If a single regex is not powerful enough to check a given input type, then the user can specify his own checking functions in the same way,
idnum : function () {}

Our 3 Demos:
Main Demo: Form Validation
Our main demo demonstrates all of our plugin’s features except the customizability of validation rules and error messages. In our html header section, we write:
<script type=”text/javascript”>
$(document).ready(function() {
$(“#fname”).DefaultValue(“Enter your first name…”);
$(“#lname”).DefaultValue(“Enter your last name…”);
$(“#pass”).DefaultValue(“MyPassword”);
….
$(“#customerForm”).validate();
});
</script>

As explained earlier, our plugins are called on “document.ready”. In the document.ready block, the first few lines set the default text for particular fields, while the last line makes the call to validate() to initiate validation. In addition, elements in the form have their class attribute modified to reflect what the element needs to be validated against:
<input type=”text” size=”30″ name=”email” id=”email” accept=”" alt=”"/>
This specifies that the input field is required and must be of type ‘email’

Second Demo: Custom Validation Rules
This demo demonstrates our support for customizability of validation rules, checking functions, error messages. In this example, the html form has two field types, “num” and “numrange”. Since our default validation methods do not include checking against either of these types, the user must specify his own rules to check for num and numrange. Once again, all the plugin calls are made inside the document.ready block:
$(document).ready(function() {
$(“#customerForm”).validate({
mymethods: {
num: “^42$”,
},
mymethodfuncs: {
numrange: function (value, element) {
return this.optional(element) || ((value > 23) && (value < 54));
}
},
myerrors: {
num: “Wrong! Guess again.”,
numrange: “Do you know how to read?!?!”,
}
});
});

In this code, validate() is called with an argument dictionary. There are three fields in this argument:
mymethods, which contains validation rules that can be matched with just regexp’s,
mymethodfuncs, which contains validation rules that need more than just a regexp to match, and
myerrors, which contains custom error messages for the specified types. These rules/messages allow the user to write something like
<input type=”text” size=”20″ name=”fname2″ id=”fname2″ value=”" />
to validate a “numrange”.

Third Demo: Hidden Form Validation
This example shows how a single input string can be split into multiple sections, each of which can be validated separately. To do this, we call a javascript library to split the input string, and pass the resulting substrings into hidden input fields, which are not displayed to the client. A snippet of our code:
$(“#codeForm”).validate({
mymethods: {
pname: “^[a-zA-Z][a-zA-Z]+$”,
location: “^[a-zA-Z][a-zA-Z]+$”,
action: “[NSEW]|([NS][EW])”
},
myerrors: {
pname: “Please enter a valid name.”,
location: “Please enter a valid location.”,
action: “Please enter one of the cardinal directions.”
}
});
…
<input type=”submit” value=”Validate” onclick=”decode(code.value);” />
<input type=”hidden” name=”pname” id=”pname” value=”" /><br/>

As can be seen, custom rules are again specified, and validation is done through the click of a submit button.

Part 4: Implementation
Our two different approaches (from hw3)
Functional Approach:
This type of implementation would regard the form on a webpage to be one object, and we would implement different validation methods to handle every type of field. To validate a form, the user would, for each field that needs to be validated, call a method from the form object and apply that method to the field input. This means that there is no notion of the different entries of the form as different objects. This approach would probably be more difficult to debug (since there is less encapsulation of methods, as all methods reside in one object).

Object Oriented Approach:
For this approach, each field of a form stores its validation specifications in the field’s ‘class’ attribute in the DOM. We use a mix of jQuery’s selector methods and Javascript’s getElementByID function to access elements in the DOM. When the page is done loading we initialize object representations for the fields’ specifications and store them in the jQuery plugin. This makes the implementation more clean as the user would only have to modify the attributes for the fields he is using and leave the rest to the validator object. Debugging will be handled with a Javascript debugger, as our plugin is built on jQuery, and jQuery is built on top of Javascript. The specifications are represented with regular expressions; for instance, e-mail fields are checked against the e-mail regex.

Current implementation details (post-hw3)
Frontend:
In our project, the frontend involves calling our validation plugin under the ‘script’ tag in an html file. An html form is validated through a single call to validate(options), so users ‘use’ our plugin by passing in different values for the ‘options’ argument. In our implementation, a non-null argument to validate() will be in the form of a dictionary. Furthermore, we currently support three possible fields for this argument dictionary: mymethods, mymethodfuncs, and myerrors (‘mymethods’ and ‘mymethodfunc’ are used to specify validation rules, while ‘myerrors’ is used to specify error messages). Each of these fields is itself a dictionary mapping field types to their corresponding rules or error message.

When the ‘options’ argument, a dictionary of dictionaries, is passed into the validate() method of the plugin, we process it when a validator object is intialized. Inside our plugin, our validator class already has dictionary containers to store the default rules and error messages. Thus, by iterating through ‘mymethods’, ‘mymethodfuncs’, and ‘myerrors’ separately, we can add the key value pairs inside these dicts into the originally existing containers.

In addition, when validate() is called, our validation code iterates through every input element in the html file and checks the value of the ‘class’ attribute. If it not an empty string, then we use its value to do a dict lookup on the appropriate validation rule handler to apply

The core language:
Internally, validation rules are essentially functions that match the input against a regex. Thus, we designed our custom validation rule construct such that users simply had to specify ‘[field type] : [regex]‘ to implement a new rule. This meant that in our validation plugin, we had to desugar this construct by wrapping the regexp in a function.

The above desugaring only applies if the user specifies his validation rules through the ‘mymethods’ field. If the user were to specify them by using ‘mymethodfunc’, he would be writing out the entire checking function, and thus we can store this function directly inside our rules dictionary without any desugaring.

Internal representation:
As mentioned earlier, validation rules and error messages are both stored as dictionaries under the validator class. A call to validate() instantiates validator, which then contains all the instance variables and methods to do the bookkeeping and handling of validation. More specifically, once the validator object is instantiated, it filters all the input elements of the DOM, and then runs its check() method on each of these elements. Since all the validation rules (both defaults and user-specified) reside in a dictionary, check() can then lookup the particular rule to apply on the input field. In addition, our ‘keyup’ and ‘focusout’ event handlers ensure that the validator calls check() every time such an event occurs.

Interpreter/compiler:
Since the frontend and backend are both in JavaScript, the arguments passed in to our validate() method without any preprocessing – we simply take it as it is.

Debugging:
Since our plugin is an extension of the jQuery language, all existing debugging tools for jQuery are at the user’s disposal. However, we also realized that the user might want additional debugging features, and thus we included a debug flag, which can be set through an argument to validate(), which when turned on would trigger alert messages at different parts of our code. For example, in our input element processing code, turning on the debug flag would call alert(element.name) for every element that is being iterated over by the code.

1.Validate a basic form, which might include login, password, email, and website URL. Jquery plugins can actually be run on WordPress, so one example would be to test out validating fields on a wordpress form:

2. Password Strength Indicator

One of the features of our plugin is to show the strength of a password based on its attributes. In our implementation, password strength will be represented by a box that will vary in color depending on how strong the password is – red for week password, and green for strong password. The password field would only be validated when the indicator is green. Our strength indicator would look similar to this example.

3.Default values for form fields

Another demo that we would want to show is to provide default values for form fields. Thus, forms using our plugin will be displayed with default values in their fields (if applicable). Once the user clicks inside the field, however, the default value will be cleared.

1. The domain: What programs do you intend to write in you language? Write down the programs that you intend to write by the end of the Final Project. Is there an exciting demo among them? Remember, the narrower the domain the easier to develop the language.

We intend to create a form and field validation metaprogramming library that plugs into JQuery. Programs will use this library to abstract away actions like verifying URLs and sanitizing user input. The set of library functions would include:
Validation by field type – types range from passwords to e-mails, URLs, among others
Individual field validation – validation for select fields on the form
Complete form validation – validation for all fields on the form.

2. Your programming model: You have been exposed to functional, OO, dependence-based programming, to declarative programming for text processing (regexes) and parsing (grammars and syntax-directed translation), and to metaprogramming (greasemonkey). Which model is suitable for your domain? Chances are it is not on the list above. It’s possible you need to invent your own.

We intend to use the object-oriented model; our library will be written as a JQuery plugin. Form and field objects will be initialized from the raw form data. There will be functions associated with those objects to facilitate validation and data extraction.

3. Write an example program in your language: Pick the simplest from the list in point one and write it in your language. The semantics need not be fully fleshed out yet, as long as you understand which parts of the semantics are not defined yet.

Ignoring exact syntax, the idea would be something like this:
FormObject registrationForm = [formData]
registrationForm.validate()

This will pull a form’s data and initialize an object represntation of the form, and then the validate function will inspect each field and verify that it conforms to each field’s specs. An alternative method would be to directly validate the form data.

This type of implementation would regard the form on a webpage to be one object, and we would implement different validation methods to handle every type of field. To validate a form, the user would, for each field that needs to be validated, call a method from the form object and apply that method to the field input. This means that there is no notion of the different entries of the form as different objects. This approach would probably be more difficult to debug (since there is less encapsulation of methods, as all methods reside in one object).

Object Oriented Approach

For this approach, we would treat each field of a form as a separate object, and implement our validation specifications by creating methods for each particular field object. This makes the implementation more clean as the user would only have to access objects that correspond to the fields he is using.

Our jquery plugin is going to be addressing the difficulty of ensuring that the fields in an online form has valid inputs. When the owner of a website requires the user to input his information through a form or survey, certain fields, such as email, date, or url address require the input to be in a certain format. The problem is that there are numerous different types of fields, and each field could support flexible formats, making it tedious to hard-code field-checking for every form. In addition, appropriate error messages must be displayed, adding to the detail and complexity.

Example: Password validation

A website that involves user accounts would probably want to specify certain requirements for passwords (i.e.  it must contain both a letter and a number, but must contain no spaces). Normally (without the validation plugin), if the password entered does not meet the requirements, there will be a lag before the server realizes that the password is invalid. However, with client-side validation, there would be no wait time; passwords could be verified without sending information to the server.

Why the problem is hard:

Many of the fields that are generally checked for validity have flexible formats that would be difficult to check on a case-by-case basis. Also, creating the mechanism for showing and hiding error messages by modifying the DOM is a task in itself.

Why the problem is worth solving:

Most websites contain some sort of form that requires user input – whether it be a user account signup form or an elaborate search function – and form validation can be tedious and clunky if not for a validation plugin (in jquery). While similar plugins do exist, we will be addressing certain features that the other plugins do not include.

Below is an example of the code that checks for passwords:

function checkPassword (strng) {
 var error = "";
 if (strng == "") {
    error = "You didn't enter a password.\n";
 }
    var illegalChars = /[\W_]/; // allow only letters and numbers
    if ((strng.length < 6) || (strng.length > 8)) {
       error = "The password is the wrong length.\n";
    }
    else if (illegalChars.test(strng)) {
      error = "The password contains illegal characters.\n";
    }
else if (!((strng.search(/[a-z]+/) > -1)
  && (strng.search(/[A-Z]+/) > -1)
  && (strng.search(/[0-9]+/) > -1))) {
  error = "The password must contain at least one
    uppercase letter, one lowercase letter,
    and one numeral.\n";
  }

The above code essentially limits password creation to be a specific subset of the language of all strings. In particular, the first few lines of code checks that the password is not the empty string (i.e. a passowrd must be entered into the form), while the next two ‘if’ blocks ensures that the password is between 6-8 characters long and does not contain any whitespaces or underscores. In the last ‘if’ block, the code searches the input with regexes to specify the password to contain at least one lowercase letter, one uppercase letter, and one digit.

The implementation

All the code is in a file called validate.js, which can be called by an HTML ‘script’ tag at the top for the webpage with the form in it. The main function is shown below:

function checkWholeForm(theForm) {
    var why = "";
    why += checkEmail(theForm.email.value);
    why += checkPhone(theForm.phone.value);
    why += checkPassword(theForm.password.value);
    why += checkUsername(theForm.username.value);
    why += isEmpty(theForm.notempty.value);
    why += isDifferent(theForm.different.value);
    for (i=0, n=theForm.radios.length; i<n; i++) {
        if (theForm.radios[i].checked) {
            var checkvalue = theForm.radios[i].value;
            break;
        }
    }
    why += checkRadio(checkvalue);
    why += checkDropdown(theForm.choose.selectedIndex);
    if (why != "") {
       alert(why);
       return false;
    }
return true;
}

This function acts as a wrapper function which calls the subfunctions, each of which performs checks on a field (the example above described checkPassword(), which was one such subfunction). For instance, the username field on the webpage would be checked by the checkUsername() function, which simply checks that the username is not the empty string. Some of these subfunctions, such as checkUsername(), checkRadio(), and checkDropdown() were pretty straightforward – regular expressions were used to match the input to the appropriate specifications. For checkPhone() (code shown below), there was an additional library function call to strip parentheses, spaces, and dots from phone numbers:

var stripped = strng.replace(/[\(\)\.\-\ ]/g, '');
//strip out acceptable non-numeric characters
if (isNaN(parseInt(stripped))) {
   error = "The phone number contains illegal characters.";
}
if (!(stripped.length == 10)) {
	error = "The phone number is the wrong length.
	  Make sure you included an area code.\n";
}

The implementation does have its limitations. For example, the checkEmail() function does not check for email addresses that are RFC-compliant (this would require much more additional code). Furthermore, the code provides no support for AJAX requests, such that url’s could only be checked for correct formatting, but not existence. Also, this particular implementation was clunky in that each field check was hardcoded in javascript and there was no leeway for flexibility in the formatting of the fields – this resulted in code that was hard to reuse or update.