> Oh BTW, defined?(draper_collection_decorator) wasn't doing what you thought it was. It returns "method"

Oh good catch. Thanks!

> are there any other decorator gems that support collections?

I haven't really looked into other decorator gems. Draper seems to be the standard for this use case. My first reaction guess would be that no other gem will work with ActiveAdmin now without a lot of feature-detection code.

> 1. It seems like we should either define an API that people can follow for their own implementation
> 2. we should always rely on Draper
> 3. or we should gracefully fallback to not using a collection decorator if not available.
>
> Of those options, it seems 1 & 3 go well together.

1 + 3 is basically what we have now (except that the API is not documented). When I originally wrote the decorator feature I explicitly used a custom decorator for the test case to sort of have a working example to document that API (see https://github.com/gregbell/active_admin/blob/54f2d792977edbcf85db2165921eb863c332edb1/spec/support/templates/post_decorator.rb). However, since we keep on having problems with the draper API changes, I figured that we should actually just start testing with Draper. Also, the custom decorator required to conform to the API we needed used to be far simpler. Now I feel like you'd have to implement half of Draper to get it to work again...

2 is basically what I am advocating for, but once again, I totally understand not wanting vendor-lock AA users.

Just to play devils advocate again for a moment, what is your concern with vendor-lock? Is it for users that might want to use other decorator gems because I don't think there is enough of an API standard for this to work anyway. Or, are you concerned with making users install a gem that they might not use and bloating AA's dependencies? I don't mean to push on this issue too hard; I just want to debate a little to make sure we come up with the best decision in the end. So, another note: ActiveAdmin is in general fairly opinionated about which tools it uses such as arbre, devise, formtastic, inherited_resources, kaminari, and ransack/meta_search. Imagine supporting formtastic *and* simple_form (NOTE: I have a few apps that use formtastic in ActiveAdmin, but simple_form in the rest of the app).

Anyway, I'll support whichever decision you want to make on whether or not AA should depend on draper.

> `collection.map &:decorate`

This is actually why collection decorators exist. As soon as you do this, you lose your ActiveRecord scope. All sorts of things like get unhappy. In my experience working with decorators in ActiveAdmin [this is what blows up first](https://github.com/gregbell/active_admin/blob/master/lib/active_admin/helpers/collection.rb#L11).

So, to recap, our options are:

1. Use the current code and document the decorator API specifying it was intended to work with Draper but you could make it work if you use the documented example.
2. Change the collection decorator usage to version-check Draper, making it more clear that you should use Draper or not use decorators.
3. Depend directly on Draper. This would not require people to *use* Draper, but would allow us to target a specific version of Draper.

My original implementation was 1. I'd prefer to move towards 2 or 3 now.

Thanks for your input!