На мой взгляд, XML-RPC протокол является одним из наиболее удобных способов передачи данных между Интернет-ресурсами. Можно, конечно, поспорить, но на изучение XML-RPC требуется минимальное количество времени, есть множество готовых библиотек, да и используется он очень широко. Поэтому я никогда не понимал, почему разработчики отличного фреймворка Yii решили не включать библиотеку для работы с XML-RPC в дистрибутив. Хотя, возможно, это вопрос времени

Тем не менее, работать нужно уже сейчас, и в этой статье мы разберём, как решить проблему с помощью сторонних библиотек.

Примечание. Если вас интересует создание XML-RPC клиента, почитайте статью XML-RPC и Yii фреймворк.

Немного теории.

Мы можем использовать два основных подхода при создании XML-RPC сервера.

1) Отдельный скрипт. В этом случае создаём файл с именем вроде xmlrpc.php и помещаем его в корень сайта. В нём будет находиться код обработки XML-RPC запросов. Такой подход используется, например, в WordPress. Достоинство в том, что вам не нужно вносить никаких изменений в код вашего проекта, т.е. XML-RPC интерфейс получается независимым. С другой стороны, независимость приводит к тому, что вам будет гораздо сложнее работать со встроенными библиотеками фреймворка.

2) Использование действий контроллера. Этот вариант гораздо интереснее. Во-первых, вы автоматически получаете доступ ко всем возможностям Yii. Во-вторых, в этом случае XML-RPC методы можно разделить по модулям. Т.е. подключение / отключение модуля будет автоматически подключать / отключать соответствующие XML-RPC методы.

Т.к. реализация первого подхода никакой сложности не представляет (фактически вы можете использовать примеры из документации к вашей библиотеке для работы с XML-RPC), мы рассмотрим второй вариант.

Какие библиотеки можно использовать?

По большому счёту – любые, т.к. подключение сторонних библиотек к Yii выполняется без особых проблем. Я обычно использую библиотеку Incutio XML-RPC Library. Она достаточно простая, работает без проблем и, кроме того, используется в WordPress, а эта CMS используется очень часто.

Переходим к практике.

Шаг 1. Подключаем библиотеку.

Для этого скачиваем библиотеку и сохраняем файл IXR_Library.php в папку protected/vendors. Теперь подключить библиотеку можно так:

Yii::import('application.vendors.*');
require_once ('IXR_Library.php');

Этот код можно добавить в любое действие (action) контроллера.

Шаг 2. Создаём точку входа.

Как я уже говорил, в качестве точки входа мы используем действие контроллера. Код будет выглядеть примерно так:

class MyController extends Controller {
	...
	public function actionXmlrpc() {
		Yii::import('application.vendors.*');
		require_once ('IXR_Library.php');

		$server = new IXR_Server(array(
			'my.hello' => array($this,'hello'),
		));
	}
	...
}

В этом методе мы просто создаём объект типа IXR_Server, конструктору которого нужно передать массив с названиями XML-RPC методов. В данном случае в массиве только один элемент. Ключ этого элемента является названием XML-RPC метода, а значение – именем функции, которую нужно вызвать.

array($this,'hello') означает, что будет вызван метод hello данного контроллера.

Тут нужно помнить об одном нюансе. Обычно в XML-RPC запросах не передаются данные сессий. Логин и пароль отправляются в каждом запросе в качестве параметров. Поэтому необходимо, обеспечить доступ к методу actionXmlrpc() без авторизации. Для этого немного изменим метод accessRules

public function accessRules() {
	return array(
		array('allow',  // allow all users to perform 'index' and 'view' actions
			'actions'=>array('index','view','xmlrpc'),
			'users'=>array('*'),
		),
		…,
	);
}

Шаг 3. Добавляем методы.

Теоретически, можно ограничиться просто добавлением метода hello, который просто вернет «Hello, world!».

public function hello($args) {
	return 'Hello, world!';
}

Но в 99% нужно аутентифицировать пользователя. Добавим метод

protected function xmlrpcLogin($username, $password) {
	$identity = new UserIdentity($username, $password);
	$identity->authenticate();
	if ($identity->errorCode === UserIdentity::ERROR_NONE) {
		Yii::app()->user->login($identity, 0);
		return true;
	}
	else {
		return false;
	}
}

Здесь мы используем класс UserIdentity, который автоматически создаётся фреймворком Yii при создании приложения. В параметрах этого метода нужно передать логин и пароль. В случае успешной аутентификации метод вернёт TRUE, в противном случае – FALSE. Кроме того, данные пользователя будут доступны через Yii::app()->user, т.е. точно также как и при обычной работе с фреймворком.

Теперь перепишем код метода hello.

public function hello($args) {
	if (!$this->xmlrpcLogin($args[0], $args[1])) {
		return new IXR_Error(-1, 'You did not provide the correct password');
	}
return 'Hello, world!';
}

Здесь предполагается, что логин и пароль будут переданы в первом и втором параметрах XML-RPC запроса.

Шаг 4. Проверяем работу.

Для проверки достаточно создать обычный PHP скрипт со следующим кодом.

require_once ('IXR_Library.php');

$client = new IXR_Client('http://my_site.domen/my/xmlrpc');
$client->debug = true;

$args = array();
$args[0] = 'login';
$args[1] = 'password';

if (!$client->query('my.hello', $args)) {
    die('Something went wrong - '.$client->getErrorCode().' : '.$client->getErrorMessage());
}
echo $client->getResponse();

Как видите, создание XML-RPC сервера особой сложности не представляет. Конечно, самая сложная работа – это написание самих методов. Но не забывайте, что если у вас уже готов web интерфейс и логика по максимуму вынесена в модели, то вы сможете спокойно использовать её и в XML-RPC методах.

Успехов!

Полезная информация

Новогодний подарок от Inferno Solutions – всем новым клиентам панель ISP бесплатно и 30$ в подарок при заказе VPS в Германии, Украине или Голландии! Укажите при заказе в примечании ISP+30.

Постоянные читатели этого блога, наверное, помнят, что и о фреймворке Yii, и о сервисе аутентификации Loginza я раньше рассказывал. Найти эти статьи несложно: Yii, Loginza.

Но в статье о Loginza, речь шла о протоколе обмена данными с сервисом, а вопрос аутентификации остался «за бортом». Я, конечно, объяснил когда нужно создавать сессию, но на практике этого явно недостаточно

В этой статье я постараюсь исправить этот недостаток и покажу пример аутентификации пользователя с помощью сервиса Loginza.

Прежде всего, определим требования к такой системе.

1) Она не должна нарушать работу стандартной системы аутентификации (с использованием логина и пароля).

2) Должны поддерживаться стандартные средства Yii для работы с пользователями. Речь о компоненте Yii::app()->user (CWebUser).

3) Завершение сеанса (Yii::app()->user->logout()) должно работать независимо от того каким образом была выполнена аутентификация.

4) Если посетитель впервые зашел на сайт и успешно прошел аутентификацию с помощью Loginza, для него нужно автоматически создать аккаунт.

5) Нужна возможность удобно показывать ссылку «Войти с помощью Loginza» на любой странице сайта (виджет).

6) После аутентификации пользователь должен вернуться на исходную страницу.

Чтобы лучше представить фронт работ, рассмотрим алгоритм аутентификации фреймворка Yii.

1. Посетитель кликает по кнопке «Войти с помощью Loginza».

2. Появляется виджет в котором пользователь выбирает сервис аутентификации.

3. Loginza проводит аутентификацию и возвращает посетителя на наш сайт. При этом в массиве $_POST передается token, с помощью которого можно получить результаты аутентификации пользователя.

4. Наше приложение должно.

4.1. Получить данные от сервиса Loginza.

4.2. Создать пользователя (экземпляр класса, реализующий интерфейс IUserIdentity). Этот класс содержит метод authenticate в котором мы проверим, существует ли данный пользователь в БД, если нет – создадим его, и установим данные, которые необходимы для работы класса CWebUser.

4.3. Выполнить аутентификацию. Т.е. вызвать Yii::app()->user->login. При этом в первом параметре метода login мы передаем экземпляр класса, реализующего IUserIdentity (который мы создали на предыдущем этапе). Таким образом, мы обеспечим нормальную работу нашего класса со всеми остальными компонентами фреймворка.

Переходим к реализации.

Шаг 1. Создадим виджет, показывающий ссылку «Войти с помощью Loginza».

