Можно ли иметь согласование контента на уровне контроллера?

В Zend Framework 2 согласование содержимого происходит на уровне представления, и меня это вполне устраивает. Пример в моем контроллере:

public function viewAction()
{
    $id   = $this->params('id');
    $user = $this->getRepository()->findUser();

    return new ViewModel(array(
        'user' => $user,
    ));
}

Это либо отображает шаблон view.phtml для возврата html, либо преобразует пользовательский объект в ответ JSON. Так называемая стратегия просмотра определяет, как отображать ответ на основе запроса.

Поток приложения REST в моем веб-приложении

Этот тип согласования контента работает довольно хорошо для многих случаев использования:

  1. /user или indexAction() возвращает массив пользователей => возможно html JSON;
  2. /user/1 или viewAction() возвращает пользовательский объект => возможно html или JSON (пример выше);
  3. /user/1/update или updateAction() возвращает HTML-форму. POST для этого URL-адреса возвращает html или JSON при наличии ошибок. Или в случае успеха он перенаправляется на viewAction() и, таким образом, возвращает новую версию пользователя => html и снова возможно JSON;
  4. /user/create или createAction() возвращает HTML-форму. POST для этого URL-адреса возвращает html или JSON при наличии ошибок. Или в случае успеха он перенаправляет на viewAction() для только что созданного пользователя => html и снова возможно JSON

Мой вопрос

Есть несколько случаев использования, когда согласование содержимого является своего рода «требуемым» на уровне контроллера. Я не уверен, что упускаю из виду некоторые возможности: есть ли варианты, которые я могу использовать, например, в следующих случаях?

  1. Удалить пользователя: POST в /user/1/delete. В случае html-представления вы будете перенаправлены к списку пользователей (где удаленный пользователь теперь отсутствует). Если вам нужен ответ JSON, вы хотите вернуть 200 OK и объект JSON с сообщением об успешном удалении.
  2. Разместите комментарий к статье в блоге. В случае представления в формате html вы будете перенаправлены на сообщение, к которому добавлен ваш комментарий. Если вы запрашиваете ответ JSON, вы хотите вернуть 200 OK и объект JSON с комментарием, который вы только что разместили.

Моя цель состояла бы в том, чтобы не повторять согласование содержимого, уже присутствующее на уровне представления. Это также сделало бы мои контроллеры более толстыми, поскольку теперь у меня есть два возможных ответа (JSON и html), но это может быть не единственный случай. Если позже я захочу поддерживать XML или другой формат, у меня есть переключатели для каждого действия для этих типов ответов.


php rest model-view-controller content-negotiation zend-framework2
person Jurian Sluiman    schedule 14.10.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Интересно, что в настоящее время мы рассматриваем возможность переноса аспекта согласования контента из слушателей стратегии просмотра в плагины контроллера. Обоснование в значительной степени, как вы заметили, - задача контроллера - сопоставить входящий запрос с соответствующей моделью (моделями) и представлением. Таким образом, да, я думаю, что вы на правильном пути — и, вероятно, инструменты, разрабатываемые сейчас для версии 2.1, будут вполне соответствовать вашим методологиям. (Подробнее см. https://github.com/zendframework/zf2/pull/2615. .)

person weierophinney    schedule 15.10.2012
comment
Спасибо за Ваш ответ! Я знаю об этом PR и также разработал его в первой версии :) Мои опасения по поводу этого были примерами типичных вариантов использования этого PR: на самом деле логические части, которые, по моему мнению, относятся к слою представления. Также в качестве второго аргумента я могу представить, что такая логика не является устойчивой, если вы также хотите поддерживать PDF и XML. Затем вы получаете множество переключателей в своих контроллерах только на основе некоторых характеристик представления. Или я что-то неправильно вижу? Вы предпочитаете сочетать стратегии просмотра с согласованием содержимого контроллера? - person Jurian Sluiman; 16.10.2012
comment
То, как я смотрел на использование, заключалось в том, что я выборочно определял, какая стратегия просмотра является подходящей, изнутри контроллера. Задача контроллера состоит в том, чтобы упорядочить запрос и определить, что с ним делать, и частью этого является определение используемого представления. - person weierophinney; 18.10.2012
comment
С точки зрения контроллера с запросом => ответ вы правы, конкретный запрос может привести к ответу 200 OK, тогда как другим требуется ответ 30x. Принимаю сейчас, посмотрю как получится результат PR в коде приложения :) - person Jurian Sluiman; 31.10.2012