WiceGrid 3.6.0.pre4 examples

Custom filters (joined tables)

There are two approaches to custom filters with joined tables. The first thing that comes to mind is to define a column of a joined table with :attribute and :assoc , and submit a list of all possible values of this column to :custom_filter , like it is done in the example below in the Priority column:

g.column name: 'Priority', attribute: 'name', assoc: :priority, custom_filter: %w(Anecdotic High Low Normal Urgent) do |task|

This works but such a filter produces a query with a WHERE clause comparing a varchar field with one of the string values submitted to :custom_filter . This is not guaranteed to be as efficient as comparing an indexed integer foreign key with an integer primary key, thus, this approach is highly advised against.

To implement filtering by foreign keys, define the column with the foreign key in :attribute and submit a hash or a two element array containing the IDs and labels of the joined table to :attribute . This has a negative side effect on sorting - the column will now be sorted according to the numerical value of the foreign key. It can be dealt with by overiding sorting by :custom_order in initialize_grid :

custom_order: {'tasks.status_id' => 'statuses.position', 'tasks.project_id' => 'projects.name'}

  • # encoding: utf-8
    class CustomFilters2Controller < ApplicationController
      def index
        @tasks_grid = initialize_grid(Task,
          include: [:priority, :status, :project],
          order: 'statuses.name',
          custom_order: {
            # 'tasks.priority_id' => 'priorities.name',
            'tasks.status_id'   => 'statuses.position',
            'tasks.project_id'  => 'projects.name'
          }
        )
      end
    end
    
  • <%= grid(@tasks_grid) do |g|
    
      g.column name:  'ID', attribute: 'id', filter: false
    
      g.column name:  'Title', attribute: 'title'
    
      g.column name:  'Priority', attribute: 'name', assoc: :priority, custom_filter: %w(Anecdotic High Low Normal Urgent) do |task|
        task.priority.name if task.priority
      end
    
      g.column name:  'Status', attribute: 'status_id',  custom_filter: Status.to_dropdown  do |task|
        task.status.name if task.status
      end
    
      g.column name:  'Project Name', attribute: 'project_id', custom_filter: Project.to_dropdown do |task|
        task.project.name if task.project
      end
    
      g.column  name:  'Archived', attribute: 'archived' do |task|
        task.archived? ? 'Yes' : 'No'
      end
    
      g.column name:  'Added', attribute: 'created_at' do |task|
        task.created_at.to_s(:short)
      end
    
      g.column   do |task|
        link_to('Edit', edit_task_path(task))
      end
    end -%>
  • .well
      %h2= current_page_title
      %p
        There are two approaches to custom filters with joined tables. The first thing that comes to mind is to define
        a column of a joined table with
        %code :attribute
        and
        %code :assoc
        , and submit a list of all possible values of this column to
        %code :custom_filter
        , like it is done in the example below in the Priority column:
      %p
        %code g.column name:  'Priority', attribute: 'name', assoc: :priority, custom_filter: %w(Anecdotic High Low Normal Urgent) do |task|
    
      %p
        This works but such a filter produces a query with a
        %code WHERE
        clause comparing a varchar field with one of the string values submitted to
        %code :custom_filter
        \.
        This is not guaranteed to be as efficient as comparing an indexed integer foreign key with an integer primary key, thus, this approach is highly advised against.
      %p
        To implement filtering by foreign keys, define the column with the foreign key in
        %code :attribute
        and submit a hash or a two element array containing the IDs and labels of the joined table to
        %code :attribute
        \.
        This has a negative side effect on sorting - the column will now be sorted according to the numerical value of the foreign key.
        It can be dealt with by overiding sorting by
        %code :custom_order
        in
        %code initialize_grid
        \:
      %p
        %code custom_order: {'tasks.status_id' => 'statuses.position', 'tasks.project_id' => 'projects.name'}
    
    = show_code
    
    .row-fluid
      .col-md-12
        = render   'grid'
IDTitlePriorityStatusProject Name ArchivedAdded

141-160 / 500 show all
269culpa assumendaHighCancelledDivine FirmwareNo12 Mar 12:37Edit
271etResolvedDivine FirmwareYes19 May 12:37Edit
4nisi quiLowVerifiedDivine FirmwareNo18 Mar 12:37Edit
174ipsa quia voluptasAnecdoticPostponedDivine FirmwareNo18 Apr 12:37Edit
285iure veniam numquamAnecdoticResolvedDivine FirmwareNo29 May 12:37Edit
288consectetur dolores delectusNormalClosedDivine FirmwareNo18 May 12:37Edit
180cupiditate tenetur omnisCancelledDivine FirmwareNo17 Jun 12:37Edit
295itaque velitLowNewDivine FirmwareNo30 Apr 12:37Edit
75velit non magniDuplicateDivine FirmwareNo07 May 12:37Edit
151ullam labore architectoHighNewDivine FirmwareNo24 Mar 12:37Edit
306omnis voluptatem abAnecdoticVerifiedDivine FirmwareNo13 May 12:37Edit
308optio idLowDuplicateDivine FirmwareNo17 Jun 12:37Edit
154nostrumAnecdoticDuplicateDivine FirmwareNo06 Jun 12:37Edit
77sed quibusdam isteLowNewDivine FirmwareNo03 Jun 12:37Edit
78exercitationem sapienteUrgentClosedDivine FirmwareNo07 Apr 12:37Edit
316at enim ullamUrgentClosedDivine FirmwareNo12 Apr 12:37Edit
321quis est autemAnecdoticPostponedDivine FirmwareNo02 May 12:37Edit
160aut voluptatesLowDuplicateDivine FirmwareNo20 Mar 12:37Edit
466autAnecdoticVerifiedDivine FirmwareNo19 Mar 12:37Edit
457asperiores qui nonAnecdoticNewDivine FirmwareNo15 May 12:37Edit

Fork me on GitHub