Cобытие Model::EVENT_ON_LOAD

[andrei.obuhovski]

http://symfony.com/blog/new-in-symfony- ... figuration
На симфони тоже учат говнокодить)

Имхо, хелпер в виде проще и понятнее.

[zelenin]

http://symfony.com/blog/new-in-symfony- ... figuration
На симфони тоже учат говнокодить)

ты просто не понимаешь, что я пишу. Как раз по ссылке все правильно - отображением занимается вьюшка, а не не модель.

Имхо, хелпер в виде проще и понятнее.

вьюмодель и есть хелпер. Только в классическом и практическом виде.

[SiZE]

Имхо, хелпер в виде проще и понятнее.

вьюмодель и есть хелпер. Только в классическом и практическом виде.

Наверное он имел ввиду что там хелпер форматирования в ядре и исользуется такая конструкция:

Код: Выделить всё

\HtmlView::formatDate($model->date_created);

Вместо указанной тобой.

На самом деле это тоже наглядно. По поводу дублирования кода при использовании такого хелпера, это получится, как в анекдоте:

Чтобы вступить в рукопашный бой, боец спецназа должен:

1) Потерять на поле боя автомат, пистолет, нож, поясной ремень, лопатку, бронежилет, каску.
2) Найти ровную площадку на которой не валяется ни одного камня или палки.
3) Найти на ней такого же распиздяя.

Если перефразировать, то он должен не знать структуры проекта, проект не задокументирован, никто не делает код ревью и тп...

[andrei.obuhovski]

ты просто не понимаешь, что я пишу

Возможно. Давай на конкретном примере.

Я так понял предлагаешь использовать это:
Контроллер:

Код: Выделить всё

$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 со вставками

[zelenin]

как мы видим, ты преобразуешь данные во вьюшке, вместо того, чтобы форматирование инкапсулировать где-то. Плюс ты имеешь возможность во вьюшке прямой доступ к модели, можешь ее даже изменить, что подталкивает тебя и других разработчиков говнокоднуть.

$date = DateTimeHeper::formatDate($model->date); = $date = $viewModel->getDate(); практически без оверхеда.
И во втором случае ты все форматирование инкапсулируешь в одном классе, который выступает адаптером между моделью и вьюшкой, передавая во вьюшку только безопасные скаляры, не обладающие поведением. Плюс все данные для вьюшки у тебя В ОДНОМ МЕСТЕ. Править тебе надо в одном месте, добавлять поля в одном месте. Мы получаем чистую вьюшку вместо вьюшки на 5000 строк, где переменная $title в самом начале не равна переменной $title в самом конце, потому что где-то в середине ее изменили.

Неужели не очевидны плюсы такого подхода? Неужели не понятно, что удобно группировать логику преобразования переменных в одном месте вместо разброса преобразований в вбольшой вьюшке? Это удобнее для программиста и безопаснее для проекта - меньше шанса наговнокодить.

[SiZE]

Неужели не очевидны плюсы такого подхода? Неужели не понятно, что удобно группировать логику преобразования переменных в одном месте

$date = $viewModel->getDate();

ну только если все равно создавать базовый класс baseViewModel, в котором можно назначить:

Код: Выделить всё

public function getDate(){
   return '<div class="date">'.$this->date_created.'</div>';
} 

чтобы потом не искать все viewModel для правки.

[zelenin]

зачем искать все viewModel для правки? ViewModel уникален для каждой вьюшки.

[samdark]

Плюсы-то очевидны. Но и минусы тоже...

[zelenin]

Плюсы-то очевидны. Но и минусы тоже...

мне - нет.

[samdark]

Это потому, что проблема излишней абстракции не рассматривается вами как проблема.

[zelenin]

Это потому, что проблема излишней абстракции не рассматривается вами как проблема.

один уровень абстракции - это не излишняя абстракция.
Один уровень абстракции - это избавление от гемороя во время правок.
Излишняя абстракция - это когда, в каскаде вложенных классов трудно найти источник данных и непонятно что с данными происходит.
Тут речь идет об одном слое-адаптере.

