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

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

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

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

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

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

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

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

php
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(), який автоматично викликається після успішного збереження запису у БД.

php
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.