Комментарии 28
если честно не понимаю в чем соль статьи, вы по сути пересказали документацию.
p.s. не увидел принципиальных отличий с первой веткой.
p.s. не увидел принципиальных отличий с первой веткой.
Немножко замечаний по коду
можно упростить до
Так вот эта сложная мешанина из атрибутов хотя бы дублироваться не будет.
и уж никак это не getSlug, ибо метод ничего не возвращает. Это скорее processSlug.
Да и вообще сомнительная логика с разными атрибутами…
if ( empty( $this->owner->{$this->out_attribute} ) ) {
$this->owner->{$this->out_attribute} = $this->generateSlug( $this->owner->{$this->in_attribute} );
} else {
$this->owner->{$this->out_attribute} = $this->generateSlug( $this->owner->{$this->out_attribute} );
}
можно упростить до
$attr = empty( $this->owner->{$this->out_attribute}) ?
$this->in_attribute : $this->out_attribute;
$this->owner->{$this->out_attribute} = $this->generateSlug( $this->owner->{$attr} );
Так вот эта сложная мешанина из атрибутов хотя бы дублироваться не будет.
и уж никак это не getSlug, ибо метод ничего не возвращает. Это скорее processSlug.
Да и вообще сомнительная логика с разными атрибутами…
Новичкам будет полезно однозначно.
Чем больше разжеванных примеров, тем лучше.
Чем больше разжеванных примеров, тем лучше.
Лучше бы в качестве примера реализовали что-то более полезное (meta-информация для постов, кеширование и очистка кеша при изменении данных, сериализация массивов/объектов, отправка имейлов по сохранению/изменению… Ибо из статьи они не поймут главного — зачем вообще нужны бихейверы. Этот пример плохо иллюстрирует то, что они создаются для уменьшения дублирования кода.
По-моему, все, что вы предложили в качестве полезного, не больше проиллюстрирует, а может и меньше (отправка имейлов? очистка кэша?).
Из статьи понятно, что мы можем подключить это поведение теперь к любой модели прописыванием 4 строк, не дублируя больше никакой код.
Тем не менее, ваше мнение принял.
Из статьи понятно, что мы можем подключить это поведение теперь к любой модели прописыванием 4 строк, не дублируя больше никакой код.
Тем не менее, ваше мнение принял.
НЛО прилетело и опубликовало эту надпись здесь
А почему бы не реализовать тот же функционал в виде trait, раз уж задача избавиться от дублирования кода?
А в чем преимущество трейтов?
Тут у меня скорее вопрос: в чем преимущество behavior?
Для себя в trait вижу только минусы (общая статичность, нетестируемость отдельно от класса), но в контексте задачи статьи не смог понять, чем предложенное решение лучше. Возможно это из-за ограниченности моего опыта разработки на Yii.
Для себя в trait вижу только минусы (общая статичность, нетестируемость отдельно от класса), но в контексте задачи статьи не смог понять, чем предложенное решение лучше. Возможно это из-за ограниченности моего опыта разработки на Yii.
Бихейверы в yii появились с первых версий, и они вписываются в концепцию фреймворка (все на магии). Православно было бы использовать композицию и декораторы, но это существенно увеличивает количество кода да и смысла для подобной задачи нету. Собственно я считаю что и бихейвер для подобного делать не нужно.
Ближе к делу. Комментарии не только для того, чтобы критиковать статью, но и предлагать лучшие решения. Не бихейвиор, тогда что?
Вот более конкретное сравнение github.com/drcypher/php-trait-vs-yii-behavior
В данном случае трейт и бихейвиор будут выполнять одно и то же. Но в общем… Хотя зачем пересказывать, дискуссия на эту тему уже была github.com/yiisoft/yii2/issues/1053
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, но я бы проверку на уникальность обернул бы в цикл без ифов.
>Если кто может предложить лучшее решение, буду благодарен.
Дописать в конец primaryKey.
Где-то видел универсальное решение, /slug-id/, и поиск entity прямо по ид.
Дописать в конец primaryKey.
Где-то видел универсальное решение, /slug-id/, и поиск entity прямо по ид.
то есть testovaya-novost-969 (при id = 969)? Это конечно вариант, и он используется в некоторых решениях (в Joomla по-моему), но не такой красивый. Хотя, сравнивая testovaya-novost-2 и testovaya-novost-969, большой разницы не вижу.
С другой стороны для вашего варианта все равно придется делать два запроса — для testovaya-novost, а потом для testovaya-novost-969. А вероятность, что будет более двух записей с одним заголовком, достаточно мала для большинства проектов, чтобы экономить на спичках.
С другой стороны для вашего варианта все равно придется делать два запроса — для testovaya-novost, а потом для testovaya-novost-969. А вероятность, что будет более двух записей с одним заголовком, достаточно мала для большинства проектов, чтобы экономить на спичках.
конечно поведение уже написано и находится в пакете yii2, но все же отпишусь:
1. автору явно надо почитать про оптимизацию, а конкретно в данном случае:
лучше юзать count()
2. если вы в owner модели перекрыли метод find, к примеру так
то расширение удалит условие установленное в перекрытом методе, что делает потенциально опасным применение данного поведения. Решение заменить where на andWhere
1. автору явно надо почитать про оптимизацию, а конкретно в данном случае:
return !$this->owner->find()
->where( $condition, $params )
->one();
лучше юзать count()
2. если вы в owner модели перекрыли метод find, к примеру так
public static function find()
{
return parent::find()->andWhere(['status' => 'public']);
}
то расширение удалит условие установленное в перекрытом методе, что делает потенциально опасным применение данного поведения. Решение заменить where на andWhere
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создаем поведение (behavior) для Yii2