Warning: toplevel constant XYZ referenced Admin:XYZ


#1

I have an odd problem. I got controllers in a namespace and
controllers outside of the namespace. For example, I have a
PagesController and a Admin::PagesController.

When I run rspec from the top, tests pass and I get the following
warning:

spec/controllers/admin/pages_controller_spec.rb:4: warning: toplevel
constant PagesController referenced by Admin::PagesController

This makes no sense. I do have a PagesController and an
Admin::PagesController and specs for both that are declared properly.

I get this for 3 out of about 20 controllers.

Any ideas?


#2

On Apr 15, 2011, at 11:02 AM, dblock wrote:

This makes no sense. I do have a PagesController and an
Admin::PagesController and specs for both that are declared properly.

I get this for 3 out of about 20 controllers.

Any ideas?

Can you post the top 4 lines of pages_controller_spec?


#3

Hi,

On Sat, Apr 16, 2011 at 00:02, dblock removed_email_address@domain.invalid wrote:

This makes no sense. I do have a PagesController and an
Admin::PagesController and specs for both that are declared properly.

I would guess it’s Ruby trying to warn you that the use of the
constant PagesController in Admin::PagesController references the
top-level PagesController, not Admin::PagesController. It can’t know
which one you mean.

To make the warning go away, you can use ::PagesController where you
mean the top-level PagesController.

HTH,
Mike


#4

None of this makes any sense :slight_smile:

dblock@dblock-magenta:~/source/Gravity/dblock$ find . -name “*.rb” |
xargs grep PagesController

./spec/controllers/admin/pages_controller_spec.rb:describe
Admin::PagesController do
./spec/controllers/pages_controller_spec.rb:describe PagesController
do
./app/controllers/admin/pages_controller.rb:class
Admin::PagesController < AdminController
./app/controllers/pages_controller.rb:class PagesController <
ApplicationController

Now, lets compare with a controller that doesn’t yield the same issue.

dblock@dblock-magenta:~/source/Gravity/dblock$ find . -name “*.rb” |
xargs grep ArtworksController
./spec/controllers/admin/artworks_controller_spec.rb:describe
Admin::ArtworksController do
./spec/controllers/artworks_controller_spec.rb:describe
ArtworksController do
./app/controllers/admin/artworks_controller.rb:class
Admin::ArtworksController < AdminController
./app/controllers/artworks_controller.rb:class ArtworksController <
ApplicationController

These are identical, unless I’m blind :slight_smile: The only thing different is
timestamps - it looks like in the case where things work the Admin
spec is loaded after the non-admin spec.


#5

To make the warning go away, you can use ::PagesController where you
mean the top-level PagesController.

I tried saying ::PagesController in the 2 places it’s declared (the
controller itself and the spec), no difference.


#6

Top 4 lines of pages_controller_spec.

require ‘spec_helper’
require ‘spec_controllers_helper’

describe PagesController do
before(:each) do
controller.stub!(:app_initialization).and_return(true)
end

Top 4 lines of admin/pages_controller_spec.

require ‘spec_helper’
require ‘spec_controllers_helper’

describe Admin::PagesController do
include Devise::TestHelpers
before(:each) do
controller.stub!(:app_initialization).and_return(true)
log_in_test_user(Admin)
end

(changing PagesController to ::PagesController does nothing)


#7

Someone made some sense out of this.

http://code.dblock.org/warning-toplevel-constant-xyz-referenced-adminxyz


#8

the following is lifted from the ‘Gotchas’ section of my own internal
wiki, i hope it help’s someone else some day.

Can’t load namespaced controllers

Errors:

warning: toplevel constant Finance referenced by Member::Finance

OR

uninitialized constant Finance

Cause:

a namespaced controller / helper which is listed BEFORE it’s dependency.
e.g. ll member/finance/ bank_batches_controller.rb base_controller.rb

Fix:

make this the first line of the dependent require_dependency
“#{RAILS_ROOT}/app/controllers/member/finance/base_controller”.
requiring the dependent file before attempting to load the class. Yes,
this goes before class …