Создаем поведение (behavior) для Yii2

[Fesor]

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

p.s. не увидел принципиальных отличий с первой веткой.

[Fesor]

Немножко замечаний по коду

        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.
Да и вообще сомнительная логика с разными атрибутами…

[zelenin]

упрощение принято. А в чем сомнительность логики?

[zelenin]

Новичкам будет полезно однозначно.
Чем больше разжеванных примеров, тем лучше.

[Fesor]

Лучше бы в качестве примера реализовали что-то более полезное (meta-информация для постов, кеширование и очистка кеша при изменении данных, сериализация массивов/объектов, отправка имейлов по сохранению/изменению… Ибо из статьи они не поймут главного — зачем вообще нужны бихейверы. Этот пример плохо иллюстрирует то, что они создаются для уменьшения дублирования кода.

[zelenin]

По-моему, все, что вы предложили в качестве полезного, не больше проиллюстрирует, а может и меньше (отправка имейлов? очистка кэша?).
Из статьи понятно, что мы можем подключить это поведение теперь к любой модели прописыванием 4 строк, не дублируя больше никакой код.
Тем не менее, ваше мнение принял.

[Fesor]

вы забыли про: добавить поле, добавить его в правила валидации… причем это правило будет дублировать логику в вашем поведении (проверка на уникальность).

[zelenin]

Это нужно делать в не зависимости от подключения поведения.

[zloyusr]

А почему бы не реализовать тот же функционал в виде trait, раз уж задача избавиться от дублирования кода?

[Fesor]

А в чем преимущество трейтов?

[zloyusr]

Тут у меня скорее вопрос: в чем преимущество behavior?
Для себя в trait вижу только минусы (общая статичность, нетестируемость отдельно от класса), но в контексте задачи статьи не смог понять, чем предложенное решение лучше. Возможно это из-за ограниченности моего опыта разработки на Yii.

[Fesor]

Бихейверы в yii появились с первых версий, и они вписываются в концепцию фреймворка (все на магии). Православно было бы использовать композицию и декораторы, но это существенно увеличивает количество кода да и смысла для подобной задачи нету. Собственно я считаю что и бихейвер для подобного делать не нужно.

[zelenin]

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

[zelenin]

Вот более конкретное сравнение github.com/drcypher/php-trait-vs-yii-behavior

[zelenin]

В данном случае трейт и бихейвиор будут выполнять одно и то же. Но в общем… Хотя зачем пересказывать, дискуссия на эту тему уже была github.com/yiisoft/yii2/issues/1053

[Ekstazi]

Спасибо, но я бы проверку на уникальность обернул бы в цикл без ифов.

[zelenin]

пример можно

[Ekstazi]

$slug=$base=translit($model->{$this->slugAttribute});
$suffix=0;
while(!$this->checkUniqueSlug( $slug )) $slug=$base.++$suffix;
return $slug;

Примерно так, писал на коленке.

[zelenin]

разве в таком варианте слаг будет типа slug, slug-2, slug-3?

[Ekstazi]

Ну если добавить к конкатенации тире, то да!

[zelenin]

Я имею в виду, что будет slug-1, а он и не нужен, так как префикс должен нести смысловую нагрузку — количество одинаковых слагов

[WorksIsGone]

>Если кто может предложить лучшее решение, буду благодарен.
Дописать в конец primaryKey.
Где-то видел универсальное решение, /slug-id/, и поиск entity прямо по ид.

[zelenin]

то есть testovaya-novost-969 (при id = 969)? Это конечно вариант, и он используется в некоторых решениях (в Joomla по-моему), но не такой красивый. Хотя, сравнивая testovaya-novost-2 и testovaya-novost-969, большой разницы не вижу.
С другой стороны для вашего варианта все равно придется делать два запроса — для testovaya-novost, а потом для testovaya-novost-969. А вероятность, что будет более двух записей с одним заголовком, достаточно мала для большинства проектов, чтобы экономить на спичках.

[k_sashka]

Лучше всего в таких случаях добавлять id в начаало или конец slugа, прописать правило разбора в routing и делать выборку из базы по id
Это позволит в дальнейшем при изменении sluga (часто сеошники любят их менять) сделать в контроллере автоматическую коррекцию url с 301 редиректом на новые ссылки

[oknimdy]

конечно поведение уже написано и находится в пакете 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

[oknimdy]

1. exist()