Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix the column_for_attribute deprecation warning for the last time #3930

Merged
merged 5 commits into from Nov 23, 2015

Conversation

seanlinsley
Copy link
Contributor

#3838

Turns out we couldn’t use type_for_column since:

  • it’s not intended as a public method
  • it would return a null object if the column had the default value (nil)

for example:

expected: "No"
     got: ""

(compared using ==)
 (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/table_steps.rb:96:in `assert_cells_match'
./features/step_definitions/table_steps.rb:79:in `block (2 levels) in assert_tables_match'
./features/step_definitions/table_steps.rb:75:in `each_index'
./features/step_definitions/table_steps.rb:75:in `block in assert_tables_match'
./features/step_definitions/table_steps.rb:74:in `each_index'
./features/step_definitions/table_steps.rb:74:in `assert_tables_match'
./features/step_definitions/table_steps.rb:115:in `/^I should see the "([^"]*)" table:$/'
features/index/index_as_table.feature:252:in `Then I should see the "index_table_posts" table:'

Failing Scenarios:
cucumber features/index/index_as_table.feature:244 # Scenario: Sorting

item.column_for_attribute(data) &&
item.column_for_attribute(data).type == :boolean
if item.class.respond_to? :columns_hash
column = item.class.columns_hash[data.to_s] and column.type == :boolean

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line is too long. [81/80]
Use && instead of and.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line is too long. [81/80]

@timoschilling I'd prefer the maximum to be 90 or 100 characters. Do you have a strong opinion either way?

Use && instead of and.

Heh, static code analysis can only understand so much.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seanlinsley There was already a discussion about that in #3841. I think the 120 chars from #3841 are to much, but 90-100 could be ok. In the past I have seen 80 chars as a "soft limit", in cases where a code rewrite is ugly then a long line, I have preferred the long line.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@seanlinsley does the test covers the difference between && and and? Not that some will change it and the test don't show it.

@seanlinsley
Copy link
Contributor Author

It's been a while since I've contributed. Did Travis always run the test suite twice?

screen shot 2015-05-03 at 8 33 53 pm

@Fivell
Copy link
Member

Fivell commented May 4, 2015

@seanlinsley , I think in case when item is decorated item.class.respond_to? :columns_hash will always give false

@timoschilling
Copy link
Member

@seanlinsley your commit run's as a ActiveAdmin repo commit (continuous-integration/travis-ci/push) and as a PR commit (continuous-integration/travis-ci/pr). That's happens only if a ActiveAdmin contributor creates a PR from a ActiveAdmin branch.

@seanlinsley
Copy link
Contributor Author

@Fivell that might be true, in which case we need more tests!

@Fivell
Copy link
Member

Fivell commented May 5, 2015

@seanlinsley, I can add cucumber feature failing/or not here (https://github.com/activeadmin/activeadmin/blob/master/features/index/index_as_table.feature) if you need it

@deivid-rodriguez
Copy link
Member

@Fivell Are you still up for adding that failing test?

@timoschilling
Copy link
Member

@Fivell maybe you can continue the work on this PR?

we couldn’t use `type_for_column` since:
- it’s not intended as a public method and
- it would return a null object if the column had the default value (nil)

for example:
```
expected: "No"
     got: ""

(compared using ==)
 (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/table_steps.rb:96:in `assert_cells_match'
./features/step_definitions/table_steps.rb:79:in `block (2 levels) in assert_tables_match'
./features/step_definitions/table_steps.rb:75:in `each_index'
./features/step_definitions/table_steps.rb:75:in `block in assert_tables_match'
./features/step_definitions/table_steps.rb:74:in `each_index'
./features/step_definitions/table_steps.rb:74:in `assert_tables_match'
./features/step_definitions/table_steps.rb:115:in `/^I should see the "([^"]*)" table:$/'
features/index/index_as_table.feature:252:in `Then I should see the "index_table_posts" table:'

Failing Scenarios:
cucumber features/index/index_as_table.feature:244 # Scenario: Sorting
```
@seanlinsley seanlinsley force-pushed the 3838-column_for_attribute-deprecation branch from fedccff to 714b092 Compare October 11, 2015 14:52
@seanlinsley
Copy link
Contributor Author