Он будет состоять из двух файлов:
1) protected/components/LoginzaWidget.php – класс виджета
2) protected/components/views/loginzaWidget.php – представление.

Рассмотрим класс виджета.

<?php
class LoginzaWidget extends CWidget {
	//параметры по-умолчанию
	private $params = array(
		'widget_url'=>'https://s3-eu-west-1.amazonaws.com/s1.loginza.ru/js/widget.js',
		'token_url'=>'https://loginza.ru/api/widget?token_url=',
		'return_url'=>'',
		'link_anchor'=>'Войти с помощью Loginza',
		'logout_url'=>'',
		'css_class'=>'loginza',
		'providers_set'=>array('vkontakte', 'facebook', 'twitter', 'loginza'
            , 'myopenid', 'webmoney', 'rambler', 'flickr', 'lastfm', 'openid'
            , 'mailru', 'verisign', 'aol', 'steam', 'google', 'yandex'
            , 'mailruapi'),
	);

	/**
	 * Этот метод подключает JS скрипт и загружает представление
	 */
    public function run() {
        //подключаем JS скрипт
        Yii::app()->clientScript->registerScriptFile(
				$this->params['widget_url']
                , CClientScript::POS_END);
        $this->render('loginzaWidget', $this->params);
    }

	/**
	 * Установка параметров
	 * @param array $params массив с параметрами
	 */
	public function setParams($params) {
		$this->params = array_merge($this->params, $params);
	}
}

Здесь мы создаем массив с дефолтными параметрами, в котором указываем настройки, необходимые для работы с сервисом Loginza. Подробно на них останавливаться не будем, т.к. они рассмотрены в предыдущей статье. Но обратите внимание, что обязательно нужно установить два параметра: return_url и logout_url.

В первом (return_url) нужно указать адрес, на который должен быть перенаправлен пользователь после аутентификации на Loginza.

Во втором (logout_url) – адрес метода, выполняющего завершение сессии.

Эти методы выполняют непосредственно аутентификацию пользователя в нашем приложении, и логично, что виджет о них ничего не знает.

Таким образом, подключить виджет можно так.

<?php  $this->widget('application.components.LoginzaWidget', array(
	'params'=>array(
		'return_url'=>'site/loginzalogin',
		'logout_url'=>'site/logout',
		'providers_set'=>array('google','vkontakte','facebook','twitter','rambler','openid','mailru','yandex','mailruapi'),
	),
)); ?>

В представлении (protected/components/views/loginzaWidget.php) мы проверяем, аутентифицирован ли пользователь и в зависимости от результата выводим ссылку «Войти с помощью Loginza» или «Выход».

<?php if (Yii::app()->user->isGuest) {
	$url = $token_url.Yii::app()->createAbsoluteUrl($return_url
			, array('providers_set'=>implode(',',$providers_set)));
	echo CHtml::link($link_anchor, $url, array('class'=>$css_class));
} else {
	$anchor = 'Выйти ('.Yii::app()->user->getName().')';
	echo CHtml::link($anchor, array($logout_url));
}
?>

Шаг 2. Напишем метод, выполняющий аутентификацию посетителя.

Я добавил этот метод в класс SiteController, который автоматически создается утилитой yiic при создании приложения.

public function actionLoginzaLogin() {
	//проверяем, пришел ли token
	if (isset($_POST['token'])) {
		$loginza = new LoginzaModel();
		$loginza->setAttributes($_POST);
		$loginza->getAuthData();
		if ($loginza->validate() && $loginza->login()) {
			//возвращаем пользователя на ту страницу на которой он
			//находился перед аутентификацией
			$this->redirect(Yii::app()->user->returnUrl);
		}
		else {
			//сообщение об ошибке
			$this->render('loginzaerror');
		}
	}
	else {
		//если этот метод вызван напрямую (без указания token)
		$this->redirect(Yii::app()->homeUrl, true);
	}
}

Этот метод мы указали в параметре return_url при настройке виджета, таким образом, именно на него придет редирект от сервиса Loginza.

Мы проверяем наличие параметра token в массиве $_POST и если он найден, продолжаем процедуру аутентификации.

От Loginza мы получаем данные о результатах аутентификации, и проверить их будет совсем не лишним. Мы, конечно, можем написать весь код самостоятельно, но гораздо удобнее использовать встроенные средства фреймворка.

Шаг 3. Создаем модель, выполняющую обработку данных от Loginza.

Модель будет называться LoginzaModel, но прежде чем переходить к ее детальному рассмотрению, определимся, какие данные о пользователе нужно хранить в БД.

Loginza передает в обязательно порядке два параметра: identity и provider (именно они позволяют однозначно идентифицировать пользователя), остальные зависят от выбранного сервиса аутентификации.

Кроме того, полезно будет хранить email пользователя и его имя. К сожалению, в зависимости от сервиса вы можете получить эти данные, а можете и не получить

Теперь рассмотрим сам класс.

<?php
class LoginzaModel extends CModel {

	public $identity;
	public $provider;
	public $email;
	public $full_name;
	public $token;
	public $error_type;
	public $error_message;

	private $loginzaAuthUrl = 'http://loginza.ru/api/authinfo?token=';

	public function rules() {
		return array(
			array('identity,provider,token', 'required'),
			array('email', 'email'),
			array('identity,provider,email', 'length', 'max'=>255),
			array('full_name', 'length', 'max'=>55),
		);
	}

	public function attributeLabels() {
		return array(
			'identity'=>'Идентификатор сервиса аутентификации',
			'provider'=>'Сервис аутентификации',
			'email'=>'eMail',
			'full_name'=>'Имя',
		);
	}

	/**
	 * Получение данных от сервиса Loginza.
	 * Предварительно нужно установить $this->token
	 * Например, так
	 * $loginza = new LoginzaModel();
	 * $loginza->setAttributes($_POST);
	 */
	public function getAuthData() {
        //получаем данные от сервера Loginza
        $authData = json_decode(
				file_get_contents($this->loginzaAuthUrl.$this->token)
				,true);

		//устанавливаем атрибуты
		//если будут отсутствовать identity и provider, метод validate
		//выдаст ошибку
		$this->setAttributes($authData);
		//full_name находится внутри вложенного массива
		//TODO доделать установку имени для разных сервисов
		$this->full_name = (isset($authData['name']['full_name'])) ? $authData['name']['full_name'] : $authData['identity'];
	}

	/**
	 * Аутентификация посетителя.
	 * @return boolean true - если посетитель аутентифицирован, false - в противном случае.
	 */
	public function login() {
		$identity = new LoginzaUserIdentity();
		if ($identity->authenticate($this)) {
			$duration = 3600*24*30; // 30 days
			Yii::app()->user->login($identity,$duration);
			return true;
		}
		return false;
	}

	public function attributeNames() {
		return array(
			'identity'
			,'provider'
			,'email'
			,'full_name'
			,'token'
			,'error_type'
			,'error_message'
		);
	}
}

Обратите внимание, что мы наследуем его от CModel и, таким образом, получаем возможность использовать встроенные средства проверки данных. Т.е. мы просто объявляем метод rules, который возвращает массив с правилами проверки.

Метод getAuthData отправляет запрос серверу Loginza, обрабатывает результат и устанавливает значения атрибутам этого класса.

Вы, наверное, заметили, что установка имени пользователя немного не доделана. Дело в том, что сервисы передают эти данные в разных элементах массива. Элемент full_name устанавливает Google. По большому счету, нужно просмотреть данные, которые возвращают остальные сервисы и соответственно устанавливать $this->full_name.

Метод login в случае успешной аутентификации создает сессию для пользователя. В нём мы создаем экземпляр класса LoginzaUserIdentity, который реализует интерфейс IUserIdentity, и передаем его в первом параметре Yii::app()->user->login.

Также LoginzaUserIdentity содержит метод authenticate, который выполняет поиск пользователя в БД и, в случае необходимости, создает новый аккаунт.

В зависимости от результата, метод login возвращает true или false.

Прежде чем переходить к рассмотрению LoginzaUserIdentity, создадим таблицу в БД в которой будем хранить данные пользователей и классы, необходимые, для работы с ней.

Шаг 4. Создаем таблицу User

Тут все просто.

Для создания таблицы можно использовать следующий SQL запрос

CREATE  TABLE IF NOT EXISTS `tablename`.`user` (
  `u_id` INT NOT NULL AUTO_INCREMENT ,
  `u_identity` VARCHAR(255) NOT NULL ,
  `u_provider` VARCHAR(255) NOT NULL ,
  `u_email` VARCHAR(255) NULL ,
  `u_full_name` VARCHAR(55) NULL ,
  `u_state` TINYINT(1) NOT NULL ,
  PRIMARY KEY (`u_id`) )
