Conversation
main/Flow/ModelAndView.class.php
Outdated
There was a problem hiding this comment.
почему бы тогда до кучи не добавить ещё аргумент $view и аргумент $model? Чем эти два лучше их?
There was a problem hiding this comment.
Я хочу вообще отказаться от 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 будет что-то типа