I'm working adding that test now.

@seanlinsley your commit run's as a ActiveAdmin repo commit (continuous-integration/travis-ci/push) and as a PR commit (continuous-integration/travis-ci/pr). That's happens only if a ActiveAdmin contributor creates a PR from a ActiveAdmin branch.

It seems like we should make it so continuous-integration/travis-ci/pr only happens on master, and on version branches like 0-6-stable.

forced to fix them. This is one deprecation:

>DEPRECATION WARNING: Using ActiveRecord's `find` on a
CollectionDecorator is deprecated. Call `find` on a model, and then
decorate the result. (called from block in add_default_batch_action at
lib/active_admin/batch_actions/resource_extension.rb:73) (StandardError)

This issue was introduced by #3775, which started decorating
collections for batch actions. The Draper ticket that resulted in the
deprecation is: drapergem/draper#509.

The simple solution would be to no longer decorate the batch action
collections, which is what this commit does.
@seanlinsley
Copy link
Contributor Author

Okay, this is ready for review.

@seanlinsley
Copy link
Contributor Author

@Fivell this PR stops decorating the batch action collection, because I couldn't figure out how to get around the Draper deprecation from calling find on a collection decorator. Unless I'm mis-remembering, before #3775 we didn't decorate batch actions. Why did you add that in the first place?

@Fivell
Copy link
Member

Fivell commented Oct 13, 2015

@seanlinsley , how do you think isn't it confusing when you're declaring decorator, you still have some places where it is decorated and some places where it isn't. However I have no idea too how to fix this stupid deprecation warning as well.

@seanlinsley
Copy link
Contributor Author

It seems like the only way we could continue to decorate the collection is by doing the filtering for the user, which would be a breaking change.

batch_action :archive do |collection|
  collection.each{ |record| record.update archived: true }
end

We might want to do that for AA 2.0, but for now I don't think we can support decoration.

@Fivell
Copy link
Member

Fivell commented Oct 13, 2015

@seanlinsley , maybe we can introduce new specific method filtered_collection on controller level to make it possible to use for AA users who want to have decorated items, other can use batch_collection collection which will be documented about it contains undecorated items ?

@seanlinsley
Copy link
Contributor Author

I don't think it makes sense to provide both filtered_collection and batch_collection. If you're applying decoration to Active Admin, there's no reason to provide an undecorated version.

A nice way to provide the new DSL without needing to deprecate anything would be to still pass the IDs as a block argument, but provide collection as a method that would automatically apply filtering and decoration.

batch_action :archive do |ids|
  ids == [1,2,3]
  collection.is_a? Draper::CollectionDecorator # with filtering applied

Is there a reason we would use batch_collection instead of collection?

@Fivell
Copy link
Member

Fivell commented Oct 13, 2015

@seanlinsley , sorry not clear for me how it helps

@fabn
Copy link
Contributor

fabn commented Nov 6, 2015

What's the status of this PR? Does it solve the deprecation warning? Thanks.

@fabn
Copy link
Contributor

fabn commented Nov 9, 2015

For other seeking for a solution until this is merged. I imported this in my code using a monkey patch, ugly but effective

module ActiveAdmin
  # Module used to define patches using Module#prepend
  module Patches
    # Original module
    module Views
      # Monkeypatch for https://github.com/activeadmin/activeadmin/pull/3930
      module TableFor
        protected

        def is_boolean?(data, item)
          if item.class.respond_to? :columns_hash
            (column = item.class.columns_hash[data.to_s]) and column.type == :boolean
          end
        end
      end

    end
  end
end

ActiveAdmin::Views::TableFor.prepend ActiveAdmin::Patches::Views::TableFor

@seanlinsley
Copy link
Contributor Author

@fabn this does indeed fix the deprecation. I'm going to go ahead and merge it, moving the decorator discussion to #4211

@seanlinsley seanlinsley merged commit e4aa309 into master Nov 23, 2015
@seanlinsley seanlinsley deleted the 3838-column_for_attribute-deprecation branch November 23, 2015 03:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants