Как вы создаете маршрут ресурсов, когда у элемента есть необязательные дочерние элементы?

Как вы создаете маршруты для моделей, у которых есть дополнительные дочерние свойства? Скажем, я создаю приложение службы поддержки, и тикет может быть связан с заказом, который клиент ранее делал со мной, или может относиться к элементу в каталоге, который он еще не заказал.

class CustomerServiceTicket
  belongs_to :order
  belongs_to :item
  belongs_to :buyer
  belongs_to :customer_service_category
end

class Order
  ...
  has_one :customer_service_ticket
  ...
end

class Item
  ...
  has_one :customer_service_ticket
  ...
end

в схеме для customer_service_ticket, order_id и item_id могут иметь значение NULL.

Таким образом, у меня будет ссылка «создать заявку в службу поддержки клиентов» рядом с их идентификатором order_id на странице их закрытых заказов... и аналогичная ссылка рядом с item_id на странице каталога продуктов.

Я думаю, что структура URL должна выглядеть так:

customer_service_ticket/новый/заказ/123

для тикетов, созданных по заказу

а также

customer_service_ticket/новый/элемент/789

для тикетов, созданных по предмету

и просто customer_service_ticket/new, когда нет ни того, ни другого (также подходит для случаев, когда у клиента просто есть общий вопрос)

Как бы я структурировал маршруты, чтобы они были наиболее эффективными? Я не женат на этой структуре URL выше, если есть лучший способ, я рад попробовать его.


ruby-on-rails-3.1 ruby-on-rails-3.2
person Webjedi    schedule 24.04.2012    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Судя по тому, как вы описываете свои маршруты, кажется, что заказы и товары уже существуют в то время, когда вам нужно создать новый запрос в службу поддержки клиентов, верно? Если это так, то было бы лучше создать свои маршруты следующим образом:

orders/123/customer_service_ticket/new
items/123/customer_service_ticket/new
customer_service_tickets/new

Каждый раз, когда вы добавляете ресурс к существующему ресурсу, новый ресурс обычно идет в конце, а действие, которое вы выполняете, является последней частью URL-адреса. Чтобы создать эту структуру, это будет примерно так:

resources :orders do
  resource :customer_service_ticket
end

resources :items do
  resource :customer_service_ticket
end

resources :customer_service_ticket

Однако вы также можете переосмыслить свои отношения. После закрытия службы поддержки клиентов для заказа/элемента вы уверены, что никогда не будет другого обращения в службу поддержки клиентов, относящегося к этому заказу/элементу? Это может указывать на отношения has_many. Вы также можете изучить полиморфную связь между заказами и товарами и заявками на обслуживание клиентов. Таким образом, если вы хотите добавить больше объектов, которые могут относиться к билетам службы поддержки клиентов, вам не нужно постоянно добавлять поля базы данных. Обратите внимание, что изменение на has_many немного изменит объявления маршрутов выше.

person Justin    schedule 25.05.2012