data_table:

Status

We’re in pre-alpha right now, I am trying to get this to meet my first requirements.

Goal:

Define a filter in your controller, like so:

Filter.spec(:name => :testing ) do |f|
  f.element(:type) do |e|
    e.default  "Foos and Bars", nil
    e.option   "Foos",          'foo'
    e.option   "Bars",          'bar'
  end
end

resulting in the following:

• helpers on the front end to render selection box filters that know what option was selected, if any
• asking for a set of additional conditions to pass to a model-based finder
• helpers that avoid rendering complex filter data in query params
• sorting for free
• AJAX or non-AJAX modes

Philosophy

• Sorting, filtering, and pagination are inter-related

Why aren’t we all using client-side sorting? That’s easy to implement! Oh, wait, that’s only for the records that were returned to the screen. And if you’ve sorted or filtered, it’s OK if clicking for the second page of results resets your end user’s intentions, right? Nope.

• Pagination is already a public problem in the Rails space

This project will look to integrate with other plugins in this space rather than offering an alternative implementation.

• Finders in the model are the place for complex queries

In short, this project’s philosophy is that’s where complex queries lead to the overall highest quality of testing.

• Easy things should be easy…

In many cases, a filter will just be operating on a couple of important fields on a model. In these cases, the filter itself could be made capable of generating ActiveRecord-ready conditions that can be passed directly to a finder for direct use.

• Difficult things should be possible

Sometimes, things get pretty hairy in those finders. For times when the filter’s AR-ready conditions cannot be reliable, the filter should still provide an expressive options hash which the finder code can manipulate and react to before ultimately issuing a query.