1

イベント モデルと events_type モデルがあります。すべてのイベントには、event_type モデルからの ID が割り当てられます。

私のイベント インデックス アクション/ビューには、URL で渡された ID を探すことで、選択したタイプのイベントをフィルターして表示できるフィルターがあります。例えば; http:localhost:3000/events?event_type=2

私がやりたいのは、このように代わりに event_type 名でこれを機能させることです。http:localhost:3000/events/filmなどで、各 event_type に一意のメタタグを提供できるようにしたいと考えています (これはおそらく、私の event_type モデルにフィールドを追加するための移行を意味します)。

これを承認する方法について誰か助けてもらえますか? それは単にルーティング/名前空間の問題でしょうか?

4

1 に答える 1

1

resources動的機能を追加するには、ルートのメソッドから分岐する必要があります。それは大丈夫です、私の答えの下に述べたように、私は実際にそうすることを好みます。

基本的な戦略は、resourcesあなたの:event_type. この場合、:event_typeルートをオーバーライドする前に効果的にルートを挿入します。

# routes.rb

# We want the vanilla index route to come first, then deal with the rest.
# Notice it receives no params.
get 'events'           to: 'events#index'

# Using scope or namespace gives us urls nested under that string:
#  /events/:event_type
# Using scope instead of namespace prevents the router for looking under a corresponding ruby module
# AKA if this was `namespace 'event_type' do`, it would look for a
#   `Events::EventsController#index` instead of using our `EventsController#index`.
# All of the `as:` statements are to preserve access to the standard
#   path+url helpers you get out of the box with `resources`.
# All of the `constraints:` are to prevent urls from overriding each other.
#   I don't believe they're strictly necessary in this example, but
#   explicit is better than implicit in your routes.
scope 'events' do
  get ':event_type/:meta',  to: 'events#index',     as: :event_by_type_and_meta, constraints: { :event_type => /[a-zA-Z]*/, :meta => /[a-zA-Z]*/ }
  get ':event_type',  to: 'events#index',     as: :event_by_type, constraints: { :event_type => /[a-zA-Z]*/ }
  get ':id/edit',     to: 'events#edit',      as: :edit_event,   constraints: { :id => /\d/ }
  get 'new',          to: 'events#new',       as: :new_event

  delete ':id',       to: 'events#destroy',   as: :delete_event, constraints: { :id => /\d/ }
  put ':id',          to: 'events#update',    as: :update_event, constraints: { :id => /\d/ }
  get ':id',          to: 'events#show',      as: :event,        constraints: { :id => /\d/ }

  post '',            to: 'events#create',     as: :create_event
  get '',             to: 'events#index',     as: :events
end

それが整ったら、あなたは:event_typeあなたをチェックして、EventControllerそれに応じてフィルタリングすることができます. タグを使用する場合は:meta、フィルターをさらに絞り込みます。

class EventsController < ApplicationController

  def index
    if params[:event_type]
      @event_type = EventType.find_by_name(params[:event_type])
      @events = Event.includes(:event_types).where(["id NOT IN (?)", @event_type.events_ids]).all
    else
      @event_type = nil
      @events = Event.filed_under(@event_type).all
    end
  end

RESTful API を作成していない場合は、resourcesピリオドを使用しないでください。ユーザーがアプリで最初に目にする部分は、URL 構造です。これは、ユーザー エクスペリエンスで最も見落とされがちな側面です。すべてのルートを明示的に記述することは、その経験を通して考えるのに役立ち、以下で使用しているより細かい制御を主張するのにも役立ちます。

を使用するだけでは公開されるべきではないルートをそのままにしておくことも簡単ですresource。URL を明示的に指定すると、セキュリティの脆弱性を認識するのに役立ちます。

于 2013-04-15T19:29:33.693 に答える