-
Notifications
You must be signed in to change notification settings - Fork 52
ModelAndView as HttpResponse #194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
ModelAndView as HttpResponse #194
Conversation
} | ||
|
||
public function __construct() | ||
public function __construct(array $headers = array(), array $cookies = array()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
почему бы тогда до кучи не добавить ещё аргумент $view и аргумент $model? Чем эти два лучше их?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Я хочу вообще отказаться от constructor injection в пользу setter injection, чтобы избежать проблемы с наследниками и несовместимым create
. Будет, по крайней мере, последовательно.
Я уже написал комментарий в коде что сейчас ModelAndView это просто контейнер. Ну можно добавить в него ещё переменных которые будут возвращаться из контроллера и это будет дельно. Но заставлять его render'ить уже лишнее. Подобную логику стоит держать в отдельном классе обработавающим ModelAndView. |
Спорно. $view = $mav->getView();
$headerCollection = $mav->getHeaderCollection();
$cookieCollection = $mav->getCookieCollection();
$status = $mav->getStatus();
if (is_string($view)) {
$view = ...;
}
header($status->toString());
// send $headerCollection
$cookieCollection->httpSetAll();
echo $view->render($mav->getModel()); |
Ну MaV сейчас ни для чего не используется кроме передачи model и view. Странным может казаться любое его использование. |
Так ведь BC это не ломает, а странность его использования только подтолкнёт к рефакторингу. Надо подумать по поводу FrontController. |
Я положительно отношусь к необходимости где-то (не во вью) аккумулировать заголовки и все остальное, что связано с http, но ИМХО ModelAndView не совсем удачное место для этого. Вот например, у меня сейчас в проекте почти везде два представления - html или json Более того, есть случаи, когда контекст http вообще отсутствует, при этом стандартная MVC вполне может быть. |
А откуда заголовки будут браться?
Я не вижу реального кейса. Сейчас у нас есть
Не во FrontController, допустим. А в каком-то фильтре. Причём мне это видится как-то так: class UserController implements Controller
{
public function handleRequest(HttpRequest $request)
{
$user = User::dao()->getById($request->getGetVar('id'));
return
ModelAndView::create()->
setView('viewUser')->
setModel(
Model::create()->set('user', $user)
);
}
}
class ResponseFormatFilter extends DecoratorController
{
private $view;
public function __construct(CustomView $view)
{
$this->view = $view;
}
public function handleRequest(HttpRequest $request)
{
$response = parent::handleRequest($request);
$format = $request->hasAttachedVar('format'); // Enumeration (HTML, JSON, XML, Protobuf, etc.)
if (!$format->isHtml()) {
$response->getHeaderCollection()->set('Content-Type', $format->getContentType());
$response->setView($this->view->setFormat($format));
}
return $response;
}
}
class CustomView implements View
{
private $serializer;
private $format;
public function __construct(JMS\Serializer $serializer)
{
$this->serializer = $serializer;
}
public function setFormat(Format $format)
{
$this->format = $format;
return $this;
}
public function render(Model $model)
{
echo $this->serializer($model->toArray(), $this->format->getName());
return $this;
}
}
|
Кстати, а для class NotFoundResourcesFilter extends DecoratorController
{
private $logger;
public function __construct(Logger $logger)
{
$this->logger = $logger;
}
public function handleRequest(HttpRequest $request)
{
try {
$response = parent::handleRequest($request);
} catch (ObjectNotFoundException $e) {
$this->logger->logException($e);
$response = $this->createNotFoundResponse();
}
return $response;
}
} Тогда в коде выше проверка наличия юзера не нужна и будет вполне RESTful. |
Примеры выше это примеры лишь одного проекта. В других проектах другие решения. То что тут делает ResponseFormatFilter, в других местах делают другие классы подругому. |
Идея поместить в MAV данные о заголовках, сомнительна Может в мав помещать view а в в него уже заголовки ? |
Позволяет делать редирект, выставлять заголовки/cookies более православно.
Во front controller будет что-то типа