Topic: Admin Architecture

I am trying to figure out the best way to set up my administrative architecture. I want to have a set-up like the following:

/admin
/admin/categories/add
/admin/categories/edit
/admin/categories/show
/admin/products/add
... etc ...

So basically, the format:

/admin/[model]/[action]

Should I have different controllers for each model, or should I just have one admin controller that does it all? If separate controllers, do I just have something like the following, or is there a better way to do it?

AdminController (main admin controller)
CategoryAdminController
ProductAdminController

Re: Admin Architecture

I'd still like thoughts on my original question, but I am playing around with this right now:

I have my basic AdminController. Then I generate a scaffold: "script/generate scaffold category admin/categories", which creates Admin::CategoriesController.

From what I have read, this should work with the default routing in Rails, so going to "admin/categories/list" will have :controller => Admin::CategoriesController and :action => list, but going to "admin/categories" or "admin/categories/list" says "Unknown Action: No action responded to categories"

Does this not work with default routing after all?

Re: Admin Architecture

There is a naming conflict since both the controller and module have the same name (Admin). It doesn't know if "admin/categories" is the categories controller in the admin module or the categories action in the admin controller. The easiest way to fix this is to rename one.

As for how to handle the admin pages, what works well for most projects is placing the administrative actions inline with the rest of the site - especially if you are doing a RESTful design. For example, if you have a store site and you have a list of products, you would embed the administrative functionality in here so if the user is logged in as an admin they would see the "edit product" link for each product in this listing. This way you are separating the controllers based on what they manage (the models) not on how they are accessed.

If you make the admin section completely separate from the public area you may end up with a lot of duplication (needing to list the products and a way to search them for example).

Railscasts - Free Ruby on Rails Screencasts

Re: Admin Architecture

ryan, that's interesting because I have a similar type question to the OP. So what you are saying is that if I were building a CMS, I probably shouldn't have a /admin/page controller and a /page controller, but I should have page manage both the admin (create, update, delete) and public facing (read) features as part of the same controller (page)? How would I separate between an Admin "read" and a public user "read" then?

Re: Admin Architecture

It depends how you want the interface to behave. Chances are the "public" read and the "admin" read will look very similar, the only differences may be a few extra links for the admin section. You can handle this in the view for example:

<% if current_user.admin? %>
  # show admin links
<% end %>

If you want the two "read" views to be drastically different you'll need to create a separate action for them. If this is often the case with your site you may be better off with a completely separate admin section.

Railscasts - Free Ruby on Rails Screencasts

Re: Admin Architecture

Also: watch out for reserved words. I was trying to expose a "clone" action in the URL, and I tried every setting known to man. I got that same "Unknown Action: no action corresponded to clone" return, until I changed it to "mkclone."