README.md in active_hash_relation-0.0.1 vs README.md in active_hash_relation-0.0.2

@@ -11,12 +11,20 @@
 ```
 or even filter a resource based on it's associations' associations:
 ```ruby
 apply_filters(resource, {updated_at: { geq: "2014-11-2 14:25:04"}, unit: {id: 9, areas: {id: 22} }})
 ```
-and the list could go on.. Basically your whole db is exposed there. It's perfect for filtering a collection of resources on APIs.
+and the list could go on.. Basically your whole db is exposed\* there. It's perfect for filtering a collection of resources on APIs.
 
+It should be noted that `apply_filters` calls `ActiveHashRelation::FilterApplier` class
+underneath with the same params.
+
+_\*Actually nothing is exposed, but a user could retrieve resources based
+on unknown attributes (attributes not returned from the API) by brute forcing
+which might or might not be a security issue. If you don't like that check
+[whitelisting](https://github.com/kollegorna/active_hash_relation#whitelisting)._
+
 ## Installation
 
 Add this line to your application's Gemfile:
 
     gem 'active_hash_relation'
@@ -80,11 +88,24 @@
 You can apply an incensitive matching filter (currently working only for Postgres):
 * `{example_column: test}`
 
 The above filter will search all records that include `test` in the `example_column` field. A better would be nice here, for instance, setting the search sensitive or insensitive, start or end with a string etch
 
+### Limit
+A limit param defines the number of returned resources. For instance:
+* `{limit: 10}`
 
+However I would strongly advice you to use a pagination gem like Kaminari, and use `page` and `per_page` params.
+
+
+### Sorting
+You can apply sorting using the `property` and `order` attributes. For instance:
+* `{property: 'created_at', order: 'desc'}`
+
+If there is no column named after the property value, sorting is skipped.
+
+
 ### Associations
 If the association is a `belongs_to` or `has_one`, then the hash key name must be in singular. If the association is `has_many` the attribute must be in plural reflecting the association type. When you have, in your hash, filters for an association, the sub-hash is passed in the association's model. For instance, let's say a user has many microposts and the following filter is applied (could be through an HTTP GET request on controller's index method):
 * `{email: [e-mail], microposts: {created_at { leq: 12-9-2014} }`
 
 Internally, ActiveHashRelation, extracts `{created_at { leq: 12-9-2014} }` and runs it on Micropost model. So the final query will look like:
@@ -100,9 +121,30 @@
 
 will run the `.planned` scope on the resource.
 
 ### Whitelisting
 If you don't want to allow a column/association/scope just remove it from the params hash.
+
+#### Filter Classes
+Sometimes, especially on larger projects, you have specific classes that handle
+the input params outside the controllers. You can configure the gem to look for
+those classes and call `apply_filters` which will apply the necessary filters when
+iterating over associations.
+
+In an initializer:
+```ruby
+#config/initializers/active_hash_relation.rb
+ActiveHashRelation.configure do |config|
+  config.has_filter_classes = true
+  config.filter_class_prefix = 'Api::V1::'
+  config.filter_class_suffix = 'Filter'
+end
+```
+With the above settings, when the association name is `resource`,
+`Api::V1::ResourceFilter.new(resource, params[resource]).apply_filters` will be
+called to apply the filters in resource association.
+
+
 
 ## Contributing
 
 1. Fork it ( https://github.com/[my-github-username]/active_hash_relation/fork )
 2. Create your feature branch (`git checkout -b my-new-feature`)