Webolution Designs » Application Musings

August 24, 2016

Who are you?

When utilizing forms, it is helpful to use a combination of the ID and name attributes, I typically name and ID my form and nearly all of my form fields so it is easy to manage them programmatically. Here is an example:

<form id="contactForm" name="contactForm">
    <input id="firstName" name="firstName" type="text">
    <input id="lastName" name="lastName" type="text">
    <input id="phone" name="phone" type="tel">
    <input id="submit" name="submit" type="button" value"Contact Us">
</form>

</form>

Accessing via ID or Name

As you can see, I made both the names and IDs the same. The reason I do this is because sometimes you use the ID in JavaScript to grab a field and in form processing, the form object, which is accessed via the name attribute, is used.

To access a field by ID:

document.getElementByID("firstName").value;

1	document.getElementByID("firstName").value;

To access a field via the name attribute:

document.formObject["firstName"].value;

1	document.formObject["firstName"].value;

Either one is a valid access method, but with forms and their processing, the form object is typically easier and used more often.

Happy Coding!

Clay Hess

August 22, 2016

GIGO

GIGO…Garbage In Garbage Out. This is a term that can sometimes be associated with data. Let’s face it, data is the lifeblood of any organization. In today’s marketplace, data analytics and data mining help organizations meet the needs of their clientele. So…that data needs to be protected to the utmost. This is where, as developers, we have a role to play.

DBA

Before I address the developer’s role, let’s chat about the database administrator’s (dba) role. It is their role to protect the data at all cost. Most good dba’s take this very seriously…and rightly so. As a developer, I sometimes don’t look at it that way and feel that it is a pain. “I mean, come on…just give me admin rights to the database and do a select asterisk so I can build cool apps!” I have said variations of this at times throughout my career. That quote is probably making dba’s skin crawl. They have a highly important job…let’s make it easier as developers. In comes data validation.

Data Validation Location

Data validation is performed in two main locations…server-side and client-side. I want to speak to the client-side in this post. This is the first line of defense and the easiest location to tend to things. Most data validation involves forms.

Let’s be real here…show of hands…how many of you have filled out a form, say a registration form, and put in bogus information just to get the form filled out and in the door? I thought so. Once that happens, the data is tainted. Developers can help prevent this.

There are two main ways to accomplish this…1) HTML constraints and 2) programmatic validation with JavaScript and Regular Expressions. I plan on addressing the coding side of things with regular expressions at a later date. For now, I want to speak to HTML constraints.

HTML Constraints

It can go a long way towards data validation when the proper HTML is used to build a form. Let’s say you are asking the end user for a date. HTML5 has a date input type field complete with drop down calendar! I recall building that by hand. That enhancement alone was worth the price of admission for me to HTML5. If the HTML is written with another input type, say a text field, well…you have opened the door to allow the end user to specify any date format they wish…which will lead to errors and possibly a knock on your door from your friendly. neighborhood dba.

Some examples of helpful HTML5 input types are:

search
email
url
tel
number
range
date
month
week
time
datetime
datetime-local
color

So make sure you select the proper HTML5 input types and constraints to make the rest of your validation easier.

Happy Coding!

Clay Hess

May 23, 2016August 22, 2016

Forms…how do they work?

In nearly every web application, you will build a form of some kind. There are a lot of moving parts with forms. So I thought I would spend a post discussing those parts…or at least parts of those parts.

Process

So how does this whole form process work? At its basic level, it works as follows…

End user submits the form
Form is received by the web server
Submission is passed to the app server (.NET, Java, PHP, etc.)
App processes the form (validation, database interactions, etc.)

Now, that is an extremely high-level explanation. There are a lot of pieces that need to be in place for a form to work properly. Let me address each of these over several posts. Let’s begin with the first one…the end user submitting the form.

In the ‘old days’, HTML forms were submitted directly to the web server. This is no longer the case. As web developers, what we typically do is capture the form submission. In other words, we do not allow the form submission to occur as it normally would under regular HTML. We want to control the submission process to ensure it is completed properly. Typically, this involves validation (which I will write a more detailed validation post at a later date). We want to make certain that our data is correct and we do not get

We want to make certain that our data is correct and we do not get ‘GIGO’, or Garbage In, Garbage Out. Data is the life-blood of an organization. So we want to ensure it is as clean as possible. This may be checking that the data is in the format required, that there is data in the form fields at all, etc.

So, nowadays, we grab the submission event and stop it. We then run the form data through several validation checks, give whatever feedback is necessary and submit the form on behalf of the end user.

There are several ways to stop the regular form submission process. Some of these depend on the framework that is being used. Allow me to offer just some examples of how a developer might do this…

// This example uses jQuery
$('#someForm').submit(function (evt) {
    // Prevent default stops the default behavior
    evt.preventDefault();
});
// This example is raw JS
element.addEventListener("submit", function(evt) {
    // Prevent default stops the default behavior
    evt.preventDefault();
}
// A return function statement can also be used
onsubmit="return someFunc()"

// This example uses jQuery

$('#someForm').submit(function (evt) {

// Prevent default stops the default behavior

evt.preventDefault();

});

// This example is raw JS

element.addEventListener("submit", function(evt) {

// Prevent default stops the default behavior

evt.preventDefault();

}

// A return function statement can also be used

onsubmit="return someFunc()"

I, personally, prefer the first two methods of using preventDefault(). This separates the functionality from the content.

Happy Coding!

Clay Hess