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.

1. go to Rails Google co-op
2. right click on the search box.
3. select ‘Add keyword for this search’
4. fill out the resulting form and add a keyword like ‘rails’
5. move focus to the address bar (CMD-L on a Mac)
6. Type ‘rails sciwerks’ on the address bar

You can also do this with rails or ruby API methods.

You could also set up a quicksilver web search for this too.

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…

[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.

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

line.

Then stick this in your application helper.

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

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.

This technique is clearly one to keep an eye on for a good user experience. It is not yet clear to me when this type of interface can be used for maximal benefit, and when conventional paging should be the preferred method.

Unspace – Endless Pageless: No More Next Page

Yes, that is really me.

Typically this problem arises when a user attempts to submit a form and the server does not immediately respond to the request. The delay can be due to network traffic, high load, or a particularly complex action that must be completed. In any event, it does not take long before the user begins to wonder if they actually hit the button and they click it again just to make sure.

If your application is not properly designed, this can lead to multiple identical records, or actions being processed more than once. Sometimes with undesirable side effects (like multiple billing).

There are a couple of solutions to this problem.

1. Warn the user to avoid clicking the button more than once…. this is a complete cop out on the part of the programmers and is just inviting trouble.
2. Disable the submit button when pressed (using AJAX). This sort of works, but if the server is slow and non-responsive, this is likely to fail too. This will also fail if the user has JS turned off, or if they reload or go back to the form and resubmit.
3. Disable the button via javascript. This works reasonably well, but if the user uses the browser back button, they can press the submit button again, resulting in a double submit. Again, this will fail if JS is turned off

The reality is that all of these solutions have problems and don’t really address the underlying issue. The real problem is not that the user is submitting multiple copies of the same request, the problem is that the server is trying to act on all of them.

The double_submit_protection plugin for Rails

How it works.

1. User submits a request
2. If the request is successfully processed, it records the time and the contents of the params
3. if a request with an identical params array is processed within a predefined interval it will reject the request or redirect to another page

The user can then do whatever they want and they won’t be able to send the identical request again until the time interval expires.

If they change the content of the form and resubmit, that request will work.

Installation

Usage:

First, restart your server.

To protect your entire application from duplicate post requests (non-ajax) you can put the following code in your application controller.

Disclaimer and Tips

This is beta stuff, so don’t be surprised if it breaks things. In particular, it can block some repeated AJAX calls if you don’t configure it properly.

Note that since it uses a before filter to do it’s dirty work, you can limit the actions it applies to by passing an parameters like

You may need to adjust the timeout period to suit your needs. Longer timeouts will make your session object get pretty big.

If you have a datetime_select in your form, it may circumvent any timeout interval. If this control defaults to the current time, then the plugin will not be able to tell that it is the same because the ‘minutes’ field will be changing. It should work fine against multiple submit presses, but it will have a harder time with refresh-submit cases. Future versions may have the option to ignore datetimes in the params.

Occasionally there is a need to have a user enter a unique string. For example, if you want to ensure that a new user’s login id is not used by someone else. The traditional rails way of doing this is to set up a ‘validates_uniqueness_of’ validation on the model and then catch the error when you try to save the record.

From the user’s point of view, this can be a horrendously painful experience that can be akin to trying to outsmart the Sphinx.

The biggest problem here is that there is no feedback to the user if the value they selected is valid until they submit. Some forms will also force you to retype your new password everytime this fails as well. Double ouch!

Solutions

1. offer suggestions for valid responses when it fails the first time. Not exactly the best, you might as well autogenerate their id for them and hope they don’t forget it.
2. provide feedback with AJAX to let them know if the value is ok.

As you might have guessed from the title of the article, I’m going to show you how to do this with a standard rails auto_complete text field.

That’s it. Anytime the auto_complete matches a record, it will change the ‘login_error’ div to indicate there’s a problem.

Net result…. a much better user interface experience and much happier users.

Then just use ‘commit_tag’ instead of ’submit_tag’ in your form.
Strictly speaking, you don’t really need to give the button an ‘id’, but I do because it has the bonus side effect of making it easy programmatically disable the button from RJS templates.

One reason this approach is superior (I think) to an AJAX call is that there is less of a chance that an over-enthusiastic user will be able to click the button again before the AJAX response renders.

This requires some sort of javascript hackery to achieve, but the easiest way I’ve found to do this is with my trusty old KRJS pocketknife.

This will add this behavior for all submit buttons with the ‘commit’ id. The hardest part here is remembering to add the ‘commit’ id.

Requires: KRJS Plugin