[samdark]

Не одном, а ещё одном.

[zelenin]

Не одном, а ещё одном.

а, ну да, такое бывает в программировании. Но "излишняя абстракция" это про запутанность слоев абстракции, а не про их кол-во в проекте. Или предлагаешь, пользуясь yii, больше не вводить дополнительных сущностей? Типа вот AR-модель, вот вьюшка, а все остальное излишне?

[samdark]

Нет. Я всего-лишь к тому, что это может стать проблемой. Не совсем правильно утверждать, что это единственно верный способ, а всё остальное — нет. У каждого свой уровень восприятия абстракции. Кому-то нормально когда всё очень слоёное, а кому-то это не даёт нормально дебажить и читать код. У кого-то возникает желание всё заабстрагировать превентивно, а у кого-то наоборот, не городить пока не припечёт. Причём и в том и в том случае встречаются как успешно делающие большие сложные проекты, так их и успешно заваливающие.

Так что надо именно для себя, своего проекта и своей команды взвесить все за и против и делать так, как лучше в конкретной ситуации.

[zelenin]

Нет. Я всего-лишь к тому, что это может стать проблемой. Не совсем правильно утверждать, что это единственно верный способ, а всё остальное — нет. У каждого свой уровень восприятия абстракции. Кому-то нормально когда всё очень слоёное, а кому-то это не даёт нормально дебажить и читать код. У кого-то возникает желание всё заабстрагировать превентивно, а у кого-то наоборот, не городить пока не припечёт. Причём и в том и в том случае встречаются как успешно делающие большие сложные проекты, так их и успешно заваливающие.

Так что надо именно для себя, своего проекта и своей команды взвесить все за и против и делать так, как лучше в конкретной ситуации.

ну мне очевидно, что если модель и вьюшка общаются через один адаптер со скалярами, не обладающий собственным поведением, то профитов здесь больше чем, в случае передачи чего угодно в любом кол-ве. Это дисциплинирует и не дает во вьюшке испортить код.

А довод "делать так, как лучше в конкретной ситуации" - не довод против обсуждения подходов.

[samdark]

Ну я и не спорю, что плюс имеется.

[R3D3]

адаптер со скалярами, не обладающий собственным поведением,

Это и есть по определению хелпер, разве нет?

UPD. Хотя нет, хелпер не принимает инстанс модели в конструктор, таким образом он более универсальный. С помощью одного метода форматирования даты можно выводить дату абсолютно любой модели, а не только конкретно той, для которой создается ViewModel класс

[zelenin]

адаптер со скалярами, не обладающий собственным поведением,

Это и есть по определению хелпер, разве нет?

UPD. Хотя нет, хелпер не принимает инстанс модели в конструктор, таким образом он более универсальный. С помощью одного метода форматирования даты можно выводить дату абсолютно любой модели, а не только конкретно той, для которой создается ViewModel класс

хелпер в твоем понимании - это то, что может использоваться внутри адаптера. а может и не использоваться. Я скорее о подходе, а не месте, где форматировать строку.

[R3D3]

Ну форматирование вывода в модели точно не должно происходить, с этим вроде все согласны. А вот при выборе между статическим классом-хелпером и DTO, обладающим состоянием, я выберу скорее статический класс-хелпер. Потому что, например, если надо отформатировать дату у 1000 моделей, то что, на каждую модель создавать свой DTO ?

Кстати, в твиге как раз используются статические хелперы, просто они так красиво встроены в синтаксис, что пользоваться ими приятней чем создавать форматирующие объекты.

[ElisDN]

Почему бы автору ни добавить свой формат в Formatter для использования напрямую:

Код: Выделить всё

<?= Yii::$app->formatter->format($model->value, 'myFormat') ?>

или в гриде:

Код: Выделить всё

'columns' => [
    'id',
    'created_at:datetime',
    'value:myFormat',
]