Hello
I’m having trouble with routing within modules. I have a user directory
(/app/controllers/user) and within that I have a home controller
(User::HomeController). I want to route any request to Custom Application Development Software for Business - Salesforce.com
to the home controller within the user directory.
I’ve tried
map.connect ‘/user’, :controller => ‘home’
and
map.connect ‘/user’, :controller => ‘user/home’
and get “uninitialized constant HomeController”
and when I try
map.connect ‘/user’, :controller => ‘/user/home’
I get
compile error
generated/routing/recognition.rb:16: syntax error, unexpected tCOLON3,
expecting tCONSTANT
return {“controller” => ::::User::HomeController, “action” =>
“index”} …
I have had a similar problem with a heavily moduled application.
Moduling controllers (aka using “Controller Namespaces”) sounds like a
good idea, but practically, in current Rails, the whole thing appears
to be implemented as a half-hearted afterthought.
IIRC at the beginning you would encounter serious bugs with even the
most basic uses of controller namespaces. Then those bugs were (afaik)
fixed, but you still have some deep issues integrating them with the
rest of the Rails kingdom, e.g. the routes issue you raised and several
important plugins which simply don’t work with moduled controllers.
I’d love to hear from someone more informed than me what’s the current
situation with this (rather arcane) aspect of Rails.
My 2 cents:
It doesn’t seem as if the core developers are committed to supporting
controller namespaces. DHH for example explicitly shuns them (see the
RailsConf keynote). So the support for this feature, which had lows and
highs, is likely to see more lows than highs in the future. IMHO the
Rails core team should decree whether they are Evil, in which case they
should be removed to avoid trapping people (and I think they can be a
rather nasty trap), or otherwise that controller namespaces are Good,
in which case support for them should improve, e.g. they should be
better supported by routes.rb and plugins which break on them should be
considered broken.
I have had a similar problem with a heavily moduled application.
Moduling controllers (aka using “Controller Namespaces”) sounds like a
good idea, but practically, in current Rails, the whole thing appears
to be implemented as a half-hearted afterthought.
Concrete examples, please.
IIRC at the beginning you would encounter serious bugs with even the
most basic uses of controller namespaces. Then those bugs were (afaik)
fixed, but you still have some deep issues integrating them with the
rest of the Rails kingdom, e.g. the routes issue you raised and several
important plugins which simply don’t work with moduled controllers.
What are these deep issues and important plugins?
I’d love to hear from someone more informed than me what’s the current
situation with this (rather arcane) aspect of Rails.
Directories correspond to modules. Classes live in files in those
directories. No arcane magic lurking here.
My 2 cents:
considered broken.
I’d rather discuss in terms of code and test cases than how DHH seems to
you. Rails’ directory/module convention should hold for controllers as
well
as any other class that the dependencies mechanism autoloads. If you
have
issues or bugs, report, fix, test, and document them.
IIRC at the beginning you would encounter serious bugs with even the
most basic uses of controller namespaces. Then those bugs were (afaik)
fixed, but you still have some deep issues integrating them with the
rest of the Rails kingdom, e.g. the routes issue you raised and several
important plugins which simply don’t work with moduled controllers.
I distinctly recall Engines not working well with controller namespaces
for several releases (may have been fixed since then, haven’t
followed). I’ve seen ML postings of several other plugins breaking with
controller namepaces.
Do you happen to have a User model also? This would place your
HomeController class inside your User model, which is awfully strange.
jeremy
That was exactly the problem. I was using modules with the same name as
my models, which must’ve been screwing everything up. Thanks a million
Jeremy!!
-Mike
Could you explain the problem here? I don’t understand the issue or your
expectation.
I distinctly recall Engines not working well with controller namespaces
for several releases (may have been fixed since then, haven’t
followed). I’ve seen ML postings of several other plugins breaking with
controller namepaces.
If this is the sum of it, I recommend you use better-tested plugins. Do
you
have other examples? Otherwise, this smells like you got singed but are
proclaiming forest fire.
The problem is that in map.connect, you get the namespace and the
controller glued together: a request for controller bar inside
namespace foo would set :controller to be ‘foo/bar’. There’s no way to
seperate the two in routes.rb.
The entire path is the controller. You’re asking for a different way
of
looking at controller paths.
This problem prevented me from accomplishing a very specific task:
reroute all requests from ‘foo/’ to ‘baz/’. As
there was simply no way to get the controller and namespace as seperate
components, there was no way to say in routes.rb: “take every request
to a controller in namespace foo and redirect it to a controller with
the same name in namespace baz”.
This is a pretty obtuse requirement predicated on the above assumption
about
controller paths. An httpd-level rewrite is well-suited to big changes
to
the URL space like this: Redirect permanent /foo /bar
Over more than several months of Rails experience, controller
namespaces proved to engender a lot more trouble than they solved, and
require a lot more pain and effort than they saved. I find this to be a
good enough reason to warn newbies against them.
I’m sorry to hear that; I hope we can address the other problems you
experienced. Please open tickets for each if you remember what they
were.
Could you explain the problem here? I don’t understand the issue or your
expectation.
The problem is that in map.connect, you get the namespace and the
controller glued together: a request for controller bar inside
namespace foo would set :controller to be ‘foo/bar’. There’s no way to
seperate the two in routes.rb.
This problem prevented me from accomplishing a very specific task:
reroute all requests from ‘foo/’ to ‘baz/’. As
there was simply no way to get the controller and namespace as seperate
components, there was no way to say in routes.rb: “take every request
to a controller in namespace foo and redirect it to a controller with
the same name in namespace baz”.
Do you
have other examples? Otherwise, this smells like you got singed but are
proclaiming forest fire.
The reality is that I came to regret using controller namespaces. They
bit me with similar problems to the one OP experienced. They broke some
plugins, which worked fine without them. And eventually I was bitten by
the rerouting shortcomings which for me were the last straw. After
that, I stopped namespacing controllers altogether, and used only root
level controllers.
Over more than several months of Rails experience, controller
namespaces proved to engender a lot more trouble than they solved, and
require a lot more pain and effort than they saved. I find this to be a
good enough reason to warn newbies against them.