Tag: form

HTML5 autofill using autocomplete

Once in a while, the web development community reintroduces old ideas in a new way. Years ago, there was a concept called ECML (E-Commerce Markup Language) that added an HTML attribute to identify values in a FORM that could be auto-filled from a users “virtual wallet”. Sadly, while it was implemented on a variety of websites (mine included), it was not widely supported and disappeared.

The concept has been reintroduced as values in the ‘autocomplete’ attribute in HTML5. Traditionally this attribute was only used to prevent auto-filling of values, now it can identify which values it is related to for pre-fill.

The usual payment, address and demographic fields (and variations of each) are supported.

EXAMPLE:

^<input type="text" name="ccnum" autocomplete="cc-number" value="" />

REFERENCES:

Some other helpful Selenium methods

Here are a few other helpful functions for use of Selenium testing scripts as you often need to click links, fill in fields, and submit forms.


import java.util.List;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebDriverException;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
/**
*
* @param driver
* @param name
* @return
*/
public static WebElement findElementByName(final WebDriver driver, final String name){
final By el = By.name(name);
final WebElement wel = driver.findElement(el);
return wel;
}
/**
*
* @param driver
* @param name
* @param value
*/
public static void sendKeysByFieldName(final WebDriver driver, final String name, final String value){
final WebElement wel = findElementByName(driver, name);
wel.sendKeys(value);
}
/**
*
* @param driver
* @param xpath
*/
public static void clickByXpath(final WebDriver driver, final String xpath){
final By el = By.xpath(xpath);
//LOGGER.info("el is {}", el);
final WebElement wel = driver.findElement(el);
wel.click();
}
/**
*
* @param driver
* @param linktext
*/
public static void waitToClickLinkText(final WebDriver driver, final String linktext){
final WebDriverWait wait = new WebDriverWait(driver, 10);
final By el = By.linkText(linktext);
wait.until(ExpectedConditions.elementToBeClickable(el));
final WebElement wel = driver.findElement(el);
wel.click();
}
/**
*
* @param driver
* @param text
* @return
*/
public boolean pageContainsText(final WebDriver driver, final String text){
final String xpathExpression = "//*[contains(text(),'" + text + "')]";
final List<WebElement> list = driver.findElements(By.xpath(xpathExpression));
return list.size() > 0;
}

HTML5 speech input

Adding speech input to your webapp is much easier than it might first seem.
This is part of the proposed HTML5 enhancements to FORMS and is already implmented in some browsers.

Google Chrome (WebKit 534.24) added this in version 11 in April 2011.

XHTML compatible example:
<input type="text" x-webkit-speech="x-webkit-speech" speech="speech" value="" />

NOTE:
In this example, ‘x-webkit-speech’ is the proprietary attribute used by Google Chrome (WebKit). ‘speech’ is the expected HTML5 attribute when it is finalized.

REFERENCES:

META Tag ‘MSThemeCompatible’

Okay, so this one’s a little old, and I just found it while looking at some of Microsoft Update’s HTML source, it appears to be relevant for MSIE6 and newer and may be responsible for some interesting styling and behaviour of form components.

A quick search for it turns up lots of discussions about other browers such as Firefox being effected if the value is not defined… as such it’s likely a good idea to define it in your pages to be sure.

An old MSDN entry reads…

When running on Windows XP, Internet Explorer 6 and the content displayed in it sports a look and feel that matches the Windows XP platform. You can opt to have your HTML content not take on the same look as the operating system for elements such as buttons and scroll bars, by adding the following META tag:
<meta http-equiv="MSThemeCompatible" content="no" />