ENGINE = InnoDB;

А классы, необходимые для выполнения CRUD, можно создать с помощью компонента gii.

Вызывается так.
sitename.domen/index.php?r=gii

Предварительно нужно активировать его в настройках приложения (config/main.php)

'modules'=>array(
	'gii'=>array(
		'class'=>'system.gii.GiiModule',
		'password'=>'yourpass',
	),
),

Шаг 5. Создаем класс LoginzaUserIdentity.

Размещаться он будет в protected/components.

Как я уже упоминал, он реализует интерфейс IUserIdentity и, таким образом, фреймворк сможет с ним работать.

<?php
/**
 * Этот класс выполняет аутентификацию и, при необходимости, регистрацию посетителя.
 */
class LoginzaUserIdentity implements IUserIdentity {

	private $id;
	private $name;
	private $isAuthenticated = false;
	private $states = array();

	public function __construct() {
	}

	/**
	 * Аутентификация пользователя.
	 * Этот метод ищет пользователя в БД. Если он не найден, создает нового.
	 * Устанавливает значения атрибутов.
	 *
	 * @param LoginzaModel $loginzaModel модель, содержащая данные от сервиса Loginza
	 * @return boolean true если пользователь найден или создан новый аккаунт, false - если недостаточно данных
	 */
	public function authenticate($loginzaModel = null) {

		if (empty($loginzaModel->identity) || empty($loginzaModel->provider)) {
			return false;
		}
        //сначала проверяем, существует ли такой пользователь в БД
        $criteria=new CDbCriteria;
        $criteria->condition = 'u_identity=:identity AND u_provider=:provider';
        $criteria->params = array(
            ':identity'=>$loginzaModel->identity
            , ':provider'=>$loginzaModel->provider
        );
		$user = User::model()->find($criteria);
		if (null !== $user) {
			//используем существующего пользователя
			$this->id = $user->u_id;
			$this->name = (null != $user->u_full_name) ? $user->u_full_name : $user->u_identity;
		}
		else {
			//создаем нового
			$user = new User();
			$user->u_identity = $loginzaModel->identity;
			$user->u_provider = $loginzaModel->provider;
			$user->u_email = $loginzaModel->email;
			$user->u_full_name = $loginzaModel->full_name;
			$user->save();
			$this->id = $user->u_id;
			$this->name = (null != $user->u_full_name) ? $user->u_full_name : $user->u_identity;
		}
		$this->isAuthenticated = true;
		return true;
	}

	public function getId() {
		return $this->id;
	}

	public function getIsAuthenticated() {
		return $this->isAuthenticated;
	}

	public function getName() {
		return $this->name;
	}

	public function getPersistentStates() {
		return $this->states;
	}
}

Основную часть работы выполняет метод authenticate. Рассмотрим его подробнее.

Прежде всего, мы проверяем, есть ли у нас необходимые данные для поиска пользователя или создания нового аккаунта. Это атрибуты identity и provider модели.

Затем выполняем поиск пользователя в БД. Модель User у нас создана, поэтому поиск можно выполнить с помощью метода find.
User::model()->find($criteria)
Здесь $criteria – экземпляр CDbCriteria в котором мы установили условие 'u_identity=:identity AND u_provider=:provider'.

Если пользователь найден, устанавливаем значения атрибутов name, id и isAuthenticated. Если нет – создаем нового.

Остальные методы необходимо реализовать, т.к. они объявлены в интерфейсе IUserIdentity. Они возвращают основные данные о текущем пользователе.

Благодаря им обеспечивается совместная работа с классом CWebUser. Например, будут правильно установлены атрибуты
Yii::app()->user->isGuest, Yii::app()->user->name и т.п.

Шаг 6. Обеспечиваем возврат пользователя на исходную страницу.

Т.к. в процессе аутентификации выполняется несколько редиректов, а первый этап выполняется с помощью JS кода, то нам нужно заранее сохранить адрес страницы, на которой находился пользователь. Сделать это проще всего с помощью сессий.

К тому же, есть довольно удобный компонент под названием setReturnUrl.

Он устанавливается как фильтр

public function filters() {
	return array(
		array(
			'ESetReturnUrlFilter - login, loginzalogin, logout',
		),
	);
}

Здесь мы указываем, что этот фильтр не должен применяться к методам login, loginzalogin, logout, т.к. мы должны вернуть пользователя на страницу, на которой он находился до того, как они были вызваны.

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

Рассмотреть каждый мелкий нюанс практически невозможно, статья бы получилась просто огромной . К тому же, я предполагаю, что у вас есть хотя бы общее представление о фреймворке Yii.

Но, в любом случае, я будут рад ответить на вопросы и обсудить замечания и предложения!

До встречи!

Интересно почитать

Четыре способа увеличения продаж на конкурентном б2б-рынке

Сегодня хочу показать небольшую особенность, которую нужно учитывать при разработке виджетов для фреймворка Yii.

В большинстве случаев, виджеты состоят из файла самого виджета и файла с представлением.

Например, у нас есть файлы.
protected/components/MyWidget.php – класс виджета
и
protected/components/views/myWidget.php – представление.

Класс виджета может выглядеть примерно так.

class MyWidget extends CWidget {

	public function run() {
		$this->render('myWidget');
	}
}

А в представлении можно записать что-то вроде

<h1>Привет!</h1>

В таком варианте все будет прекрасно работать, но пользы от такого виджета немного.

Часто в представлении нужно показать какие-нибудь данные. Они могут быть получены откуда угодно: из модели, из конфигурационной файла, из параметров запроса и т.д.

При этом, передавать их в представление удобнее всего если они сохранены в виде ассоциативного массива, т.к. метод render принимает во втором параметре именно массив.

Теперь представьте такую ситуацию. Мы создаем виджет, для работы которого нужна группа параметров. При этом, возможно, часть из них нужно будет изменять для настройки виджета под конкретный проект.

Т.е. код выглядит приблизительно так

class MyWidget extends CWidget {
	public $params = array(
		'parameter 1'=>'value 1',
		'parameter 2'=>'value 2',
		'parameter 3'=>'value 3',
	);

	public function run() {
		$this->render('myWidget', $this->params);
	}
}

Теперь взгляните на код вставки виджета на страницу.

$this->widget('application.components.MyWidget');

Тут все отлично, но что если мы захотим изменить 'parameter 3'? Во втором параметре метода widget мы можем передать наши значения.

$this->widget('application.components.MyWidget', array(
	'params'=>array(
		'parameter 3'=>'new value 3',
	);
));

Но такой вызов перезапишет весь массив $params, т.е. 'parameter 1' и 'parameter 2' будут стерты.

Можно, конечно, передать весь массив, но, во-первых, элементов может быть много, а, во-вторых, нет никакого смысла задавать по нескольку раз одни и те же значения.

Лучше решить проблему так.

1) Делаем массив $params приватным.

private $params = array(
...
);

2) Добавляем метод setParams в класс виджета (название образуется с из названия атрибута класса, значение которого нужно установить (в данном случае Params), и приставки set). Этот метод в первом параметре получит новое значение атрибута. В этом примере – массив с измененным параметром. Нам остается только объединить массивы.

public function setParams($params) {
	$this->params = array_merge($this->params, $params);
}

Этот же прием можно использовать для проверки параметров или их предварительной обработки.

Если есть замечания или вопросы, пишите, постараюсь ответить

Удачи!

Интересно почитать

Предлагаем авоськи оптом из любых органических тканей

Я думаю, все, кто хоть немного работал с фреймворком Yii знают, что он поддерживает возможность разграничения прав доступа на основе ролей.

Принцип работы этой системы достаточно прост. Вы создаёте наборы правил и пользователей, связываете их между собой. После этого, вы в любой момент можете проверить, имеет ли пользователь право на выполнение какой-то операции или нет.

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

if (!Yii::app()->user->checkAccess('createUser')) {
	throw new CHttpException(403, 'Forbidden');
}
//остальной код…

В теории всё просто. Но на практике, документации и примеров по этой теме практически нет (надеюсь, это скоро изменится).

Основные источники информации (на русском): Аутентификация и авторизация и RBAC и описание ролей в файле. На английском хороших и подробных примеров, к сожалению, я не нашел.

Примечание. Очень советую прочитать эти статьи, прежде чем переходить к моему примеру.

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

