Showing posts with label validation. Show all posts
Showing posts with label validation. Show all posts

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.

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.
#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)

Thursday, September 18, 2008

Dynamic turbogears widgets and validation.

If you are using TurboGears widgets and have a need to build widgets dynamically within the context of a request, it simply doesn't work. Well, that's not entirely true. Here is a case where it is.

Say you are displaying a form to a user that displays a selectbox widget. This selectbox widget contains a list of languages supported by your application that the user can choose. For this, you would use a TurboGears widget. Now, say that you also want the default selection to be the language of the requesting client. This is a case where the widget would need to be dynamically constructed within the context of the request.

So far, so good. We can build TurboGears widgets in web controllers no problem. Now, what if we want to enforce some validation on the language selector? We use a TurboGears validator to say this widget may not be empty say. Well, when the widget validation fails, so does your widget because it can no longer be constructed. This is because the validation logic is taken care of for the developer outside the controller.

This is an obscure case but it is nonetheless realizable. Perhaps the TurboGears validation decorator should offer more flexibility in how widget failure validation is handled. Maybe this is already possible?