Стратегия создания нескольких представлений для одного и того же класса на основе критериев с использованием драгоценного камня ROAR?

На самом деле это вопрос передового опыта / использования hwo для использования Roar & представимого в Rails, поскольку я не нашел никаких примеров этого. Вот два сценария. Я использую шаблон декоратора.

Сценарий 1:

Допустим, у меня есть класс Product, который имеет несколько атрибутов и ассоциаций. По умолчанию, когда кто-то делает запрос к api.com/products/1 - я хочу показать все, что у меня есть, но если кто-то делает запрос к другому действию, например, api.com/products/1/inventory_details - я хочу только чтобы показать ограниченное представление, которое относится к инвентарю (чтобы сделать его более быстрым для поиска инвентаря) или если кто-то делает запрос к api.com/products/1/assembly_details - я хочу вернуть матрицу связанных узлов вместе с некоторыми соответствующими деталями продукта,

Вопросы к сценарию 1:

  1. Создаю ли я отдельный представитель для каждого случая, например ProductRepresenter, ProductInventoryDetailRepresenter, ProductAssemblyDetailRepresenter, или мне нужно использовать какой-либо элемент управления потоком в ProductRepresenter?
  2. Если я создаю несколько представителей для одного и того же класса, как я могу использовать шаблон "представитель / answer_with" и "ответ_ в / рендер"?
  3. Могу ли я переопределить это на уровне действий?

Сценарий 2:

Допустим, у меня есть api.com/products/1, который может вызывать мое внутреннее приложение, но я также хочу показать его своим клиентам. Однако я не хочу, чтобы мои клиенты видели некоторые атрибуты, такие как детали инвентаря или, может быть, только один или два атрибута. Также в зависимости от уровня доступа сотрудников, я хочу ограничить их представление / представление.

Вопросы к сценарию 2:

  1. Я создаю определенный представитель для каждого случая, например ProductRepresenter, ProductClientViewRepresenter, или я использую какой-либо элемент управления потоком в ProductRepresenter?
  2. Если я создаю несколько представителей для одного и того же класса, как я могу использовать шаблон "представитель / answer_with" и "ответ_ в / рендер"?
  3. Могу ли я переопределить это на уровне действий - в зависимости от типа доступа, например: admin vsource_user vs shipping_user?

Любой совет будет оценен. (Я сделаю кросс-пост на github в Gem Roar-Rails)

1 ответ

Решение

Сценарий 1:

  1. Создаю ли я отдельный представитель для каждого случая, например ProductRepresenter, ProductInventoryDetailRepresenter, ProductAssemblyDetailRepresenter, или мне нужно использовать какой-либо элемент управления потоком в ProductRepresenter?

Да, пожалуйста, используйте отдельные классы. Не начинай с if: а еще и тому подобное дерьмо, как это делается в ванильных Rails. Один класс-представитель для каждого контекста - это то, что я считаю правильным. Однако вы должны использовать модули и включать их в декораторы для совместного использования общих свойств.

  1. Если я создаю несколько представителей для одного и того же класса, как я могу использовать шаблон "представитель / answer_with" и "ответ_ в / рендер"?

Вы можете использовать:: представляет для этого, см. Рев-рельсы.

  1. Могу ли я переопределить это на уровне действий?

Опять же, проверьте документы на respond_with а также render в ревах они позволяют явно устанавливать представителей.

Вопросы к сценарию 2:

  1. Я создаю определенный представитель для каждого случая, например ProductRepresenter, ProductClientViewRepresenter, или я использую какой-либо элемент управления потоком в ProductRepresenter?

Если речь идет только о сокрытии определенных свойств, вы можете попробовать :if и вставьте контекст в вызов рендеринга / разбора.

object.to_json(context: "admin")

property :title, if: ->(options) { options[:context] == "admin" }

Тем не менее, я настоятельно не рекомендую :if в общем, как всегда, оказывается в беспорядке решающих. Ударил меня на GitHub, может быть, мы сможем найти способ решить эту проблему на общем уровне, с контекстами или тому подобное?

  1. и 3. см. выше.
Другие вопросы по тегам