В этой статье мы рассмотрим пример создания несложной системы управления пользователями (идея взята из одного web приложения).

Постановка задачи.

Есть три типа пользователей.

Обычный (user) – может создавать и редактировать свои данные (например, список контактов) и изменять свои логин/пароль.

Администратор (admin) – может создавать новых пользователей, но не может изменять их данные. Он может изменить свои собственные логин и пароль, но не может изменить роль.

Суперпользователь (root) – может выполнять любые операции с пользователями.

Ни admin, ни root не имеют доступа к персональным данным пользователя (которые он создаёт при работе с приложением).

Примечание. Чтобы сократить объем кода, я урезал набор правил. Но, думаю, вы без особого труда сможете его дополнить. Главное понять идею и принцип работы.

Шаг первый. Выбираем тип хранилища для ролей и операций.

Для этих целей Yii позволяет использовать PHP файл (CPhpAuthManager) или базу данных (CDbAuthManager).

Если вы предполагаете, что количество пользователей будет большим, то лучше использовать БД. Но для знакомства с библиотекой лучше использовать PHP файл, т.к. читать его легче. К тому же перейти от одного типа хранилища к другому совсем несложно.

Для того, чтобы Yii «узнал» о вашем выборе, в массив с настройками (config/main.php) нужно добавить следующий элемент.

'components'=>array(
…
	'authManager'=>array(
		'class' => 'CPhpAuthManager',
	),
),

Шаг второй. Создадим таблицу в БД для хранения пользователей.

Эта таблица будет состоять из шести полей.

u_id – первичный ключ;
u_name – имя пользователя;
u_email – адрес почты (используется как логин);
u_pass – пароль;
u_state – статус (активен, заблокирован);
u_role – роль пользователя (root, admin, user).

В данном примере для нас играет роль последнее поле (u_role).

Шаг третий. Создаём операции, роли и задачи.

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

Сразу перейдём к созданию файла с этими настройками.

Т.к. в качестве хранилища мы выбрали PHP файл, то можно создать его вручную (этот способ подробно рассмотрен в статье RBAC и описание ролей в файле).

Но, на мой взгляд, гораздо удобнее использовать API. Поэтому создадим небольшой инсталляционный скрипт (контроллер SiteController метод actionInstall).

Примечание. Данные будут сохранены в файле protected/data/auth.php. Файл будет создан автоматически, поэтому запись в эту папку должна быть разрешена.

public function actionInstall() {

	$auth=Yii::app()->authManager;

	//сбрасываем все существующие правила
	$auth->clearAll();

	//Операции управления пользователями.
	$auth->createOperation('createUser', 'создание пользователя');
	$auth->createOperation('viewUsers', 'просмотр списка пользователей');
	$auth->createOperation('readUser', 'просмотр данных пользователя');
	$auth->createOperation('updateUser', 'изменение данных пользователя');
	$auth->createOperation('deleteUser', 'удаление пользователя');
	$auth->createOperation('changeRole', 'изменение роли пользователя');

	$bizRule='return Yii::app()->user->id==$params["user"]->u_id;';
	$task = $auth->createTask('updateOwnData', 'изменение своих данных', $bizRule);
	$task->addChild('updateUser');

	//создаем роль для пользователя admin и указываем, какие операции он может выполнять
	$role = $auth->createRole('admin');
	$role->addChild('createUser');
	$role->addChild('viewUsers');
	$role->addChild('readUser');
	$role->addChild('updateOwnData');

	//все пользователи будут создаваться по-умолчанию с ролью user,
	//только root может менять роль другого пользователя

	//создаем роль для пользователя root
	$role = $auth->createRole('root');
	//наследуем операции, определённые для admin'а и добавляем новые
	$role->addChild('admin');
	$role->addChild('updateUser');
	$role->addChild('deleteUser');
	$role->addChild('changeRole');

	//создаем операции для user'а
	$bizRule='return Yii::app()->user->id==$params["contact"]->c_user_id;';

	$auth->createOperation('createContact','создание контакта');
	$auth->createOperation('viewContacts','просмотр списка контактов');
	$auth->createOperation('readContact','просмотр контакта', $bizRule);
	$auth->createOperation('updateContact','редактирование контакта',$bizRule);
	$auth->createTask('deleteContact','удаление контакта',$bizRule);

	//создаем роль user и добавляем операции для неё
	$user = $auth->createRole('user');

	$user->addChild('createContact');
	$user->addChild('viewContacts');
	$user->addChild('readContact');
	$user->addChild('updateContact');
	$user->addChild('deleteContact');
	$user->addChild('updateOwnData');

	//создаем пользователя root (запись в БД в таблице users)
	//тут используем DAO, т.к. AR автоматически назначит пользователю роль user
	$sql = 'INSERT INTO users(u_name, u_email, u_pass, u_state, u_role)'
		.' VALUES ("root", "test@test.ru", "'.md5('11111')
		.'", '.Users::STATE_ACTIVE.', "'.Users::ROLE_ROOT.'")';
	$conn = Yii::app()->db;
	$conn->createCommand($sql)->execute();

	//связываем пользователя с ролью
	$auth->assign('root', $conn->getLastInsertID());

	//сохраняем роли и операции
	$auth->save();

	$this->render('install');
}

Метод получился довольно объемный, но в нём большую часть занимаю вызовы createOperation и addChild, которые создают операции и связывают их с ролями.

Большинство операций в этом примере соответствуют методам контроллера (CRUD), но они могут быть любыми. Например, такими как changeRole, позволяющими изменять одно единственное поле записи.

Обратите внимание. После создания операций и ролей доступ ограничен не будет. Вы должны будете сами проверить у пользователя наличие прав с помощью метода checkAccess.

Отдельного внимания заслуживает использование бизнес правил (bizRule) в операциях.

Бизнес правило представляет собой обычный PHP код, который должен возвращать true или false. Этот код может получить массив с данными, который будет доступен через переменную $params.

Рассмотрим правило

$bizRule='return Yii::app()->user->id==$params["user"]->u_id;';

Здесь мы проверяем, соответствуют ли id текущего пользователя (который выполнил вход) и id записи в таблице пользователей, которую он хочет изменить. Таким образом, это правило позволит пользователю редактировать только свои данные.

В конце метода мы создаём пользователя root. Дело в том, что все пользователи будут создаваться с ролью user и только root может изменять роль. Поэтому мы создаём его сразу при инсталляции.

После создания пользователя назначаем ему роль (метод assign) и сохраняем изменения
$auth->save();

Шаг четвертый. Создание модели для работы с пользователями.

Как обычно, создаём модель с помощью генератора (gii) и затем вносим свои изменения.

Весь код модели я приводить здесь не буду (в конце статьи есть ссылка на архив с примером). Рассмотрим только измененные методы.

public function beforeSave() {
	parent::beforeSave();
	$this->u_pass = md5($this->u_pass);
	/*
	 * Если пользователь не имеет права изменять роль, то мы должны
	 * установить роль по-умолчанию (user)
	 */
	if (!Yii::app()->user->checkAccess('changeRole')) {
		if ($this->isNewRecord) {
			//ставим роль по-умолчанию user
			$this->u_role = Users::ROLE_USER;
		}
	}
	return true;
}

Перед созданием новой записи мы проверяем, имеет ли текущей пользователь право изменять роли, если нет, то ставим роль по-умолчанию (user).

После сохранения (или создания) записи, нужно назначить пользователю роль. Права пользователя мы уже проверили и роль установили, поэтому сейчас просто назначаем пользователю роль (метод assign).

Предварительно, с помощью метода revoke удаляем связь между пользователем и ролью (если такая существовала). Если связь не удалить, то когда root будет изменять роли, у нас появятся пользователи с несколькими ролями.

public function afterSave() {
	parent::afterSave();
	//связываем нового пользователя с ролью
	$auth=Yii::app()->authManager;
	//предварительно удаляем старую связь
	$auth->revoke($this->prevRole, $this->u_id);
	$auth->assign($this->u_role, $this->u_id);
	$auth->save();
	return true;
}

При удалении пользователя не забываем удалить связь между ним и ролью.

public function beforeDelete() {
	parent::beforeDelete();
	//убираем связь удаленного пользователя с ролью
	$auth=Yii::app()->authManager;
	$auth->revoke($this->u_role, $this->u_id);
	$auth->save();
	return true;
}

Как видите, принцип работы достаточно простой. Главное, не забывайте вызывать $auth->save(); чтобы сохранить изменения.

