uninitialized constant Draper::Railtie::ApplicationController

[krainboltgreene]

$ rails console
Connecting to database specified by database.yml
1.9.3-p194@manacurve-api/gems/rake-0.9.2.2/lib/rake/ext/module.rb:36:in `const_missing': uninitialized constant Draper::Railtie::ApplicationController (NameError)
  from 1.9.3-p194@manacurve-api/gems/draper-0.15.0/lib/draper/railtie.rb:39:in `block in <class:Railtie>'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/railtie.rb:179:in `call'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/railtie.rb:179:in `block in load_console'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/railtie.rb:179:in `each'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/railtie.rb:179:in `load_console'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/engine.rb:429:in `block in load_console'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/application/railties.rb:8:in `each'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/application/railties.rb:8:in `all'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/engine.rb:429:in `load_console'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/application.rb:153:in `load_console'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/commands/console.rb:27:in `start'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/commands/console.rb:8:in `start'
  from 1.9.3-p194@manacurve-api/gems/railties-3.2.7/lib/rails/commands.rb:41:in `<top (required)>'
  from script/rails:6:in `require'
  from script/rails:6:in `<main>'

I want to say I've reported this before, but I can't find it.

Basically Draper doesn't function in the console without an ApplicationController. My API doesn't have an ApplicationController. I only have namespaces (versions) so the class I have is V1::ApplicationController.

I really feel like this was already solved, but I again I can't find anything.

[steveklabnik]

What version of Draper are you using?

This should be making it work.

Oh, wait: here. Heh.

Yes, we currently assume that you have an ApplicationController. Not sure what the best way to fix this is.

[nashby]

@steveklabnik what about ActionController::Base?

[steveklabnik]

The issue is that we mix things into the ActionController so that we can monkeypatch view_context. Patching AC::Base in the same way would be hard.

Honestly, I'm tempted to say 'this rails app is odd, I don't want to complicate Draper to support it, please just make a blank ApplicationController and make your verisioned ones inherit from it.'

If we can support this cleanly somehow, I'm not opposed.

[krainboltgreene]

Is it really "odd" to have only namespaced ApplicationControllers? I mean, if I have multiple versions and they all share code, then yeah. I'd have a root AC. That said the different namespaces (versions) will have different inherited methods, constants, etc.

I may just add it to get past this bug. Kinda annoyed Rails doesn't have a mechanism like Rails.root_controller or something.

[steveklabnik]

Is it really "odd" to have only namespaced ApplicationControllers?

To me, yes. This may be a function of my own social circles.

[codeodor]

What makes patching ActionController::Base harder than ApplicationController? I'm curious, not trolling.

I'm especially interested in this because it seems to me that having your app's base controller named something other than the default seems like a useful deviation from default to me. (For example, I have one project where I make use of multiple base controllers as well).

[steveklabnik]

The key is here. We want to use the super behavior. For that, you need a subclass.

[krainboltgreene]

Worse is that I'm not even inheriting from ActionController::Base, I'm getting things from ActionController::API. This is all due to rails-api.

[steveklabnik]

Right. rails-api works a bit different...

[steveklabnik]

After giving it some thought, I don't want to support this use case. If someone can make it work without significantly complicating our codebase, please open a pull request, but I think this is far enough outside of the usual Rails Way that I don't want to work on supporting it myself.

[codeodor]

I guess when Ruby 2.0 comes out, and is adopted enough to use rely on it, you can use module prepending and have it equally simple to how it works now.

One option I was thinking of for now is to extend the instance of the controller with the module, which gives you the parent class. (But don't know enough about the project implementation yet to know if it would be simple in that context)

[steveklabnik]

I linked to the implementation a few comments up, if you want to check it out.

[steveklabnik]

So, I think I may have found a solution to this problem: https://github.com/plataformatec/has_scope/pull/31/files#L2L184

Therefore, re-opening and we'll see if we can take care of it.

[krainboltgreene]

That's way cool, thanks reopening.

On Nov 24, 2012, at 2:16 PM, Steve Klabnik notifications@github.com wrote:

So, I think I may have found a solution to this problem: https://github.com/plataformatec/has_scope/pull/31/files#L2L184

Therefore, re-opening and we'll see if we can take care of it.

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

[haines]

@steveklabnik AFAIK the one remaining ApplicationController reference is here. I think Draper already does what that pull request is doing, as of d8779aa

[steveklabnik]

Seems like it might, but I'd like to determine if it is or not.

[haines]

Since on_load does an instance_eval under the hood, what they are effectively doing in HasScope is this:

ActionController::Base.instance_eval do
  include Something
end

whereas Draper effectively does this

ActionController::Base.class_eval do
  include SomethingElse
end

by passing self (ie AC::Base) out of the instance_evaled block into setup_action_controller.

So, at the end of the day, they are equivalent.

[steveklabnik]

Makes sense.