Створення та редагування записів

Після того, як ми закінчили із моделлю Post, займемося контролером PostController і його відображеннями. У даному розділі ми налаштуємо правила доступу операцій CRUD. Потім змінимо код, відповідальний за створення (create) та оновлення (update).

Налаштування правил доступу

Перше, що ми запланували - налаштування прав доступу. Код, згенерований за допомогою gii, нам не підійде.

Необхідно змінити метод accessRules() у файлі /wwwroot/blog/protected/controllers/PostController.php наступним чином:

public function accessRules()
{
    return array(
        array('allow',  // дозволяє всім користувачам виконувати дії 'list' та 'show'
            'actions'=>array('index', 'view'),
            'users'=>array('*'),
        ),
        array('allow', // дозволяє аутентифікованим користувачам виконувати будь-які дії
            'users'=>array('@'),
        ),
        array('deny',  // забороняє всім користувачам
            'users'=>array('*'),
        ),
    );
}

Описані вище правила дозволяють всім користувачам виконувати дії index та view. Аутентифікованим - будь-які дії, включаючи admin. Всім іншим користувачам заборонено все. Варто відзначити, що правила застосовуються у порядку їх опису. Перше правило, що спрацювало, визначає, давати доступ або не давати. Наприклад, якщо поточний користувач є власником системи та намагається зайти на сторінку створення запису, буде застосовано друге правило і доступ буде дозволений.

Правки у діях create та update

Операції create та update досить схожі. У обох випадках необхідно вивести HTML форму для збору даних, що вводяться користувачем. Також потрібна валідація та збереження даних у БД. Головна відмінність у тому, що при update форма буде заповнюватися даними запису, що редагується. З цієї причини gii генерує вкладене відображення /wwwroot/blog/protected/views/post/_form.php, яке включається як у відображення 'create', так і відображення 'update' для виводу HTML форми.

Для початку змінимо файл _form.php таким чином, щоб форма збирала тільки потрібні нам дані: title, content, tags та status. Для перших трьох атрибутів ми використовуємо текстові поля. Для status - випадаючий список з усіма можливими станами запису:

<?php echo $form->dropDownList($model,'status',Lookup::items('PostStatus')); ?>

У наведеному коді для отримання списку статусів використовується виклик Lookup::items('PostStatus').

Далі змінимо клас Post таким чином, щоб він автоматично виставляв деякі атрибути (такі, як create_time та author_id) безпосередньо перед збереженням запису у БД. Перекриємо метод beforeSave():

protected function beforeSave()
{
    if(parent::beforeSave())
    {
        if($this->isNewRecord)
        {
            $this->create_time=$this->update_time=time();
            $this->author_id=Yii::app()->user->id;
        }
        else
            $this->update_time=time();
        return true;
    }
    else
        return false;
}

При збереженні запису ми хочемо також оновити інформацію про частоту використання тегів у таблиці tbl_tag. Ми можемо реалізувати це у методі afterSave(), який автоматично викликається після успішного збереження запису у БД.

protected function afterSave()
{
    parent::afterSave();
    Tag::model()->updateFrequency($this->_oldTags, $this->tags);
}
 
private $_oldTags;
 
protected function afterFind()
{
    parent::afterFind();
    $this->_oldTags=$this->tags;
}

Так як необхідно визначити, чи змінював користувач теги при редагуванні запису, нам знадобляться старі теги. Для цього ми реалізуємо метод afterFind(), який записує старі теги у властивість _oldTags. Метод afterFind() викликається автоматично при заповненні моделі AR даними, отриманими із БД.

Тут ми не будемо детально розглядати метод Tag::updateFrequency(). Зацікавлені читачі можуть ознайомитися із ним у файлі /wwwroot/yii/demos/blog/protected/models/Tag.php.