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