how to have many controllers under one admin page?

7 views
Skip to first unread message

Matthieu

unread,
Jan 27, 2007, 6:17:16 AM1/27/07
to rubyonra...@googlegroups.com
Hello,

Since I have many controllers that require administration treatment,
with the scaffold command I'm able to create one admin page for each of
these controllers.

How would it be possible to gather all of them under one page?

Or if it's not possible, how can I have a main Admin page with
subfolders in which I'll put every admin interfaces? (like
site.com/admin/controller1, site.com/admin/controller2...)

I'm a total beginner with Ruby on Rails so please try not to skip the
basic steps ;)

Thanks by advance

Best regards,

Matthieu

--
Posted via http://www.ruby-forum.com/.

Russell Norris

unread,
Jan 27, 2007, 8:35:41 AM1/27/07
to rubyonra...@googlegroups.com
While many people dislike the concept of putting admin controllers into their own namespace, I don't. So I'll let you in on how it's done along with some handy routing tricks I've picked up along the way.

1. You'll need to create the controller with script/generate controller Admin/Whatevers [where Whatever is the controller name.] which creates the controller in the subdirectory [app/controllers/admin]. It also puts it into the namespace Admin, the fullname being Admin::WhateverController.
2. I find it's easiest to go ahead and create another controller Admin::CommonController [created by script/generate controller Admin/Common] and have all the Admin controllers descend from it. That way you can have a common layout defined once in Admin::CommonController and it trickles down instead of adding it manually to each controller. It also can serve as a holding place for common code. For example, in Admin::CommonController...

  def go_home
    redirect to :action => :index
  end

That's something you type a lot. As a function in Admin::CommonController, now all the descendant controllers have access to it and you can write "go_home and return" instead of "redirect_to :action => :index" over and over. I find this to be one of the biggest benefits to using an Admin:: namespace.
3. Anyhow, now about routing. If you're using REST-y routing then there's a super awesome trick to keep the named routes for admin controllers from conflicting down the road with non-admin controllers as well.

  map.with options :name_prefix => "admin_", :path_prefix => "admin/" do |m|
    m.resources :whatevers, :controller => "admin/whatevers"
  end

The benefits are more obvious when there's a handful of controllers, natch! A heads ups though... Named routes will obviously have admin_ prefixed to them. This creates routes like admin_whatevers_url and the kinda oddly named admin_new_whatever_url instead of the more English new_admin_whatever_url. Just remember that the name_prefix truly is a prefix.
3a. I usually also define a method "index" on Admin::CommonController that redirects to the actual controller you want as a default admin controller for logins. That way " http://domain.com/admin" will get routed to "http://domain.com/admin/whatevers". You will have to add a route [map.admin "/admin", :controller => "admin/common", :action => "index"] for it as well. Of course, you don't have to redirect. You could use it as a dashboard of sorts. Do whatever there. You're the boss. But usually [because I'm trying to embrace the CRUD and REST] I'm redirected to another controller.
3b, If you're not all RESTed up [and why _not_??], you can still use that map.with_options to DRY some of the routing.

  map.with_options :controller => "admin/whatevers" do |m|
    m.admin_whatevers "admin/whatevers", :action => "index"
    m.admin_new_whatever "admin/whatevers/new", :action => "new"
    # And so on...
  end

I'm a big believer in the named routes and not using the :controller/:action/:id default, which can inadvertently expose methods you might not want exposed all the time. Though you should be using "private" to protect those kinds of methods anyhow. But the named route benefits are reason enough.

Anyhow, I hoped that helped.

RSL

Matthieu

unread,
Jan 27, 2007, 9:03:33 AM1/27/07
to rubyonra...@googlegroups.com
Russell Norris wrote:
> A very helpul solution!

Thank you a lot for your detailed explanations!

For the first two parts, I think I'll be able to manage it.
For the third, I don't really know what is REST or CRUD, so I'll read
some stuff about it before trying it.

And again, thanks a lot!

Matthieu

unread,
Jan 27, 2007, 3:04:37 PM1/27/07
to rubyonra...@googlegroups.com
Hi again!

When I try to follow what you told me ,I get this message:

NameError in Admin/commonController#index

uninitialized constant Admin::CommonController

RAILS_ROOT: ./script/../config/..


Do you have any idea of how to avoid this??

Thanks!!

Best regards

Matthieu

unread,
Jan 28, 2007, 8:27:42 AM1/28/07
to rubyonra...@googlegroups.com
Hello,

I somehow managed to make it works, so ignore the previous message!!

Thanks again!

Russell Norris

unread,
Jan 28, 2007, 11:01:06 AM1/28/07
to rubyonra...@googlegroups.com
Just making sure I pointed out that [for example] Admin::CategoriesController needs to descend from Admin::CommonController and not ApplicationController

class Admin::CategoriesController < Admin::CommonController # in admin/categories

and admin/common _does_ descend from application

class Admin::CommonController < ApplicationController

RSL
Reply all
Reply to author
Forward
0 new messages