думаю все исходит в первую очередь из стоящих задач

после уже выбирается способ реализации

все пилят getStatus() потому что какой-то умник на стаковерфлоу так написал, и все побежали повторять )

все пилят getStatus() потому что какой-то умник на стаковерфлоу так написал, и все побежали повторять )

Чего за шум снова?

Чего за шум снова?

да нет никакого шума, учат говнокодить тут )

Прям как ты вчера

Но сегодня ты сам не свой ?

пернатые на запах говна слетаются )

правильнее будет хранить в enum тектстовые статусы

ну так там и хранятся если их немного а если много тогда в базе

пернатые на запах говна слетаются )

Ну как обычно ты уже там

ну так там и хранятся если их немного а если много тогда в базе

а enum чо не в базе хранится?

а enum чо не в базе хранится?

имеется в виду файл енум с константами и методами возвращающими тектовый вариант их скажем так

имеется в виду файл енум с константами и методами возвращающими тектовый вариант их скажем так

дай пример

выглядит как говно какое-то

нах?

чтоб понять что ты хочешь скзаать

я ничего не хочу сказать пытался Борису объяснить

Объясни на примере что такое enum в файле.

у меня такая хрень присутствует на проекте class ArticleStatusEnum extends base\Enumerable { const ACTIVE = 1; const MODERATE = 2; const DELETED = 0; public static $list = [ self::ACTIVE => 'Активная', self::MODERATE => 'ОжидаетМодерацию', self::DELETED => 'Удаленная', ]; public static function listData($exclude = array()) { $list = self::$list; foreach ($exclude as $item) { unset($list[$item]); } return $list; } }

раньше тоже таким говном страдал кстати )

че дали с тем и работаем

какие-то отдельные классы для статусов... какая хуйня же это все )

какие-то отдельные классы для статусов... какая хуйня же это все )

Хэлпер жи.

https://github.com/ElisDN/yii2-demo-shop/blob/master/shop/helpers/UserHelper.php

Как по мне весьма удобно.

Хэлпер жи.

да дерьмо мусорное )

https://github.com/ElisDN/yii2-demo-shop/blob/master/shop/helpers/UserHelper.php

че то похожее но свое самописное

это один из многих примеров

максимум что можно вынести константы в интерфейс модели )

если такие кто-то делает :D

у еслисеева просто грамотней написоно что ли

у еслисеева просто грамотней написоно что ли

Без сторонних классов как у тебя (если правильно понял)

вот смори. делаешь ты такой обработчик формы

у еслисеева просто грамотней написоно что ли

у него DDD там

через конструктор напряму или через DI запускаешь туда модель свою AR, через ее интерфейс

к примеру

и следом тянешь ебеный статус )

потому что он там нужен. Статус имею в виду класс

щас накидаю пирмерный пример

https://pastebin.com/WqUQFWya

как-то так

$article = new Article(); // или Article::findOne($id) // или подтянуть ее откуда-то еще. $form = new ExampleForm($model); в контроллере

Ну и в чем шибко разница?

в гибкости

но ты вероятно не поймешь

Ну я не один в чатике

Другие поймут

Щито? Каокой save() в форме?

Кроме гипотетической возможности наследоваться не вижу никаких преимуществ

какой то пиздец

$this->article->setTitle($title); $this->article->setStatus(ArticleStatusEnum::CREATED); // и вот тут ты тащишь свой вонючий класс. //$this->article->setStatus(ArticleInterface::STATUS_CREATED); // а мог вот так $this->article->save(); Щито? Какой setStatus? ты при сохранении каждый раз маслаешь руками поля?

С формы пришел status=0|1|10|30|etc ты его и пишеш в БД жи, не?

Кроме гипотетической возможности наследоваться не вижу никаких преимуществ

преимущества увидишь при рефакторинге. инфа сотка

Блэт, а почему не сделать setStatusActive()|setStatusDelete|etc и не дрюкать моск?

$this->article->setTitle($title); $this->article->setStatus(ArticleStatusEnum::CREATED); // и вот тут ты тащишь свой вонючий класс. //$this->article->setStatus(ArticleInterface::STATUS_CREATED); // а мог вот так $this->article->save(); Щито? Какой setStatus? ты при сохранении каждый раз маслаешь руками поля?

пример условный. естесно статусы могут меняться при апдейтах, например

Блэт, а почему не сделать setStatusActive()|setStatusDelete|etc и не дрюкать моск?

Если статус сам ставишь, а не приходить откуда-то, тогда его и не должно быть в форме ввода.

Форму не должно жи волновать с каким статусом пришли данные

ее задача их принять и валидировать, все

Если статус сам ставишь, а не приходить откуда-то, тогда его и не должно быть в форме ввода.

статус может быть в форме ввода, при создании статей он как правило бывает "опубликовано" например

при апдейте тоже есть. ты просто придираешься к какой-то хуйне

lol, ну ок

Если статус сам ставишь, а не приходить откуда-то, тогда его и не должно быть в форме ввода.

принял, валидировал. что дальше?

ERROR: S client not available

куда ты отдашь данные эти?

в репозиторий

но сначала в сервис

каким образом?

репозиторий как я понимаю заинжектишь в форму? или просто вернешь данные с формы?

form->service->repository->entity в БД

продлжай )

в ентити будешь че писать нет? )

Жара

ваще

ога

ты либо достанешь с репо этот ентити при обновлении

либо создашь новый и добавишь потом в репо

каким хуем это имеет разницу между твоими домыслами и моим примером?

тем что

да нет никакого шума, учат говнокодить тут )

просто смотри

с формы пришел статус, как ты будешь выбирать какой метод использовать?

типа $entity->setStatusDeleted()

из твоего же примера

С формы пришел status=0|1|10|30|etc ты его и пишеш в БД жи, не?

свитч кейс? )

как ты его писать будешь? с формы в объект?

if ($form->status === 'deleted') $entity->setStatusDeleted(); вот так ты будешь писать

угадал?

nope

ну твой же пример

читать между строк это мощно

отлистай назад на первые сообщения и прочти внимательно

ты просто нихуя не понял, натянул это на свое мировоззрение и возмутился

ога)