I think some of the reluctancy of web developers to use fieldset
elements to organize their forms stems from the fact that they don't look all that great by default. The legend
element labels the fieldset
element, which is rendered with an inset border around the whole thing. Another turn-off may be the fact that there's already a suite of styles that you can use to style your form
elements — and using fieldset
elements would just break the whole flow.
Showing posts with label form. Show all posts
Showing posts with label form. Show all posts
Thursday, June 26, 2014
Organizing Forms Using Fieldsets
Wednesday, June 25, 2014
Using Tooltips With Form Validation
The jQuery UI tooltip widget is a good way to describe what's required in a specific form input
element. A good way to instruct the user, so that they're less likely to receive validation errors when they submit the form. Even with this help, the user will likely get something wrong, or just forget to supply information altogether. In this case, you can use the same tooltip widget to provide a subtle visual cue that there's something wrong with their input.
Labels:
form
,
jqueryui
,
tooltip
,
validation
Monday, November 1, 2010
HTML Forms
Forms are useful tools for collecting information, whether they're physical, or or your computer screen. When we need specific bits of information, brevity is of virtue. Collecting these data fragments are why forms exist. A form value is as simple as a yes or no. They're as complex as a line or two of text. The web-equivalent of a paper form is the HTML form element. Given that a form is used to capture information, and, that is what it is good at, why aren't forms used more often in web pages? Not using a form element to gather user input is a classic example of reinventing the wheel. So why do we do it?
Maybe we don't like to use forms because we associate them with legacy-style HTML pages from the nineties. But forms aren't visual elements. Its the elements within the form that are displayed, the text inputs, the radio buttons, and selectors you can see. If a form is a non-visual element, that is, a structural element used to group others, why go out of our way to submit data by other means?
The ultimate purpose of a form element is pragmatic - it is functional, not presentational. There are two other data items forms store in addition to user input - the action and the method. The form action is a URI. A URI usually represents some data resource on the server. The form method corresponds to the HTTP method used to submit the form. When a form is submitted, the HTTP request is made with the stored action and method.
Another example of an element that stores an action and a method is an anchor tag. Links store the action in the href attribute. Just like forms, actions are URIs that represent resources on the server. So where exactly is the method stored? Links store the HTTP GET method implicitly. There is no way to click a link that sends a POST request without intervening with Javascript. Unlike forms, however, links take on the dual role of being both a functional and a presentational element - you can see links on the web page.
Since links can't send anything other than GET requests, we are more likely to use Javascript - assuming we want to make a POST request by clicking a link. This gives us full control over the HTTP request. When a user clicks a link, or any other element listening for click events, some Javascript function is triggered that will assemble the HTTP request. The request is then sent asynchronously behind the scenes. This work flow is especially easy with libraries such as jQuery. All it takes is a few lines of code to build the request and send it.
There is nothing inherently wrong with this approach - only writing code to do exactly what a form does is discouraged. This is especially true with GET requests that are sent as a result of user input. For example, we have a page that lists objects in a table. We also have a select element that filters the list by some field. When that selector changes, the page is refreshed with the new GET parameters. The request is triggered by binding the selector change event to a Javascript function. The function then builds the URI and sends the request. Alternatively, the select element is part of a form that stores the URI, and the method. Our function would simply submit the form.
Using forms as they were intended is good web-programming practice. They are perfect for collecting small pieces of information and map well to abstractions that exist on a server. Forms store HTTP methods, action URIs, group input elements, and assemble HTTP requests so that you don't have to. They exist for a practical purpose. Use them to your advantage and you'll be surprised at how much code you don't have to write.
Maybe we don't like to use forms because we associate them with legacy-style HTML pages from the nineties. But forms aren't visual elements. Its the elements within the form that are displayed, the text inputs, the radio buttons, and selectors you can see. If a form is a non-visual element, that is, a structural element used to group others, why go out of our way to submit data by other means?
The ultimate purpose of a form element is pragmatic - it is functional, not presentational. There are two other data items forms store in addition to user input - the action and the method. The form action is a URI. A URI usually represents some data resource on the server. The form method corresponds to the HTTP method used to submit the form. When a form is submitted, the HTTP request is made with the stored action and method.
Another example of an element that stores an action and a method is an anchor tag. Links store the action in the href attribute. Just like forms, actions are URIs that represent resources on the server. So where exactly is the method stored? Links store the HTTP GET method implicitly. There is no way to click a link that sends a POST request without intervening with Javascript. Unlike forms, however, links take on the dual role of being both a functional and a presentational element - you can see links on the web page.
Since links can't send anything other than GET requests, we are more likely to use Javascript - assuming we want to make a POST request by clicking a link. This gives us full control over the HTTP request. When a user clicks a link, or any other element listening for click events, some Javascript function is triggered that will assemble the HTTP request. The request is then sent asynchronously behind the scenes. This work flow is especially easy with libraries such as jQuery. All it takes is a few lines of code to build the request and send it.
There is nothing inherently wrong with this approach - only writing code to do exactly what a form does is discouraged. This is especially true with GET requests that are sent as a result of user input. For example, we have a page that lists objects in a table. We also have a select element that filters the list by some field. When that selector changes, the page is refreshed with the new GET parameters. The request is triggered by binding the selector change event to a Javascript function. The function then builds the URI and sends the request. Alternatively, the select element is part of a form that stores the URI, and the method. Our function would simply submit the form.
Using forms as they were intended is good web-programming practice. They are perfect for collecting small pieces of information and map well to abstractions that exist on a server. Forms store HTTP methods, action URIs, group input elements, and assemble HTTP requests so that you don't have to. They exist for a practical purpose. Use them to your advantage and you'll be surprised at how much code you don't have to write.
Labels:
form
,
html
,
http
,
javascript
Wednesday, October 7, 2009
Form Encode Errors
The FormEncode Python package has grown to be the standard for validating web requests in Python web applications. Rather than implement some custom code that ensures incoming request data is what is expected, FormEncode provides validation functionality that is common. Although the package name suggests that the validation may only occur on form data, this is not the case fortunately. The validation may be applied to any data. The data might not even come from the web, although, that is what its' intended use is.
Parameters of web controllers that make up the application are what the developers of these applications want to validate. This is how external clients are able to get data into the application. Through the parameters of the controllers. It is thus important to ensure that this data is acceptable to the application.
With FormEncode, schemas may be defined by a controller. These schemas are defined on a per controller basis and include the parameters used by the controller. By using this method of parameter validation, each parameter of the controller can be validated at the same time instead of trying to validate each parameter individually.
However, with schemas that have many parameters to validate, more than one parameter may be at fault for the validation failure. In this case, the exception raised by the validation failure has no useful meaning as a whole. What the client needs is an explanation for why each individual field failed. An example of how this can be done is shown below.
Parameters of web controllers that make up the application are what the developers of these applications want to validate. This is how external clients are able to get data into the application. Through the parameters of the controllers. It is thus important to ensure that this data is acceptable to the application.
With FormEncode, schemas may be defined by a controller. These schemas are defined on a per controller basis and include the parameters used by the controller. By using this method of parameter validation, each parameter of the controller can be validated at the same time instead of trying to validate each parameter individually.
However, with schemas that have many parameters to validate, more than one parameter may be at fault for the validation failure. In this case, the exception raised by the validation failure has no useful meaning as a whole. What the client needs is an explanation for why each individual field failed. An example of how this can be done is shown below.
#Example; Better formencode error handling.
import formencode
#A simple validation schema.
class Schema(formencode.Schema):
name=formencode.validators.String(not_empty=True)
#Get meaningful data from the formencode exception.
def format_error(e):
return e.error_dict
#Main.
if __name__=="__main__":
#Attempt to validate.
try:
Schema().to_python({"name":""})
except formencode.Invalid, e:
#Display the better error data.
print format_error(e)
Labels:
error
,
form
,
formencode
,
python
,
validation
Thursday, October 1, 2009
Django Form Fields
The Django Python web application framework comes with almost every component that one might need to construct a full-featured application. One common component of web applications are widgets. Widgets are similarly defined in most desktop GUI libraries. A widget is simply a smaller part of the GUI whole. Widgets typically have a tightly defined concept and purpose. For example, a button widget is meant to be clicked. Also, a button widget is also meant to be visually striking enough that it is obvious that it is meant to be clicked. Django comes with a set of widgets that are featured in almost every web application in one way or another.
Web applications generally contain forms. Nobody has gotten away with using the web without having to fill out a form at some point. The pieces of these forms are often referred to as fields. This is from a data or domain perspective. When talking about a field, you are generally talking about what data that field contains, how that data is validated and so on. When talking about widgets in a form, you are generally talking about the visual aspect, like what can this widget do and how does it look when it does it.
Django provides abstractions within the framework for both of these concepts. The two concepts are closely related and thus tightly coupled. In this particular situation, tight coupling is absolutely necessary. You can't have a field without a widget and vice-versa. The alternative would be to implement all the field functionality inside the widget abstraction which would give us something bloated and hard to understand. Modularity is a good thing even when tight coupling is necessary. The two classes representing these concepts are Widget and Field. The two classes and how they are related to one another are illustrated below.
Web applications generally contain forms. Nobody has gotten away with using the web without having to fill out a form at some point. The pieces of these forms are often referred to as fields. This is from a data or domain perspective. When talking about a field, you are generally talking about what data that field contains, how that data is validated and so on. When talking about widgets in a form, you are generally talking about the visual aspect, like what can this widget do and how does it look when it does it.
Django provides abstractions within the framework for both of these concepts. The two concepts are closely related and thus tightly coupled. In this particular situation, tight coupling is absolutely necessary. You can't have a field without a widget and vice-versa. The alternative would be to implement all the field functionality inside the widget abstraction which would give us something bloated and hard to understand. Modularity is a good thing even when tight coupling is necessary. The two classes representing these concepts are Widget and Field. The two classes and how they are related to one another are illustrated below.
Labels:
django
,
field
,
form
,
python
,
userinterface
,
webframework
Subscribe to:
Posts
(
Atom
)