为了在我们的应用程序中进行组织,我根据情况做了一些事情。
首先,关于管理员/用户功能的单独控制器,我会说你可能不想走那条路。我们使用授权和before_filter
管理应用程序中的权限。我们推出了自己的产品,但事后看来,我们应该使用CanCan。从那里你可以设置这样的东西(这是伪代码,实际语言取决于你如何实现授权):
before_filter :can_edit_user, :only => [:new, :create, :edit, :update] #or :except => [:index, :show]
protected
def can_edit_user
redirect_to never_never_land_path unless current_user.has_rights?('edit_user')
end
或者更高层次
before_filter :require_admin, :only [:new, :create]
并在您的应用程序控制器中
def require_admin
redirect_to never_never_land_path unless current_user.administrator?
end
这取决于哪条路线,但我会用它来授权而不是拆分控制器。
至于名称空间与嵌套资源,这取决于具体情况。在我们的几个应用程序中,我们都有。当存在逻辑分离的原因或一组控制器之间将共享功能时,我们使用名称空间。对我们来说,案例和要点是我们将管理功能放在命名空间中,并且在其中我们有用户、角色和其他专有管理功能。
map.namespace :admin do |admin|
admin.resources :users
admin.resources :roles
end
然后在这些控制器中,我们有一个基本控制器,它存储我们的共享功能。
class Admin::Base < ApplicationController
before_filter :require_admin
end
class Admin::UsersController < Admin::Base
def new
....
end
这为我们提供了数据的逻辑分离,并能够通过共享before_filter
.
如果有一段代码你希望在控制器之间保留一些东西,我们会使用嵌套控制器。我们应用的案例是我们的客户。我们搜索并加载客户,然后在该客户中,他们有订单、票、位置。在该区域内,我们在查看不同选项卡时加载了客户。
map.resources :customers do |customer|
customer.resources :tickets
customer.resources :orders
customer.resources :locations
end
这给了我们网址:
customers/:id
customers/:customer_id/orders/:id
customers/:customer_id/tickets/:id
我们从中体验到的其他优势是易于设置菜单系统和选项卡。这些结构非常适合有组织的网站。
我希望这有帮助!