Шаг пятый. Контроллер и представления.

Как и в случае с моделью, создаем контроллер и представления с помощью генератора (gii).

Методы filters и accessRules можно убрать, т.к. их мы не используем. В остальные методы добавляем проверку прав пользователя.

Опять же, весь контроллер целиком рассматривать нет смысла, он есть в архиве с исходниками. В качестве примера рассмотрим метод обновления данных пользователя.

Это самый сложный случай. У нас есть пользователь, которому можно изменять любые записи, есть пользователи, которым можно изменять только свою запись, но при этом нельзя изменять свою роль. Поэтому проверок будет две.

В первый раз проверяем, пытается ли изменить роль пользователь, у которого на это нет прав.

С помощью второй проверки убеждаемся, что у пользователя есть права на изменение данной записи.

public function actionUpdate()
{
	$model=$this->loadModel();

	//проверяем, можно ли пользователю изменять роль
	if (isset($_POST['Users']['u_role']) && !Yii::app()->user->checkAccess('changeRole')) {
		throw new CHttpException(403,'Forbidden');
	}

	//проверяем, может ли пользователь изменять данную запись
	if (!Yii::app()->user->checkAccess('updateUser')
			&& !Yii::app()->user->checkAccess('updateOwnData', array('user'=>$model))) {
		throw new CHttpException(403,'Forbidden');
	}

	if(isset($_POST['Users']))
	{
		$model->prevRole = $model->u_role;
		$model->attributes=$_POST['Users'];
		if($model->save())
			$this->redirect(array('view','id'=>$model->u_id));
	}

	$this->render('update',array(
		'model'=>$model,
	));
}

В представлении (views/users/_form.php) убираем из формы поле «Роль» для пользователя у которого нет прав её изменять.

…
<?php if (Yii::app()->user->checkAccess('changeRole')) { ?>
	<div class="row">
		<?php echo $form->labelEx($model,'u_role'); ?>
		<?php echo $form->dropDownList($model,'u_role',array(
				Users::ROLE_USER=>Users::ROLE_USER,
				Users::ROLE_ADMIN=>Users::ROLE_ADMIN,
				Users::ROLE_ROOT=>Users::ROLE_ROOT,
			));
		?>
		<?php echo $form->error($model,'u_role'); ?>
	</div>
<?php } ?>
…

На этом мы остановимся. Общую идею, надеюсь, я объяснил. Если есть желание, можете скачать архив и поиграться с этим примером.

В архиве есть дамп базы и папка protected приложения. Само приложение вам нужно будет создать самостоятельно. Дальше, думаю, вы разберетесь

Любые вопросы или замечания оставляйте в комментариях. Постараюсь ответить!

В этой части я хочу рассказать о некоторых особенностях реализации AJAX запросов в компоненте CGridView.

Предположим, у нас есть таблица, и мы создали для неё модель и скрипты для выполнения CRUD операций (с помощью встроенного генератора Yii).

Пусть таблица называется countries, содержит список стран с двумя полями (id, name).

В этом случае, страница управления записями будет доступна адресу

index.php?r=countries/admin

В нижней части страницы находится пагинатор (листалка). Клик по ссылке с номером страницы приведет к отправке ajax запроса. Но вот тут появляется одна из особенностей. Этот ajax запрос возвращает не только новую страницу с данными, но и всю страницу целиком. Начиная от doctype и заканчивая закрывающим тегом html.

Если на странице ничего, кроме таблицы нет, то это не проблема. Но если мы разместим на ней несколько виджетов, для формирования которых нам потребуется выполнить дополнительные запросы к БД, то смысла в такой ajax пагинации окажется немного.

В общем, нужно, чтобы при клике на номер страницы сервер отправлял только фрагмент разметки с таблицей.

Сделать это несложно. Для начала вынесем из представления views/countries/admin.php код, который выполняет формирование таблицы в отдельный файл – views/countries/admingrid.php.

Речь идет об этом фрагменте

<?php $this->widget('zii.widgets.grid.CGridView', array(
	'id'=>'countries-grid',
	'dataProvider'=>$model->search(),
	'filter'=>$model,
	'columns'=>array(
		'c_id',
		'c_name',
		array(
			'class'=>'CButtonColumn',
		),
	),
)); ?>

На его место в views/countries/admin.php добавляем следующий код.

<?php
$this->renderPartial('admingrid', array('model'=>$model));
?>

Идея в том, что если мы получим ajax запрос, то возвращать будем только содержимое admingrid.php, если запрос будет обычный – всю страницу.

Теперь переделываем метод actionAdmin контроллера.

public function actionAdmin()
{
	$model=new Countries('search');
	$model->unsetAttributes();  // clear any default values
	if(isset($_GET['Countries']))
		$model->attributes=$_GET['Countries'];

	if (isset($_GET['ajax'])) {
		$this->renderPartial('admingrid',array(
			'model'=>$model,
		));
	}
	else {
		$this->render('admin',array(
			'model'=>$model,
		));
	}
}

Здесь добавлена дополнительная проверка (строка 8). Класс CGridView имеет свойство ajaxVar, которое по-умолчанию равно ajax. Это свойство задает имя GET параметра, который указывает, что данный запрос является ajax запросом.

Если этот параметр установлен, мы используем метод renderPartial, который возвращает браузеру только содержимое представления admingrid. В противном случае, вызываем метод render, который формирует всю страницу целиком.

Внешне в работе страницы ничего не изменилось, но если вы посмотрите с помощью firebug’а ответы сервера на ajax запросы, то разница будет заметной.

Теперь сделаем просмотр записей с помощью AJAX.

По-умолчанию, если мы нажмем на кнопку просмотра (в последней колонке таблицы), то мы попадем на страницу соответствующей записи.

Мы изменим это поведение. Добавим под таблицей блок, в котором будут отображаться подробные сведения о выбранной записи, т.е. содержимое представления views/countries/admingrid.php.

Чтобы не менять стандартное поведение кнопок в таблице мы добавим к ней ещё один столбец со ссылками «Предпросмотр».

При клике по этой ссылке под таблицей появится подробная информация о данной записи.

Приступим.

Добавляем новую колонку в таблицу. Для этого изменим файл admingrid.php следующим образом.

<?php
$this->widget('zii.widgets.grid.CGridView', array(
	'id'=>'countries-grid',
	'dataProvider'=>$model->search(),
	'filter'=>$model,
	'afterAjaxUpdate'=>'function(id, data) {$.fn.setPreviewLinksHandler(id, data);}',
	'columns'=>array(
		'c_id',
		'c_name',
		array(
			'class'=>'CButtonColumn',
		),
		array(
			'type'=>'raw',
			'value'=>'CHtml::link("Предпросмотр", array("countries/view", "id"=>$data->c_id, "ajax"=>"preview"), array("name"=>"previewLink"))',
		),
	),
)); ?>

Здесь есть нюансы. Во-первых, при добавлении столбца необходимо указать, что он имеет тип raw, иначе по-умолчанию Yii применит фильтры к его содержимому.

Во-вторых, нам нужно назначить каждой ссылке обработчик события onClick. Причем, сделать это необходимо как при первоначальной загрузке страницы, так и при «перелистовании».

Для этого мы используем свойство afterAjaxUpdate (строка 6). Ему присваиваем JavaScript функцию, которая будет вызвана после обновления таблицы с помощью ajax метода.

Теперь напишем функцию setPreviewLinksHandler. Для этого создаём файл js/previewlinks.js.

$(function() {
	$.fn.setPreviewLinksHandler = function(id, data) {
		$("a[name=previewLink]").click(function() {
			var link = $(this);
			$.get(link.attr('href'), function(data) {
				$('#preview').html(data);
			});
			return false;
		});
	};
	$.fn.setPreviewLinksHandler();
});

Эта функция получает в качестве параметров id блока с таблицей и её содержимое (data). Но, т.к. содержимое таблицы мы менять не будем, то и эти параметры нам не нужны.

Наша функция setPreviewLinksHandler ищет все ссылки, у которых атрибут name равен previewLink и назначает им обработчик события onClick.

Этот обработчик формирует и отправляет ajax запрос, который возвращает подробную информацию о записи.

Тут обратите внимание, что при отправке ajax запроса используется атрибут href ссылки, таким образом, при отключенном JS клик по ссылке будет отправлять пользователя на страницу с подробной информацией о записи.

Рассмотрим метод actionView контроллера.

