Авто-генерируемые модели в виде 2 файлов ActiveRecord

[mj4444]

Я не ради флейма. Я почему уточнял что в вашем варианте в БД хранится - я просто привык\люблю\считаю правильным хранить числовой идентификатор для подобных вещей. В int-овом поле (уменьшенном, например tiny\small Int (3)). Где только не работал - везде были споры на тему - число в инт поле, либо идентификатор в енум\сет полях. И для меня самый удобный вариант, предложенный ранее

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

public static function getStatus($id = null)
    {
        $statuses = [
            self::STATUS_ACTIVE => Module::t('Active'),
            self::STATUS_INACTIVE => Module::t('Inactive'),
            self::STATUS_BANNED => Module::t('Banned')
        ];
        if ($id !== null) {
            return ArrayHelper::getValue($statuses, $id, null);
        }
        return $statuses;
    } 

так же еще его можно дополнить параметром - $keysOnly - при нужде выводить только ключи (в нашем случае валидный перечень статусов) и использовать массив ключей для валидации. Но обычно чтоб не нагружать функцию параметрами использую array_keys() для результата функции.

Тут обсуждается автогенератор которые берёт данные из базы... Если вы любите писать всё в ручную, причём тут автогенератор кода?
Вы можете расширять возможности модели во втором классе формы...
Но поверьте, хранить в виде чисел это лишь привычка и ничего удобного в этом нет...

про $keysOnly вы сами же и ответили как надо...

[mj4444]

кстати еще бывают ситуации, когда в зависимости от ситуации используются не все а только определенные статусы (админ редактирует новость или обычный редактор?). Это всё я к тому, что это всё лучше и правильнее делать руками сразу. Валидацию автогенерируемую толковую не сделаешь, увы.

Автогенерируемые правила валидации проверяют данные на соответствие базе данных...
Для ваших целей вы можете дополнять валидаторы во втором классе и/или использовать сценарии... И вообще может этим стоит заняться моделе формы?

[mj4444]

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

"принятых в большинстве приложений" - часто трудно вас понять... Думаю php тоже часто не понимает ваш копипаст...
Слишком часто мне приходиться исправлять ошибки копипастеров, может когда нить вы поймёте все прелести gii, баз данных и вообще автогенерации кода...

[zelenin]

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

"принятых в большинстве приложений" - часто трудно вас понять... Думаю php тоже часто не понимает ваш копипаст...
Слишком часто мне приходиться исправлять ошибки копипастеров, может когда нить вы поймёте все прелести gii, баз данных и вообще автогенерации кода...

очень достойный ответ

[mj4444]

На данном этапе отличия от стандартного генератора:

- Дополнительный класс модели для пользовательского кода
- Автогенерация валидаторов для значений по умолчанию
- Автогенерация валидаторов для полей enum (возможно частичное/полное отключение)
- Автогенерация констант для полей enum и set
- Автогенерация behaviors для моделей содержащих поля обрабатываемые TimestampBehavior
- Таблица 'migration' исключается из автогенерации (настраивается)
- Возможно настроить список игнорируемых таблиц
- Полностью переработано создание имён для связей