1

名前空間とネストされたリソースの両方を使用するのはひどい考えですか?

たくさんのコントローラーを備えた管理エリアが必要です。その領域の一部のリソースは、入れ子にするのが理にかなっています。たとえば、次のようになります。

resources :suppliers do
  resources :products   
  resources :locations
end

このように名前空間を設定しながら:

 map.namespace :admin do |admin|
  resources :suppliers do
    resources :products 
    resources :locations
  end
 end

このような名前空間内でネストを使用することは可能ですか/良い考えですか? 物事をどのように構築すればよいですか?

4

1 に答える 1

1

管理領域の名前空間は、これらのコントローラーをパブリック/ユーザー向けコントローラーから分離するため、良い考えです。ここでの大きな利点はセキュリティです。なぜなら、管理アクセスをどのように構築したいかによって、管理アクションはより多くのことができる可能性が高く、承認の量を削除または制限するなどの特定のセキュリティ制限を回避できるからです。

リソースの入れ子については、意味がある場合は使用してください。親リソースのコンテキスト外でネストされたリソースのいずれかにアクセスしたくない場合は、ネストされたリソースを使用することをお勧めします。

例として、管理インターフェースがサプライヤーによってアクセスされ、各管理者がサプライヤーのリソースのみにスコープされる場合、そのネストされたリソースを単純にクエリでき、承認がアカウントがそのサプライヤーに関連付けられていることを確認するだけです。

class Admin::ProductsController < AdminController
  before_filter :load_supplier

  # your actions

  def load_supplier
    # Will trigger a 404 if the supplier does not belong to the admin
    @supplier = current_admin.suppliers.find(params[:supplier_id])
  end
end

もちろん、それはあなたが達成しようとしていること、管理領域の予想される聴衆が何であるか、彼らがすべてに完全にアクセスできるかどうかに大きく依存します. その場合、関係のコンテキスト外のリソースにアクセスする必要があります。たとえば、私が管理者で、サプライヤーに関係なくすべての製品に対して検索/並べ替え/フィルター処理を実行し (または 1 つ以上のサプライヤーでフィルター処理)、それらの制約から CSV/Excel を生成する必要があるとします。 . この場合、ネストされたリソースを使用すると、これが困難または不可能になる可能性があります。

個人的には、ネストされたリソースは、ユーザー/パブリックに面したコントローラーではより理にかなっており、管理領域ではより面倒であることがわかりましたが、それから私は常に少数の人に限定された管理インターフェースを構築してきました. その場合、私は通常、多くのカスタマイズオプションを備えた各モデルで基本的に完全な CRUD を提供する ActiveAdmin のような宝石に目を向けます。

于 2013-02-22T07:44:25.707 に答える