public function actionView()
{
	if (isset($_GET['ajax'])) {
		$this->renderPartial('viewrow',array(
			'model'=>$this->loadModel(),
		));
	}
	else {
		$this->render('view',array(
			'model'=>$this->loadModel(),
		));
	}
}

Здесь мы проверяем, есть ли в параметрах запроса атрибут ajax, и если он есть, показываем представление viewrow. При этом используется метод renderPartial. В противном случае, просто показываем представление view.

viewrow.php создаём по тому же принципу, что и admingrid.php. Перемещаем код создания виджета CDetailView в viewrow.php.

<?php $this->widget('zii.widgets.CDetailView', array(
	'data'=>$model,
	'attributes'=>array(
		'c_id',
		'c_name',
	),
)); ?>

А в view.php добавим

<?php $this->renderPartial('viewrow', array('model'=>$model)); ?>

В результате этих манипуляций подробные сведения о записи будут появляться под таблицей при клике по ссылке «Предпросмотр».

Я надеюсь, что никого не запутал своими объяснениями Чтобы вам удобнее было экспериментировать, выкладываю архив с исходниками этого примера и дампом базы (предварительно вам нужно будет создать приложение Yii).

Если есть вопросы или замечания, пишите! Особенно интересуют альтернативные варианты решения таких задач

Интересно почитать

Компания Intelsib предлагает продвижение сайта в интернете, поисковиках, а также его аудит.

Одной из наиболее мощных возможностей фреймворка Yii является генерация кода. Она позволяет сразу после создания таблицы в базе данных получить файлы модели, контроллера и представлений. Т.е. весь необходимый код для выполнения CRUD операций.

Но, естественно, код формируется по стандартному шаблону, дизайн которого вам, возможно, захочется изменить.

Взгляните на обычную страницу управления записями, сформированную с помощью компонента CGridView.

Такая страница доступна по адресу
sitename.domen?r=controller/admin

Она состоит из трех частей.

1) Строки с номерами показанных записей и их количеством (summary).

2) Таблицы с данными (items).

3) Листалки (pager). Если записей в таблице меньше, чем отображается на странице, этот элемент показан не будет.

Теперь взгляните на код, который создает такую таблицу.

<?php $this->widget('zii.widgets.grid.CGridView', array(
	'id'=>'cities-grid',
	'dataProvider'=>$model->search(),
	'filter'=>$model,
	'columns'=>array(
		'id',
		'city',
		'country',
		array(
			'class'=>'CButtonColumn',
		),
	),
)); ?>

Источником данных служит объект CActiveDataProvider, который создается в контроллере. Но сейчас речь не о данных.

Попробуем изменить порядок вывода основных элементов.

CGridView имеет параметр template, который позволяет управлять выводом основных элементов страницы. Этот параметр принимает строку, в которой нужно перечислить необходимые элементы страницы.

Например, следующий код покажет листалку сверху и снизу страницы.

<?php $this->widget('zii.widgets.grid.CGridView', array(
	…,
	'template'=>'{summary} {pager} {items} {pager}',
	'columns'=>array(
		…,
	),
)); ?>

В шаблон можно вставлять произвольный текст и теги, но это не очень удобный вариант изменения разметки страницы. Лучше менять разметку внутри самих элементов и/или использовать CSS стили.

Если нужно изменить дизайн, то я бы рекомендовал делать в следующей последовательности.

1) Попытаться добиться результата, не меняя разметку, с помощью CSS стилей. Разметка, которую создаёт фреймворк, достаточна простая и соответствует стандартам.

2) Если необходимо, изменить разметку.

Рассмотрим первый вариант – использование своих CSS стилей.

По-умолчанию, для оформления CGridView используются следующие CSS файлы:

1) Для оформления таблицы framework/zii/widgets/assets/gridview/styles.css (он автоматически копируется в папку DOCUMENT_ROOT/accets/номер/gridview/styles.css).

2) Для оформления листалки framework/web/widgets/pagers/pager.css (он копируется в assets/номер/pager.css).

Допустим, ваши стили находятся в файлах gridview-styles.css и pager-styles.css, которые расположены в папке DOCUMENT_ROOT/css.

Подключаем файл со стилями таблицы, для этого передаем ссылку на файл в параметре cssFile.

<?php $this->widget('zii.widgets.grid.CGridView', array(
	…,
	'cssFile'=>Yii::app()->getBaseUrl(true).'/css/admin-styles.css',
	'columns'=>array(
		…,
	),
)); ?>

В результате, фреймворк будет загружать ваш файл вместо стандартного.

Кроме того, есть несколько параметров (itemsCssClass, rowCssClass, summaryCssClass и др.), которые позволяют указать ваши имена CSS классов. Но, вы можете использовать и стандартные имена классов, например, взять стандартный файл со стилями и переделывать его под свой дизайн.

Установка стилей для листалки (pager) немного отличается.

Из CGridView нужно получить доступ к атрибуту pager и устанавливать параметры для него.

<?php $this->widget('zii.widgets.grid.CGridView', array(
	…,
	'pager'=>array('cssFile'=>Yii::app()->getBaseUrl(true).'/css/pager-styles.css'),	'columns'=>array(
		…,
	),
)); ?>

Код похожий, но параметр cssFile передается в массиве и присваивается атрибуту pager.

Тут возникает интересный вопрос: «Какие еще параметры мы можем передать в этом массиве?»

Любые атрибуты класса CBasePager, а также его потомков, в том числе и имя класса-потомка, который используется для создания листалки.

В дистрибутив входит два таких класса CLinkPager (создает список ссылок с номерами страниц, используется по-умолчанию) и CListPager (создает выпадающий список с номерами страниц).

Заменить CLinkPager на CListPager можно так.

…
	'pager'=>array('class'=>'CListPager'),
…

Тут мы подходим к вопросу изменения разметки.

Допустим, нам нужно создать листалку в которой элементы страниц будут находиться внутри тегов span, а не li, как выводит CLinkPager.

Можно, конечно, создать класс, производный от CBasePager, но в данном случае будет удобнее наследовать CLinkPager.

У меня получился такой код (файл protected/components /SpanLinkPager.php).

class SpanLinkPager extends CLinkPager {

	public function run()
	{
		$buttons=$this->createPageButtons();
		if(empty($buttons))
			return;
		$this->registerClientScript();
		echo $this->header;
		echo CHtml::tag('div',$this->htmlOptions,implode("\n",$buttons));
		echo $this->footer;
	}

	protected function createPageButton($label,$page,$class,$hidden,$selected)
	{
		if($hidden || $selected)
			$class.=' '.($hidden ? self::CSS_HIDDEN_PAGE : self::CSS_SELECTED_PAGE);
		return '<span class="'.$class.'">'.CHtml::link($label,$this->createPageUrl($page)).'</span>';
	}
}

Я просто нашел в CLinkPager методы, в который формируется разметка и переопределил их. Т.е. код остался тот же, просто ul заменил на div (строка 12), а li – на span (строка 20).

Используя такой же подход можно переопределить класс CGridView и изменить разметку необходимым вам образом. Вот список основных методов, которые формируют разметку CGridView:
renderItems
renderTableHeader
renderTableFooter
renderTableBody
renderEmptyText
renderFilter
renderTableRow
renderSummary (находится в CBaseListView, который является предком CGridView)

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

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

До встречи!

Последнее время мне довольно часто приходится работать с фреймворком Yii. И иногда возникают вопросы, ответы на которые не очевидны (во всяком случае для меня).

Попробую объяснить. Сам фреймворк, на мой взгляд, достаточно удобный и документация подробная. Но классов много, и формат передачи данных их методам часто сильно влияет на результат.

Рассмотрим небольшой пример – использование оператора IN.

Т.е. нужно сформировать примерно такой запрос.

SELECT * FROM tbl_users WHERE id IN (1, 2, 3)

В Полном руководстве на эту тему информации я не нашел, а копаться в методах CActiveRecord времени не было.

Вообще, я очень не люблю такие ситуации. С одной стороны, понятно как нужно написать запрос, с другой – хочется сделать это красиво, используя встроенную библиотеку. Копаться в документации не хочется, ведь на это уходит время, а запрос можно составить за считанные минуты. Но не все так просто.

Сначала покажу решение «в лоб».

$ids = array(1, 2, 3);

$dataProvider=new CActiveDataProvider('User',array(
	'criteria'=>array(
		'condition'=>'id IN ('.implode(',', $ids).')',
	)
));

$this->render('admin',array(
	'model'=>$dataProvider,
));

