= Using the Validate Request Plugin == Arguments +validate_request+ accepts three arguments, all of which are optional: * +valid_request_methods+ - One or more (in an array) symbols representing the HTTP request methods that this action supports. The default is :get. * +param_requirements+ - A hash that describes the arguments that are required for this action. * +param_options+ - A hash that describes other arguments that this action will accept, but which are not required. == Parameter Types When specifying parameters, you get to specify the type that the value should have. These can take several forms: === Basic Types Currently, +validate_request+ only recognizes two basic types: +:integer+ and +:text+ (or +:string+, if you prefer). Basically, no checks are done on values of type +:text+ or +:string+. Support for more basic types could probably be added if it's requested enough. I decided to only support positive integers, since they're mostly what you see in rails applications. Currently, I think it's a feature to disallow negative numbers. Let me know if you disagree with this decision. === Specific Values If you specify a string or something other than one of the basic types, then it will be compared directly to the value. For example, the declaration :name => 'bob' specifies that the +:name+ parameter must have a value equal to 'bob'. This is probably only useful in the param_options hash. Note that you can't specify multiple possible values for the same parameter (yet -- it's on the to-do list). === Nested Hashes It's important to support nested hashes, since rails uses them frequently in the params hash. So, you can specify them the same way as you'd expect to be able to: :id => :integer, :dog => {:name => :text, :age_in_years => :integer} You can nest hashes as deeply as you'd like. === ActiveRecord Models Finally, you can use descendent classes of ActiveRecord::Base (your models) as the requirements for a parameter type. This saves you a considerable amount of typing, and DRYs up your code by getting rid of repetition. The column names and types will be determined by examining the model itself. So we could have written the previous example like this: :id => :integer, :dog => Dog Now if we add a new column to the dogs table, it's automatically supported by both our model and our request validation. == Handling Bad Requests +validate_request+ will always return true or false to indicate whether the request met the definition or not. If you don't like the default behavior of setting flash[:error] and redirecting, you can turn those options off (see Configuration, below), and use this return value to implement your own behavior. It's usually a good idea to return immediately from the current action if +validate_request+ returns false. This is because redirects in rails do not take effect immediately; they only happen once the action has completed. So you'll probably need to return explicitly (as in the examples here) to avoid executing the rest of your action in the case of a bad request. == Configuration By default, invalid requests will be redirected to '/', and flash[:error] will be set with a polite error message. You can change this behavior by setting the following class variables (for example, within config/application.rb): * *@@redirect_for_bad_request* - Set this to the URL to redirect to if we get a bad request. Set to nil if you do not want a redirect (and just want to test the return value of validate_request). The default is the URL '/'. * *@@flash_error_for_bad_request* - Set this to the string that should be assigned to flash[:error] if we should get a bad request. Set it to +nil+ if you do not want flash[:error] to be set at all. The default is a generic yet polite error message. == More Information If you still have questions, it may also be worthwhile to look in the +test+ directory to see a fairly wide range of examples. You'll primarily be interested in +validate_request_test_helper.rb+, which sets up a test model and controller against which tests can be run, and +validate_request_test.rb+, which makes the different calls to the test controller and checks the responses. Finally, feel free to submit bug reports and feature requests to the project page at http://rubyforge.org/projects/validaterequest . -- Scott A. Woods