Setting this will disable theme support for the document. Some background on this, Windows XP (MSIE6) allows for the use of themes for the operating system to change the general color scheme of many elements.
As such, many HTML components (such as SELECT dropdowns, BUTTONS and INPUT fields ‘MAY’ also be effected if you don’t explicitly prevent it in your code.

There was some support for this in Mozilla Firefox builds for Windows, as such, while I’d normally recommend using a conditional comment, I’m torn in this case.

Cheers

HTML FORM’s unexpected effect on layout

I was recently looking back at some websites I’d created years ago and realized just how much of a hastle the HTML FORM tag used to be for page layouts.   This generally resulted in non-valid markup where the FORM tags themselves were improperly nested in TABLE, TR and TD tags.

Other than the obvious accessibility and semantic markup issues, there are two specific items that must be realized about the layout when working with a FORM.

The following examples assume the following source:

Hello<form>Again</form>World

FORM is a block element, forcing content around it to be separated:

Example displays as:
Hello
Again
World

  • FORM generally has a bottom margin to push content down below it.

Example displays as:
Hello
Again

World

  • CSS can fix both of these cases depending upon your specific problem:

<style type=”text/css”>
form { margin-bottom:0; display:inline; }
</style>

Example displays as:
HelloAgainWorld

 Cheers!

HTTP Forward vs. Redirect

A Controller servlet may perform either a forward or a redirect operation at the end of processing a request. It is important to understand the difference between these two cases, in particular with respect to browser reloads of web pages.

Forward

  • a forward is performed internally by the application (servlet).
  • the browser is completely unaware that it has taken place, so its original URL remains intact
  • any browser reload of the resulting page will simple repeat the original request, with the original URL

Redirect

  • a redirect is a two step process, where the web application instructs the browser to fetch a second URL, which differs from the original
  • a browser reload of the second URL will not repeat the original request, but will rather fetch the second URL
  • redirect is marginally slower than a forward, since it requires two browser requests, not one
  • objects placed in the original request scope are not available to the second request.

There are several ways to perform a Redirect, here are a few common ones:

  • URL Redirection (HTTP 301): 
    HTTP/1.1 301 moved permanently

Location: http://www.example.org/
  • HTTP Refresh Header (Not Recommended) 
    HTTP/1.1 200 ok

Refresh: 0; url=http://www.example.com/
  • HTML <meta /> tag 
    <meta http-equiv="refresh" content="0; URL=http://www.example.org/" />
  • JavaScript (many possible solutions, generally not accessible or searchable) 
    <script type="text/javascript">location.href='http://www.example.org/';</script>

In general, a forward should be used if the operation can be safely repeated upon a browser reload of the resulting web page; otherwise, redirect must be used. Typically, if the operation performs an edit on the datastore, then a redirect, not a forward, is required. This is simply to avoid the possibility of inadvertently duplicating an edit to the database.

More explicitly :

  • for SELECT operations, use a forward
  • for INSERT, UPDATE, or DELETE operations, use a redirect

In HTML, a <FORM> tag can either GET or POST its data. In this context, a GET corresponds to a SELECT-then-forward, and a POST corresponds to an edit-then-redirect.

It is strongly recommended that forms for the input of search criteria should use GET, while forms for editing database records should use POST.

SECURITY NOTE: When using GET, be sure to not expose sensitive data in the URL’s.

Single FORM INPUT causes submit on Enter/Return

This is a browser oddity that I’ve had to code around for years.  In most modern browsers (currently Mozilla Firefox 2.x and MSIE 7.0), when a FORM contains only one editable INPUT field pressing the Enter or Return key will automatically submit the form, but when there are more than one the form is not submitted.   This irregularity in the single field case is responsible for several odd errors, and often results in double-submits of form data to the server.

Here’s a newer solution to the problem, the ‘magic’ is in the javascript events that we’ve added to the FORM object itself, no longer do you have to place event handlers on every INPUT field as has often been done in the past.

NOTE: not completely valid XHTML for ease of documentation and readability.

<html>
<head>
<title>test of input submit</title>
<script type=”text/javascript”>
function keycheckForm(formObj,evt){
if(isEnter(evt)){
//alert(‘in form’);
if(checkFormInputs(formObj)){
formObj.submit();
}
}
}
/*
* Added to handle enter key press
* NOTE: this is based on  a ‘legacy’ function [checkEnter(e)] that returned the reverse boolean values.
* @param evt Event
* @return boolean
*/
function isEnter(evt){ //e is event object passed from function invocation
var characterCode; //literal character code will be stored in this variable
if(evt && evt.which){ //if which property of event object is supported (NN4)
characterCode = evt.which; //character code is contained in NN4’s which property
}else{
characterCode = evt.keyCode; //character code is contained in IE’s keyCode property
}
var rc = false;
if(characterCode == 13){ //if generated character code is equal to ascii 13 (if enter key)
rc = true;
}
return rc;
}
/**
* @param formObj Object
*/
function checkFormInputs(formObj){
var rc = false;
var allInputs=formObj.getElementsByTagName(‘INPUT’);
var formInputs = allInputs.length;
var textInputs=0;
if(formInputs>1){
var ct = allInputs.length;
var i;
for(i=0; i < ct; i++){
var inputObj = allInputs[i];
var typ = inputObj.type;
if ((typ==’text’) || (typ==’password’)) {
textInputs=textInputs+1;
}
}
if(textInputs>1){
rc=true;
}
}
if(rc==false){
//alert(“blocked because of size”);
}
return rc;
}
</script>
</head>
<body>
<form action=”example.php” method=”get” onkeypress=”return keycheckForm(this,event);” onsubmit=”return checkFormInputs(this);”>
<input type=”text” name=”textfield1″ value=”testing1″ />
<button type=”button” name=”mybutton” onclick=”this.form.submit();”>Click Me</button>
</form>
</body>
</html>

Cheers!

Auto focus ‘first visible’ form field on page…

Occassionally there comes a need to set the focus within a web page to the first ‘visible’ form field, here’s the most convenient I’ve found thus far…

Implementation:
1. Add the following Javascript to the HEAD section of your page.

function formfocus() {
if(document.forms.length > 0)
{
var formElements = ["text", "checkbox", "radio", "select-one", "select-multiple", "textarea"];
var form = document.forms[document.forms.length-1];
for (var j = 0; j < form.elements.length; j++)
{
var field = form.elements[j];
for(var x = 0; x < formElements.length; x++)
{
if (field.getAttribute("type") == formElements[x])
{
field.focus();
return false;
}
}
}
}
}

2. Add the function call to the BODY tag…

<body onload="formfocus();">

That’s it! Enjoy!