Тут мы формируем массив со значениями, которые будут перечислены после IN. А затем, с помощью функции implode преобразуем его в строку и просто вставляем в запрос.

Недостатки такого подхода очевидны.

Во-первых, выглядит код не очень красиво.

Во-вторых, в реальном приложении значения для массива $ids будут откуда-то поступать, возможно, из параметров запроса. И если массив $ids окажется пустым, то при выполнении запроса возникнет ошибка.

В-третьих, полученные значения нужно проверить. А написать что-то вроде

'params'=>array(':id'=>implode(', ', $ids)),

не получится, т.к. результат работы функции implode будет взят в кавычки. Т.е. проверку необходимо сделать предварительно.

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

Решение с помощью библиотеки Yii.

Оно выглядит гораздо проще.

$model = User::model()->findAllByAttributes(array('id'=>array(1, 2, 3)));
$dataProvider=new CActiveDataProvider('User');
$dataProvider->setData($model);

$this->render('index',array(
	'dataProvider'=>$dataProvider,
));

Метод findAllByAttributes класса CActiveRecord позволяет искать записи в БД по названию поля и значению. При этом если значение является массивом, то используется оператор IN.

Этот же самый код можно записать немного иначе.

$dataProvider=new CActiveDataProvider('User');
$dataProvider->criteria->addInCondition('id', array(1,2,3));

$this->render('index',array(
	'dataProvider'=>$dataProvider,
));

Тут уже используется метод addInCondition класса CDbCriteria. Если вы работаете с CActiveDataProvider, то получить доступ к объекту CDbCriteria можно с помощью свойства criteria.

Теперь проведем несколько экспериментов.

Попробуем в массиве передать строку.

$dataProvider->criteria->addInCondition('id', array(1,2,'test'));

В результате будет выполнен следующий запрос.

SELECT * FROM 'tbl_user' WHERE "id" IN (1, 2, 0)

Т.е. текстовое значение было заменено нулем, что вполне логично, т.к. поле id имеет тип INT.

Если запрос будет выполняться к полю текстового типа, то текстовые и числовые значения будут вставлены в кавычках.

$dataProvider->criteria->addInCondition('id', array(1, 'admin','user'));

сформирует такой запрос

SELECT * FROM 'tbl_user' WHERE "id" IN ('1','admin', 'user')

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

$dataProvider->criteria->addInCondition('id', array());

SELECT * FROM 'tbl_user' WHERE 0=1

Как видите, использование встроенных библиотек всё-таки оправдывает время, потраченное на их изучение

Только не забывайте при работе с документацией Yii учитывать один момент. Классы библиотеки тесно связаны между собой, поэтому искать нужно не только в методах класса, с которым вы непосредственно работаете, но и в методах объектов, которые использует этот класс.

Так CActiveDataProvider использует CDbCriteria для формирования условий, CPagination – для разбивки на страницы, CSort – для сортировки и т.д.

Вообще, я заметил, чем больше работаешь с фреймворком, тем логичнее кажутся решения разработчиков и тем проще ориентироваться в документации

Удачи!

Сегодня продолжим тему использования сервиса Bit.ly вместе с PHP фреймворком Yii. В прошлой части мы рассмотрели создание коротких ссылок для страниц вымышленного сайта с новостями.

В этой части мы создадим отдельную страницу, на которой будет отображаться статистика переходов по коротким ссылкам.

Приступим.

Шаг первый. Добавляем новое поле в модель.

На данный момент у нас есть модель News, которая содержит следующие поля:

n_id – первичный ключ;
n_title – заголовок новости;
n_content – текст новости;
n_short_url – короткая ссылка (не обязательное поле).

Мы добавим ещё одно поле n_clicks, в которое будем записывать количество переходов по короткой ссылке.

class News extends CActiveRecord
{
	public $n_clicks;
...

Сохранять значение этого поля в базе данных не нужно, ведь оно будет очень быстро устаревать, поэтому мы будем получать его с сервиса Bit.ly при каждой загрузке страницы со статистикой.

Шаг второй. Создаём метод для получения статистики.

В прошлой части мы создали компонент BitLyShortener с методом получения короткой ссылки. Используем этот же компонент и добавим в него новый метод.

public static function getStatistics(&$models) {
	//если массив пуст - не делаем ничего
	if (0 == count($models)) {
		return;
	}
	/*
	 В запросе к Bit.ly можно передать до 15 ссылок.
	 Поэтому сначала формируем общую часть запроса, а
	 затем - добавляем в цикле ссылки, для которых
	 нужно получить статистику.
	*/
	$requestBase = 'http://api.bit.ly/v3/clicks?'
		.'login='.self::LOGIN
		.'&apiKey='.self::APIKEY
		.'&format=json';

	//разбиваем массив с моделями на блоки по 15 элементов
	$modelsChunks = array_chunk($models, 15, true);
	//для каждого блока формируем и отправляем запрос
	foreach ($modelsChunks as $i => $chunk) {
		$request = $requestBase;
		foreach ($chunk as $key => $model) {
			$request .= '&shortUrl='.urlencode($model->n_short_url);
		}
		$response = file_get_contents($request);
		$res = json_decode($response, true);
		//сохраняем результаты
		foreach ($chunk as $key => $model) {
			$models[$key]->n_clicks = $res['data']['clicks'][$key - $i*15]['global_clicks'];
		}
	}
}

Принцип получения статистики такой же, как и принцип создания короткой ссылки. Нужно отправить специальным образом сформированный запрос. Но есть нюанс.

Сервис Bit.ly накладывает ограничение на количество ссылок, для которых можно получить статистику. На данный момент обрабатывается не более 15 ссылок на запрос.

Поэтому мы разбиваем массив с короткими ссылками на блоки по 15 штук, и для каждого блока отправляем отдельный запрос.

Вообще сервис возвращает несколько значений

"clicks": [
    {
        "short_url": "http://tcrn.ch/a4MSUH", //короткая ссылка
        "global_hash": "bWw49z", //глобальный хеш идентификатора bit.ly
        "user_clicks": 0, //количество кликов по данной ссылке
        "user_hash": "a4MSUH", //идентификатор пользователя bit.ly
        "global_clicks": 1105 //количество кликов по всем коротким ссылкам, которые соответствуют данному полному URL
        },

Из всех этих параметров нам нужен только global_clicks. Его мы и записываем в исходный массив с новостями.

Шаг третий. Создаём страницу со статистикой.

Для этого добавим в контроллер метод actionStatistics

public function actionStatistics() {
	$criteria = new CDbCriteria;
	$pages = new CPagination(News::model()->count($criteria));
	$pages->pageSize = self::PAGE_SIZE;

	$models = News::model()->findAll($criteria);

	//получаем данные о посещаемости от Bit.ly
	BitLyShortener::getStatistics($models);

	$this->render('statistics', array('models'=>$models));
}

И создаём представление protected/views/news/statistics.php

<?php
foreach ($models as $model) {
?>
    <p>
        <strong><?php echo $model->n_title; ?></strong><br />
        Короткая ссылка: <?php echo $model->n_short_url; ?><br />
        Количество переходов: <?php echo $model->n_clicks; ?>
    </p>
<?php
}
//TODO добавить листалку страниц

//end of statistics.php

В результате, по адресу index.php?r=news/statistics должна появиться страница со статистикой.

Как видите, ничего сложного. Главное, не ошибиться при составлении запроса для Bit.ly.

Архив с файлами для этого примера (необходимо распаковать в папку protected).

Все вопросы и замечания пишите в комментариях. Постараюсь ответить

Интересно почитать

В магазине gamesdealer.ru есть все для покера: карты, фишки и покерные наборы.

Магазин Irobot-home.ru: лучшие роботы пылесосы от iRobot.

Думаю, о твиттере и о том, какую роль в нем играют короткие ссылки, слышали все. В принципе, можно вообще не заморачиваться, т.к. twitter сам создаст их для вас, но при таком подходе возникнет несколько проблем.

Во-первых, длина ссылки и текста может превысить 140 символов. Т.е. ссылку лучше сразу сократить.

Во-вторых, будет сложнее отслеживать статистику переходов.

Поэтому гораздо удобнее использовать специализированные сервисы, например, Bit.ly. Этот сервис предоставляет API как для создания ссылок, так и для получения статистики переходов по ним.

Теперь рассмотрим небольшой пример.

Допустим, вы разрабатываете сайт с использованием PHP фреймворка Yii. На котором у вас есть раздел с новостями. Необходимо на странице каждой новости создать кнопку «Опубликовать в твиттере», а текст сообщения должен состоять из заголовка новости и короткой ссылки на неё.

Код создания самой кнопки мы сейчас рассматривать не будем, т.к. это немного другая тема. Мы напишем компонент, позволяющий получать сокращенный URL страницы, и рассмотрим его подключение к фреймворку.

Шаг первый. Подготовим площадку для экспериментов.

1) Создаем приложение

yiic webapp .

2) Создаем таблицу в БД. Я использовал стандартную sqlite базу.

