Pull to refresh

Comments 28

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

p.s. не увидел принципиальных отличий с первой веткой.
Немножко замечаний по коду
        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 строк, не дублируя больше никакой код.
Тем не менее, ваше мнение принял.
вы забыли про: добавить поле, добавить его в правила валидации… причем это правило будет дублировать логику в вашем поведении (проверка на уникальность).
Это нужно делать в не зависимости от подключения поведения.
UFO just landed and posted this here
А почему бы не реализовать тот же функционал в виде trait, раз уж задача избавиться от дублирования кода?
А в чем преимущество трейтов?
Тут у меня скорее вопрос: в чем преимущество behavior?
Для себя в trait вижу только минусы (общая статичность, нетестируемость отдельно от класса), но в контексте задачи статьи не смог понять, чем предложенное решение лучше. Возможно это из-за ограниченности моего опыта разработки на Yii.
Бихейверы в yii появились с первых версий, и они вписываются в концепцию фреймворка (все на магии). Православно было бы использовать композицию и декораторы, но это существенно увеличивает количество кода да и смысла для подобной задачи нету. Собственно я считаю что и бихейвер для подобного делать не нужно.
Ближе к делу. Комментарии не только для того, чтобы критиковать статью, но и предлагать лучшие решения. Не бихейвиор, тогда что?
В данном случае трейт и бихейвиор будут выполнять одно и то же. Но в общем… Хотя зачем пересказывать, дискуссия на эту тему уже была github.com/yiisoft/yii2/issues/1053
UFO just landed and posted this here
Спасибо, но я бы проверку на уникальность обернул бы в цикл без ифов.
$slug=$base=translit($model->{$this->slugAttribute});
$suffix=0;
while(!$this->checkUniqueSlug( $slug )) $slug=$base.++$suffix;
return $slug;

Примерно так, писал на коленке.
разве в таком варианте слаг будет типа slug, slug-2, slug-3?
Ну если добавить к конкатенации тире, то да!
Я имею в виду, что будет slug-1, а он и не нужен, так как префикс должен нести смысловую нагрузку — количество одинаковых слагов
>Если кто может предложить лучшее решение, буду благодарен.
Дописать в конец primaryKey.
Где-то видел универсальное решение, /slug-id/, и поиск entity прямо по ид.
то есть testovaya-novost-969 (при id = 969)? Это конечно вариант, и он используется в некоторых решениях (в Joomla по-моему), но не такой красивый. Хотя, сравнивая testovaya-novost-2 и testovaya-novost-969, большой разницы не вижу.
С другой стороны для вашего варианта все равно придется делать два запроса — для testovaya-novost, а потом для testovaya-novost-969. А вероятность, что будет более двух записей с одним заголовком, достаточно мала для большинства проектов, чтобы экономить на спичках.
Лучше всего в таких случаях добавлять id в начаало или конец slugа, прописать правило разбора в routing и делать выборку из базы по id
Это позволит в дальнейшем при изменении sluga (часто сеошники любят их менять) сделать в контроллере автоматическую коррекцию url с 301 редиректом на новые ссылки
конечно поведение уже написано и находится в пакете yii2, но все же отпишусь:
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
Only those users with full accounts are able to leave comments. Log in, please.