./README.md in sinatra-param-1.4.0 vs ./README.md in sinatra-param-1.5.0
- old
+ new
@@ -1,6 +1,7 @@
# sinatra-param
+
_Parameter Validation & Type Coercion for Sinatra_
REST conventions take the guesswork out of designing and consuming web APIs. Simply `GET`, `POST`, `PATCH`, or `DELETE` resource endpoints, and you get what you'd expect.
However, when it comes to figuring out what parameters are expected... well, all bets are off.
@@ -25,11 +26,11 @@
gem "sinatra-param", require: "sinatra/param"
```
## Example
-``` ruby
+```ruby
require 'sinatra/base'
require 'sinatra/param'
require 'json'
class App < Sinatra::Base
@@ -45,11 +46,11 @@
get '/search' do
param :q, String, required: true
param :categories, Array
param :sort, String, default: "title"
param :order, String, in: ["ASC", "DESC"], transform: :upcase, default: "ASC"
- param :price, String, format: "[<\=>]\s*\$\d+"
+ param :price, String, format: /[<\=>]\s*\$\d+/
one_of :q, :categories
{...}.to_json
end
@@ -58,32 +59,44 @@
### Parameter Types
By declaring parameter types, incoming parameters will automatically be transformed into an object of that type. For instance, if a param is `Boolean`, values of `'1'`, `'true'`, `'t'`, `'yes'`, and `'y'` will be automatically transformed into `true`.
-- `String`
-- `Integer`
-- `Float`
-- `Boolean` _("1/0", "true/false", "t/f", "yes/no", "y/n")_
-- `Array` _("1,2,3,4,5")_
-- `Hash` _(key1:value1,key2:value2)_
-- `Date`, `Time`, & `DateTime`
+* `String`
+* `Integer`
+* `Float`
+* `Boolean` _("1/0", "true/false", "t/f", "yes/no", "y/n")_
+* `Array` _("1,2,3,4,5")_
+* `Hash` _(key1:value1,key2:value2)_
+* `Date`, `Time`, & `DateTime`
### Validations
Encapsulate business logic in a consistent way with validations. If a parameter does not satisfy a particular condition, a `400` error is returned with a message explaining the failure.
-- `required`
-- `blank`
-- `is`
-- `in`, `within`, `range`
-- `min` / `max`
-- `format`
+* `required`
+* `blank`
+* `is`
+* `in`, `within`, `range`
+* `min` / `max`
+* `min_length` / `max_length`
+* `format`
+### Custom Error Messages
+
+Passing a `message` option allows you to customize the message
+for any validation error that occurs.
+
+```ruby
+param :spelling,
+ format: /\b(?![a-z]*cie)[a-z]*(?:cei|ie)[a-z]*/i,
+ message: "'i' before 'e', except after 'c'"
+```
+
### Defaults and Transformations
-Passing a `default` option will provide a default value for a parameter if none is passed. A `default` can defined as either a default or as a `Proc`:
+Passing a `default` option will provide a default value for a parameter if none is passed. A `default` can defined as either a default or as a `Proc`:
```ruby
param :attribution, String, default: "©"
param :year, Integer, default: lambda { Time.now.year }
```
@@ -122,24 +135,24 @@
By default, when a parameter precondition fails, `Sinatra::Param` will `halt 400` with an error message:
```json
{
- "message": "Invalid parameter, order",
- "errors": {
- "order": "Param must be within [\"ASC\", \"DESC\"]"
- }
+ "message": "Parameter must be within [\"ASC\", \"DESC\"]",
+ "errors": {
+ "order": "Parameter must be within [\"ASC\", \"DESC\"]"
+ }
}
```
To change this, you can set `:raise_sinatra_param_exceptions` to `true`, and intercept `Sinatra::Param::InvalidParameterError` with a Sinatra `error do...end` block. (To make this work in development, set `:show_exceptions` to `false` and `:raise_errors` to `true`):
```ruby
set :raise_sinatra_param_exceptions, true
error Sinatra::Param::InvalidParameterError do
- {error: "#{env['sinatra.error'].param} is invalid"}.to_json
+ { error: "#{env['sinatra.error'].param} is invalid" }.to_json
end
```
Custom exception handling can also be enabled on an individual parameter basis, by passing the `raise` option:
@@ -149,10 +162,10 @@
one_of :q, :categories, raise: true
```
## Contact
-Mattt Thompson ([@mattt](http://twitter.com/mattt))
+Mattt ([@mattt](http://twitter.com/mattt))
## License
sinatra-param is released under an MIT license. See LICENSE for more information.