SciWerks.com » Forms

How to use an auto_complete to validate passwords

Kevin Olbrich — Thu, 01 Feb 2007 02:04:20 +0000

As a follow up to my previous article about using auto_completes to ensure unique filenames, I’ve put together a bit of code that does essentially the same thing except that it checks a password field to ensure that it meets certain criteria.

# view file
<%= text_field_with_auto_complete :user, :password %>
 
# model file
 
def User < ActiveRecord::Base
  validates_length_of :password, :in=>3..20
end
 
# controller file
 
def auto_complete_for_user_password
  @user = User.new(params[:user])
  @user.valid?  # ensures the errors array is populated
  password_errors = @user.errors.on(‘password’)
  render :update do |page|
     page.replace_html ‘login_error’, (password_errors.empty? ? "" : password_errors)
   end
end 

This will indicate when a password does not meet the validation criteria defined in the model. You can add custom validations to check the strength of the password itself.

Passing extra data with an auto_complete

Kevin Olbrich — Tue, 21 Nov 2006 19:23:43 +0000

I recently found myself trying to use an auto_complete field to allow the user to select an object from a list of possible objects. That’s all fine and dandy, but I wanted to exclude certain values depending on which object I was editing. There are at least two ways to do this, the first is to stuff the extra data into the session and then read that value from the auto_complete_for method and act appropriately.

I don’t really like this approach because I don’t want to clutter up the session with various form parameters. Thankfully, there is a simple way to do this by once again abusing the built in text_field_with_auto_complete function…

# View
<%= text_field_with_auto_complete ‘new_object’, ‘name’, { :tabindex=>1 }, {:url=>{:action=>’auto_complete_for_object_name’, :extra=>@object.extra} %> 

[In my case, I used the :extra data to exclude certain objects from the auto_complete_for response]

By passing the :url option, you rewrite the URL that the AJAX actions call, enabling you to add extra parameters that can be acted on by the method. Also note that you can change the name of the action called (in fact, you need to specify it or it will default to the name of the action for the current view… probably not what you want). This is handy because it lets you assign the response to a variable with a different name without writing a separate auto_complete_for handler. In this case, the submitted form will have a ‘new_object[name]‘ in the params, even though the action called was ‘auto_complete_for_object_name’.

Needless to say, you need to write a custom ‘auto_complete_for’ method to handle the extra data. Note that you could also use this method to handle multiple auto_complete fields.

Live Forms. Part 1: Putting the errors in the right place

Kevin Olbrich — Mon, 06 Nov 2006 02:33:59 +0000

This is Part 1 of a series describing how to make better forms for Rails.

The standard rails approach to handling form validation errors is to spit out a long list of all validation errors in a box at the top of the form. The problem with this approach is that there is a separation between the list of errors and the field that spawned them, like this.

This can be a bit annoying, particularly in a long form where the error message and the offending form field may not appear on the screen at the same time. Notice that you have to first read the error message, and then read the titles of all the fields to find the offending one(s) that need to be corrected. They aren’t even in the same order as they were specified in the form, which makes it even more confusing. This is just extra work for the user, particularly if your form is long or complex.

One way to address this problem is to put the appropriate error message right next to the field with the error. This way, it’s pretty obvious where the problems are, and even what they are. You can also generally avoid using the name of the field in the message.
A simple example of this might look like this….

This still isn’t pretty, but at least the user knows exactly which fields need correcting, and a little CSS magic can even place the message to the right of the offending field.

So how do we implement this?

Simple… first go into your view and delete the

error_messages_for ‘object’

line.

Then stick this in your application helper.

# application_helper.rb
def error_for(object, method = nil, options={})
    if method
      err = instance_variable_get("@#{object}").errors.on(method).to_sentence rescue instance_variable_get("@#{object}").errors.on(method)
    else
      err = @errors["#{object}"] rescue nil
    end
    options.merge!(:class=>’fieldWithErrors’, :id=>"#{[object,method].compact.join(’_')}-error", :style=>(err ? "#{options[:style]}" : "#{options[:style]};display: none;"))
    content_tag("p",err || "", options )     
  end 

Then in your form view, add an ‘error_for’ call wherever you need one…

# _form.rhtml
for="code_project_name">Name
<%= text_field ‘code_project’, ‘name’  %>
<%= error_for ‘code_project’, ‘name’ %>

If the model fails a validation test, then it will show the message right next to the field that caused the validation problem.
Also note that if you define an instance variable called @errors containing a hash of field_names and messages, they will also be used. This is handy for those form fields that don’t correspond to a model attribute.

Stay tuned for Part 2, where I will describe a how to make these error message dynamic with AJAX.