Название таблицы tbl_news

Поля:

n_id – первичный ключ;
n_title – заголовок новости;
n_content – текст новости;
n_short_url – короткая ссылка (не обязательное поле).

3) Создаем контроллер и модель

Для этого последовательно выполняем три команды

yiic shell
model News tbl_news
crud News

Теперь у нас есть работающий сайт. Страница с новостями будет доступна по адресу.

site_name.domen/index.php?r=news/index

На этой странице в сайдбаре будут ссылки на страницы создания и управления новостями.

Шаг второй. Регистрируемся на сервисе Bit.ly.

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

Регистрация осуществляется на этой странице.

Затем необходимо получить API-ключ.

Ваши логин и ключ API будут использоваться при всех обращениях к сервису.

Шаг третий. Если необходимо, настраиваем urlManager.

Этот компонент позволяет превращать ссылки вида
localhost/sites/yii_bit_ly/public_html/index.php?r=news/view&id=1
в
localhost/sites/yii_bit_ly/public_html/index.php/news/1

Настройка выполняется в файле protected/config/main.php, подробнее о ней можно почитать в статье Красивые адреса URL.

Дело в том, что если вы измените формат ссылок, то сокращенные ссылки нужно будет создавать заново, поэтому лучше определиться с ним заранее.

Шаг четвертый. Создаём компонент для работы с сервисом.

Назовем его BitLyShortener. Он должен находиться в файле (protected/components/BitLyShortener.php).

<?php
/**
 * Этот компонент предназначен для создания ссылок с помощью
 * сервиса Bit.ly
 */
class BitLyShortener extends CComponent {
    const LOGIN = 'ваш_логин';
    const APIKEY = 'ваш_API_ключ';

    /**
     * Укорачивает заданнй URL с помощью сервиса Bit.ly
     *
     * @param $fullUrl string - URL для которого нужно получить короткую ссылку
     * @return string короткая ссылка
     */
    public static function getShortUrl($fullUrl) {
        //формируем запрос
        $request = 'http://api.bit.ly/v3/shorten?'
            .'login='.self::LOGIN
            .'&apiKey='.self::APIKEY
            .'&longUrl='.urlencode($fullUrl)
            .'&format=json';

        //отправляем запрос
        $response = file_get_contents($request);
        $res = json_decode($response, true);

        return $res['data']['url'];
    }
}

//end of BitLyshortener.php

Архив с этим компонентом

Как видите, перед использованием нужно указать ваши логин и API ключ для работы с Bit.ly. Затем, для получения короткой ссылки достаточно вызвать метод getShortUrl и передать ему ссылку страницы в первом параметре.

API у Bit.ly достаточно прост. Для получения короткой ссылки достаточно сформировать и отправить обычный HTTP запрос. Ответ можно получить как в JSON, так и в XML формате. На мой взгляд, работать с JSON немного проще, но это не принципиально.

В случае успешного создания короткой ссылки сервис возвращает следующие данные

array
  'status_code' => int 200
  'status_txt' => string 'OK' (length=2)
  'data' =>
    array
      'long_url' => string 'http://site_name.domen/index.php?r=news/view&id=2' (length=72)
      'url' => string 'http://bit.ly/short_link' (length=20)
      'hash' => string 'c86mVl' (length=6)
      'global_hash' => string '9mLuyJ' (length=6)
      'new_hash' => int 1

Шаг пятый. Добавляем код создания ссылки в контроллер.

В случае с фреймворком Yii ссылку сокращать удобнее всего в методе loadModel() контроллера News, т.к. сразу после создания новости будет выполнен редирект на новую страницы и, соответственно, вызван метод loadModel().

public function loadModel()
{
	if($this->_model===null)
	{
		if(isset($_GET['id']))
			$this->_model=News::model()->findbyPk($_GET['id']);
			//проверяем, создана ли короткая ссылка для данной новости
			if (!isset($this->_model->n_short_url) || $this->_model->n_short_url == '') {
				//получаем адрес текущей страницы
				$request = Yii::app()->getRequest();
				$link = $request->getHostInfo().$request->getUrl();
				$this->_model->n_short_url = BitLyShortener::getShortUrl($link);
				//сохраняем короткую ссылку
				$this->_model->save();
			}
		if($this->_model===null)
			throw new CHttpException(404,'The requested page does not exist.');
	}
	return $this->_model;
}

Здесь мы проверяем, создана ли для данной записи короткая ссылка, и если нет – создаём её. Предварительно получаем URL текущей страницы. Затем, присваиваем короткую ссылку атрибуту n_short_url и сохраняем модель.

Таким образом, запрос на создание короткой ссылки будет отправляться только один раз для каждой страницы.

Вывести полученную ссылку можно точно так же, как и любой другой атрибут модели.

Вот и всё! Если у вас появились вопросы или есть замечания, пишите, обсудим

Интересно почитать

Лучшие предложения на металлопрокат в москве на
skladmetalla.ru .

Уют и тепло ваше квартире дадут чугунные радиаторы для надежного отопления вашей квартиры.

Манго фитнес-центр и салон красоты в цао, все под одной крышей.

О том, что фреймворки позволяют сократить время разработки, знают все. Но иногда при этом появляются самые неожиданные ограничения.

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

В этой статье я хочу показать пример такой ситуации, и, естественно, её решение.

UPD: Более удачное решение данной проблемы приведено в комментариях.

Не так давно я опубликовал статью Yii PHP фреймворк: создаем поле с автозаполнением, в которой рассказывал об использовании виджета CAutoComplete.

Алгоритм его работы довольно прост.

1) Создать текстовое поле (тег input).
2) Подключить плагин jQuery Autocomplete и файлы CSS стилей.
3) Подключить плагин к текстовому полю.

При этом, все настройки виджета CAutoComplete задаются при его подключении в PHP массиве.

Т.к. основную работу выполняет Autocomplete, то логично было бы предположить, что в настройках виджета можно задать все параметры этого плагина. Для большинства параметров, так оно и есть, но с параметром extraParams возникли проблемы.

В документации сказано.

Extra parameters for the backend. If you were to specify {bar:4}, the autocompleter would call my_autocomplete_backend.php?q=foo&bar=4 (assuming the input box contains "foo"). The param can be a function that is called to calculate the param before each request.

Дополнительный параметр для бэкенда. Если вы указали {bar:4}, плагин отправит запрос my_autocomplete_backend.php?q=foo&bar=4 (предполагается, что текстовое поле содержит текст "foo"). Параметр может быть функцией, которая вызывается чтобы рассчитать значение параметра перед отправкой каждого запроса.

Т.е. вы можете задать настройки для CAutoComplete следующим образом.

$this->widget('CAutoComplete',
     array(
         'extraParams'=>array('mypar'=>'myval'),
         'url'=>array('countries/autocomplete'),
     )
 );

И такой вариант будет работать.

Но если вы захотите использовать в качестве значения функцию, например

'extraParams'=>array('mypar'=>'function() {return $("#myselect").val();}'),

то этот JS код выполняться не будет.

Примечание. Показанная здесь функция возвращает значение из выпадающего списка (myselect).

Дело в том, что функция передается в виде стоки (в кавычках) и JS код при этом, естественно, не выполняется.

Решить проблему можно так.

1) Создаём js файл с таким кодом.

jQuery("#country").setOptions({
'extraParams':{'mypar':function() {return $("#myselect").val();}}}
);

2) Подключаем его к нужной странице.

$cs = Yii::app()->clientScript;
$cs->registerScriptFile(Yii::app()->request->baseUrl.'/js/autocomplete_config.js', CClientScript::POS_END);

Здесь autocomplete_config.js – название вашего скрипта.

Как видите, решение достаточно простое, но не очень красивое. Часть настроек виджета будет задана в PHP файле, часть в JS.

Если вы знаете более удачные варианты, буду рад выслушать и обсудить

До встречи!

Интересно почитать

Удобный и недорогой стол для кассы отечественной разработки