Cобытие Model::EVENT_ON_LOAD
-
- Сообщения: 610
- Зарегистрирован: 2015.07.16, 10:50
Re: Cобытие Model::EVENT_ON_LOAD
http://symfony.com/blog/new-in-symfony- ... figuration
На симфони тоже учат говнокодить)
Имхо, хелпер в виде проще и понятнее.
На симфони тоже учат говнокодить)
Имхо, хелпер в виде проще и понятнее.
Re: Cобытие Model::EVENT_ON_LOAD
ты просто не понимаешь, что я пишу. Как раз по ссылке все правильно - отображением занимается вьюшка, а не не модель.andrei.obuhovski писал(а):http://symfony.com/blog/new-in-symfony- ... figuration
На симфони тоже учат говнокодить)
вьюмодель и есть хелпер. Только в классическом и практическом виде.andrei.obuhovski писал(а):Имхо, хелпер в виде проще и понятнее.
Re: Cобытие Model::EVENT_ON_LOAD
Наверное он имел ввиду что там хелпер форматирования в ядре и исользуется такая конструкция:zelenin писал(а):вьюмодель и есть хелпер. Только в классическом и практическом виде.andrei.obuhovski писал(а):Имхо, хелпер в виде проще и понятнее.
Код: Выделить всё
\HtmlView::formatDate($model->date_created);
На самом деле это тоже наглядно. По поводу дублирования кода при использовании такого хелпера, это получится, как в анекдоте:
Если перефразировать, то он должен не знать структуры проекта, проект не задокументирован, никто не делает код ревью и тп...Чтобы вступить в рукопашный бой, боец спецназа должен:
1) Потерять на поле боя автомат, пистолет, нож, поясной ремень, лопатку, бронежилет, каску.
2) Найти ровную площадку на которой не валяется ни одного камня или палки.
3) Найти на ней такого же распиздяя.
-
- Сообщения: 610
- Зарегистрирован: 2015.07.16, 10:50
Re: Cобытие Model::EVENT_ON_LOAD
Возможно. Давай на конкретном примере.zelenin писал(а):ты просто не понимаешь, что я пишу
Я так понял предлагаешь использовать это:
Контроллер:
Код: Выделить всё
$model = Post::findOne(1);
...
$viewModel = new PostViewModel($model);
$this->render('view, ['viewModel' => $viewModel]);
Код: Выделить всё
class PostViewModel
{
private $date;
private $title;
private $content;
private $authorName;
public function __construct(Post $model)
{
$this->date = $model->date;
$this->title = $model->title;
$this->content = $model->content;
$this->authorName = $model->author->username;
}
public function getDate()
{
return DateTimeHeper::formatDate($this->date);
}
public function getTitle()
{
return strtoupper($this->title);
}
public function getContent()
{
return $this->content;
}
public function getAuthorName()
{
return $this->authorName;
}
}
Код: Выделить всё
<?php
$date = $viewModel->getDate();
$title = $viewModel->getTitle();
$content = $viewModel->getContent();
$authorName = $viewModel->getAuthorName();
?>
Далее html со вставками
Вместо этого:
Контроллер:
Код: Выделить всё
$model = Post::findOne(1);
$this->render('view', ['model' => $model]);
Код: Выделить всё
<?php
$date = DateTimeHeper::formatDate($model->date);
$title = strtoupper($model->title);
$content = $model->content;
$authorName = $model->author->username;
?>
Далее html со вставками
Re: Cобытие Model::EVENT_ON_LOAD
как мы видим, ты преобразуешь данные во вьюшке, вместо того, чтобы форматирование инкапсулировать где-то. Плюс ты имеешь возможность во вьюшке прямой доступ к модели, можешь ее даже изменить, что подталкивает тебя и других разработчиков говнокоднуть.
$date = DateTimeHeper::formatDate($model->date); = $date = $viewModel->getDate(); практически без оверхеда.
И во втором случае ты все форматирование инкапсулируешь в одном классе, который выступает адаптером между моделью и вьюшкой, передавая во вьюшку только безопасные скаляры, не обладающие поведением. Плюс все данные для вьюшки у тебя В ОДНОМ МЕСТЕ. Править тебе надо в одном месте, добавлять поля в одном месте. Мы получаем чистую вьюшку вместо вьюшки на 5000 строк, где переменная $title в самом начале не равна переменной $title в самом конце, потому что где-то в середине ее изменили.
Неужели не очевидны плюсы такого подхода? Неужели не понятно, что удобно группировать логику преобразования переменных в одном месте вместо разброса преобразований в вбольшой вьюшке? Это удобнее для программиста и безопаснее для проекта - меньше шанса наговнокодить.
$date = DateTimeHeper::formatDate($model->date); = $date = $viewModel->getDate(); практически без оверхеда.
И во втором случае ты все форматирование инкапсулируешь в одном классе, который выступает адаптером между моделью и вьюшкой, передавая во вьюшку только безопасные скаляры, не обладающие поведением. Плюс все данные для вьюшки у тебя В ОДНОМ МЕСТЕ. Править тебе надо в одном месте, добавлять поля в одном месте. Мы получаем чистую вьюшку вместо вьюшки на 5000 строк, где переменная $title в самом начале не равна переменной $title в самом конце, потому что где-то в середине ее изменили.
Неужели не очевидны плюсы такого подхода? Неужели не понятно, что удобно группировать логику преобразования переменных в одном месте вместо разброса преобразований в вбольшой вьюшке? Это удобнее для программиста и безопаснее для проекта - меньше шанса наговнокодить.
Re: Cобытие Model::EVENT_ON_LOAD
$date = $viewModel->getDate();zelenin писал(а):Неужели не очевидны плюсы такого подхода? Неужели не понятно, что удобно группировать логику преобразования переменных в одном месте
ну только если все равно создавать базовый класс baseViewModel, в котором можно назначить:
Код: Выделить всё
public function getDate(){
return '<div class="date">'.$this->date_created.'</div>';
}
Re: Cобытие Model::EVENT_ON_LOAD
зачем искать все viewModel для правки? ViewModel уникален для каждой вьюшки.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Cобытие Model::EVENT_ON_LOAD
Плюсы-то очевидны. Но и минусы тоже...
Нравится Yii? Давайте сделаем его лучше!.
Re: Cобытие Model::EVENT_ON_LOAD
мне - нет.Sam Dark писал(а):Плюсы-то очевидны. Но и минусы тоже...
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Cобытие Model::EVENT_ON_LOAD
Это потому, что проблема излишней абстракции не рассматривается вами как проблема.
Нравится Yii? Давайте сделаем его лучше!.
Re: Cобытие Model::EVENT_ON_LOAD
один уровень абстракции - это не излишняя абстракция.Sam Dark писал(а):Это потому, что проблема излишней абстракции не рассматривается вами как проблема.
Один уровень абстракции - это избавление от гемороя во время правок.
Излишняя абстракция - это когда, в каскаде вложенных классов трудно найти источник данных и непонятно что с данными происходит.
Тут речь идет об одном слое-адаптере.
Re: Cобытие Model::EVENT_ON_LOAD
а, ну да, такое бывает в программировании. Но "излишняя абстракция" это про запутанность слоев абстракции, а не про их кол-во в проекте. Или предлагаешь, пользуясь yii, больше не вводить дополнительных сущностей? Типа вот AR-модель, вот вьюшка, а все остальное излишне?Sam Dark писал(а):Не одном, а ещё одном.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Cобытие Model::EVENT_ON_LOAD
Нет. Я всего-лишь к тому, что это может стать проблемой. Не совсем правильно утверждать, что это единственно верный способ, а всё остальное — нет. У каждого свой уровень восприятия абстракции. Кому-то нормально когда всё очень слоёное, а кому-то это не даёт нормально дебажить и читать код. У кого-то возникает желание всё заабстрагировать превентивно, а у кого-то наоборот, не городить пока не припечёт. Причём и в том и в том случае встречаются как успешно делающие большие сложные проекты, так их и успешно заваливающие.
Так что надо именно для себя, своего проекта и своей команды взвесить все за и против и делать так, как лучше в конкретной ситуации.
Так что надо именно для себя, своего проекта и своей команды взвесить все за и против и делать так, как лучше в конкретной ситуации.
Нравится Yii? Давайте сделаем его лучше!.
Re: Cобытие Model::EVENT_ON_LOAD
ну мне очевидно, что если модель и вьюшка общаются через один адаптер со скалярами, не обладающий собственным поведением, то профитов здесь больше чем, в случае передачи чего угодно в любом кол-ве. Это дисциплинирует и не дает во вьюшке испортить код.Sam Dark писал(а):Нет. Я всего-лишь к тому, что это может стать проблемой. Не совсем правильно утверждать, что это единственно верный способ, а всё остальное — нет. У каждого свой уровень восприятия абстракции. Кому-то нормально когда всё очень слоёное, а кому-то это не даёт нормально дебажить и читать код. У кого-то возникает желание всё заабстрагировать превентивно, а у кого-то наоборот, не городить пока не припечёт. Причём и в том и в том случае встречаются как успешно делающие большие сложные проекты, так их и успешно заваливающие.
Так что надо именно для себя, своего проекта и своей команды взвесить все за и против и делать так, как лучше в конкретной ситуации.
А довод "делать так, как лучше в конкретной ситуации" - не довод против обсуждения подходов.
Последний раз редактировалось zelenin 2016.03.03, 15:32, всего редактировалось 1 раз.
- samdark
- Администратор
- Сообщения: 9489
- Зарегистрирован: 2009.04.02, 13:46
- Откуда: Воронеж
- Контактная информация:
Re: Cобытие Model::EVENT_ON_LOAD
Ну я и не спорю, что плюс имеется.
Нравится Yii? Давайте сделаем его лучше!.
Re: Cобытие Model::EVENT_ON_LOAD
Это и есть по определению хелпер, разве нет?адаптер со скалярами, не обладающий собственным поведением,
UPD. Хотя нет, хелпер не принимает инстанс модели в конструктор, таким образом он более универсальный. С помощью одного метода форматирования даты можно выводить дату абсолютно любой модели, а не только конкретно той, для которой создается ViewModel класс
Yii Jabber Conference: yii@conference.jabber.ru
Re: Cобытие Model::EVENT_ON_LOAD
хелпер в твоем понимании - это то, что может использоваться внутри адаптера. а может и не использоваться. Я скорее о подходе, а не месте, где форматировать строку.R3D3 писал(а):Это и есть по определению хелпер, разве нет?адаптер со скалярами, не обладающий собственным поведением,
UPD. Хотя нет, хелпер не принимает инстанс модели в конструктор, таким образом он более универсальный. С помощью одного метода форматирования даты можно выводить дату абсолютно любой модели, а не только конкретно той, для которой создается ViewModel класс
Re: Cобытие Model::EVENT_ON_LOAD
Ну форматирование вывода в модели точно не должно происходить, с этим вроде все согласны. А вот при выборе между статическим классом-хелпером и DTO, обладающим состоянием, я выберу скорее статический класс-хелпер. Потому что, например, если надо отформатировать дату у 1000 моделей, то что, на каждую модель создавать свой DTO ?
Кстати, в твиге как раз используются статические хелперы, просто они так красиво встроены в синтаксис, что пользоваться ими приятней чем создавать форматирующие объекты.
Кстати, в твиге как раз используются статические хелперы, просто они так красиво встроены в синтаксис, что пользоваться ими приятней чем создавать форматирующие объекты.
Yii Jabber Conference: yii@conference.jabber.ru
Re: Cобытие Model::EVENT_ON_LOAD
Почему бы автору ни добавить свой формат в Formatter для использования напрямую:
или в гриде:
Код: Выделить всё
<?= Yii::$app->formatter->format($model->value, 'myFormat') ?>
Код: Выделить всё
'columns' => [
'id',
'created_at:datetime',
'value:myFormat',
]