Library like Chosen (with ajax) or Select2 can help a lot

That means either forcing everyone to use one, or supporting all of the popular ones. That's a non-trivial amount of work for maintainers and people using AA, so I want to make sure we choose the right direction.

On Nov 11, 2013, at 5:36 PM, Mirko Akov notifications@github.com wrote:

Library like Chosen (with ajax) or Select2 can help a lot

�
Reply to this email directly or view it on GitHub.

They fit really nice into ActiveAdmin, and right now there are really easy to add (but without AJAX)

If I were to choose an external dependency on this, it would be Select2, since it supports Ajax out of the box.

That being said, I've never tried hooking up the filters to use Ajax. This project has too many interesting challenges:-)

I don't see why you would need to force anyone to use it...can't it be just implemented as a formtastic input? that the developer can use via as: :autocomplete?

I will actually need this functionality in a couple of weeks and was planning to take a crack at it after #2656
Here are a couple of ideas I had in terms of the api/implementation that I had brewing in the back of head:

 # search by title, use standard AA rules for the display text, fill in the id
autocomplete :title

# search by title or isbn using standard display rules of AA
autocomplete :isbn_title, on: [:isbn, :title]

# custom search by isbn or title. (Ideally supporting select2's infinite scroll)
autocomplete :featured_editions do
  Edition.where(featured: true).where("title LIKE '?%'", params[:q]).page(params[:page]).per(20)
end

# search by isbn or title, but use the cover_with_title partial to render each row
autocomplete :isbn_title, on: [:isbn, :title], partial: 'cover_with_title'

# completely override the generation of results
autocomplete :custom do
  query = Edition.some_crazy_query
  render json: query.as_json ...
end

form do |f|
  f.input :edition, as: :autocomplete, source: :featured_editions
end

Then package up the results as simple json wrapper of { id: 1, html: 'whatever was generated' }, then a custom formatResult function can extract html and render each result.

sidenote: select2 is a much better choice since chosen wasn't designed for ajax

👍 on autocomplete DSL. Probably just use Ransack by default underneath with :title_cont or :isbn_or_title_cont when you pass in the field or array of fields.

Edit

Couldn't we also just use the association's resource index.json page passing in the Ransack query if a register for the resource exists? And then you can customize using the autocomplete syntax to optimize and customize the return.

Yeah, we'd probably want to use the built-in JSON API to look up records. I've done this recently:

select1 = fieldset.find 'select:first' # Companies
select2 = fieldset.find 'select:last'  # Users
select1.change(->
  $.get '/admin/users.json', q: {company_id_eq: $(@).val()}, (data)->
    select2.html data.map (u)-> """<option value="#{u.id}">#{u.name}</option>"""
).change()

Which was nice :)

I need to be able to easily customize the appearance of the autocomplete options. The simplest way I've thought to do that is to rely on server side partials & have the server send html, as opposed to the server sending json and having the javascript generate html.
Ideally I would much rather generate html on the client side but I don't wanna resort to client side templating, any ideas?

@shekibobo
I hope you don't mind, but I'll respond to your comment from #2656 "Select2 is actually pretty simple to integrate in ActiveAdmin on its own" here, to keep all autocomplete info in one place.

You are right, integrating select2 into ActiveAdmin isn't difficult, but it involves a some boilerplate. I've prototyped it in of my apps, but when its mixed with stylized row rendering & somewhat involved queries, it becomes a little ugly. I would like to extract the plumbing into ActiveAdmin to make the customized row rendering & queries a little more apparent.

well, crap in a hat, formtastic forces you to define custom inputs in the root namespace(::) or Formtastic::Inputs::
https://github.com/justinfrench/formtastic/blob/master/lib/formtastic/helpers/input_helper.rb#L353-L360

We override it :)

I'm going to take this off of the 1.0.0 milestone because this is blocked by #2638 & Kaminari

Can you clarify if this issue is about:

1. a select box having a lot of options
2. a parent having a lot of children
3. a parent having a lot of children that have a lot options

I'm pretty sure I can solve 1 without dealing w. #2638 & kaminari. Which will improve (but not solve) the situation with 2 & 3.

what date are you shooting for 1.0 release?

Hmm, actually this issue is specific to associations so it isn't really blocked by #2638. I'll put this back on the milestone.

For the different subjects you mentioned, I'm not sure I understand what you mean by "have a lot of options". When would you ever have a select box with a huge number of options that aren't parent or child associations?

@seanlinsley sorry not had chance to push on with this yet, i'm just back from a break.
The project that I'm using to drive this is just starting so I hope to get on it very soon. Will keep you posted with my progress here.

+1

+1

+1

Please guys, use emotions, in other case those +1 doesn't matter anything:

A nice plugin that solves this problem was released at the beginning of this year: https://github.com/holyketzer/activeadmin-ajax_filter

It supports autocomplete for associations in the form, as well as for filters on the index pages. It's quite simple to configure as well.

+1

IMO one-to-many and many-to-many associations selections are a weak point in ActiveAdmin.

If it can help: some times ago I made a plugin which integrates selectize.js (I didn't know of activeadmin-ajax_filter plugin when I started, which seems quite good).
Now I'm working on another plugin with the same intent: to improve the association selection (similar to RailsAdmin).

#4132 should make it so scopes with counts are usable on large tables.

Why not just make it the default to add config.filters = false at the top of your page definitions? For example:

ActiveAdmin.register SomeModel do
  config.filters = false
  # ...
end

Alternatively, you can override the default filters by manually declaring only filters that matter to you, or filtering on :

# SomeModel: { id: integer, name: string, association1_id: integer, association2_id: integer }
ActiveAdmin.register SomeModel do
  filter :name 
  # Add filter for column value that has a Contains/Equals/'Starts with'/'Ends with' dropdown
  filter :association1_id
  # Add filter for column's exact value (meaning, the exact ID of the associated record)
  filter :association2_id_eq
  # ...
end

You can also include records so they will load with your paginated result set:

ActiveAdmin.register SomeModel do
  includes :association1, :association2

Or define a controller block that contains a scoped_collection method definition inside the register block if you want even more flexibility on what you're putting in your index page.

IMHO the current functionality provides a lot of solutions that require less effort than the implementation details what this feature request is asking for.

We added a maximum_association_filter_arity configuration for this, but we never changed the default value to something low yet.

Is there a reason this was never addressed? Seems like a huge weak spot, as one can't do a belongs_to select with lots of records as options.

Would also love seeing a clean solution for this.

I've got some associations with tens of thousands of records and generating the drop downs for adding/removing these can be a real resource hog. Not to mention that finding the correct record in the resulting select box is bit of a hassle. Seems like some kind of typeahead find in stead of a select box would be great?

On a somewhat related note: Is there any way to sponsor the development of specific features? :D

This was addressed through the maximum_association_filter_arity configuration. Did you try setting it?

@deivid-rodriguez I'm sorry, I was a bit unclear in my description.

I don't have an issue with the filters – I've manually overriden those before when they have been problematic – but with editing a record with one or more associations to large amounts of items. Finding the right item to add add there, in a huge plain select box, can be cumbersome.

Especially cumbersome if you don't know exactly what letters(s) the item name starts with. 😅