С недавних пор этот блог опять стали одолевать спамеры. Не знаю с чем это связано, больше года всё было относительно спокойно. Проскакивало по несколько спамерских комментариев в неделю, явно написанных людьми, а не ботами, и всё. А тут по 10-20 требкеков в день. Удалить их, конечно, не сложно, но надоедает и раздражает, к тому же трекбеки явно ставились автоматически, т.е. спамер своё время на них не тратил.

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

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

Теория

В WordPress все посты хранятся в таблице wp_posts (префикс wp_ может быть другим). В этой таблице есть поле ping_status, которому можно присвоить одно из двух значений: «open» или «closed». Как несложно догадаться по названию, значение «closed» отключает трекбеки к данном посту.

Теперь нужно определиться с датами. MySQL поддерживает довольно много функций для работы со временем и датами. Нам потребуются:
1) CURDATE – возвращает текущую дату;
2) DATE_SUB – вычитает даты;
и выражение INTERVAL ... DAY – позволяет указать интервал с заданным количеством дней.

Дата последнего изменения поста хранится в поле post_modified (таблицы wp_posts).

Формируем запрос

UPDATE wp_posts SET ping_status="closed" WHERE post_modified < DATE_SUB(CURDATE(), INTERVAL 60 DAY)

Как видите, это обычный UPDATE запрос, который установит полю ping_status значение «closed» для всех записей у которые последний раз обновлялись более 60-ти дней назад.

Кстати, аналогичным способом можно закрыть и комментарии. Для этого нужно установить значение «closed» для поля «comment_status».

Остаётся настроить периодический запуск этого запроса

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

В данном случае команда может выглядеть следующим образом.

mysql --default-character-set=utf8 --user=user_name --password=user_password db_name < path_to/block_trackbacks.sql

Здесь block_trackbacks.sql – имя файла в котором записан наш запрос.

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

Результаты

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

Успехов!

О сортировке данных с помощью SQL запросов, думаю, знают все web разработчики.

Достаточно указать в запросе предложение ORDER BY с нужными параметрами и вы получите желаемый результат.

Параметры задавать тоже несложно. Просто перечисляете через запятую столбцы по которым нужно выполнить сортировку и указываете её направление (по возрастанию (ASC) или по убыванию (DESC)).

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

SELECT * FROM articles ORDER BY a_title ASC, a_date DESC

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

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

Сортировка с учетом типа данных

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

При этом таблицы будут иметь приблизительно следующую структуру.

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

Но что произойдет если мы попытаемся выполнить сортировку по метаданным?

Такую сортировку можно выполнить с помощью следующего запроса

SELECT * FROM articles AS a LEFT JOIN metadata AS m ON a.a_id=m.m_article_id WHERE m.m_name="color"

Этот запрос выведет все записи из таблицы articles для которых создано мета-поле color.

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

При этом числовые данные будут отсортированы не правильно. Дело в том, что ORDER BY сравнивает значения с учетом типа поля и, например, при сортировке по возрастанию вы получите следующий ряд значений: «1», «10», «2», «3» и т.д.

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

SELECT * FROM metadata ORDER BY (m_value+0)

Обратная операция (сортировка числового поля по правилам текстового) записывается немного сложнее.

SELECT left(a_id, 20) AS id_str FROM articles ORDER BY id_str

Функция left возвращает строку, содержащую первые N символов из строки, указанной в первом параметре. Количество символов (N) задается во втором параметре. В данном случае будут выбраны первые 20 символов (достаточно чтобы преобразовать 8-байтное целое число в строку). Т.е. движок MySQL выполнит сортировку по строке, полученной из значения числового поля.

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

Сортировка текста с учетом регистра

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

1. «Язык запросов»
2. «Язык программирования»
3. «Язык Запросов»

Но если всё-таки сортировку нужно выполнить с учетом регистра, просто добавьте оператор BINARY перед именем поля.

SELECT * FROM articles ORDER BY BINARY a_title

Сортировка по фрагменту строки

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

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

SELECT SUBSTRING_INDEX(a_title, ' ', -1) AS at FROM wp_5_posts ORDER BY at

Сортировка записей по заданному списку значений

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

Очевидно, что, используя стандартный вариант сортировки (по алфавиту), расположить сезоны порядке «весна», «лето», «осень», «зима» не получится. Естественно, можно каждому времени года присвоить свой код, но есть и другой вариант решения – использовать функцию FIELD.

SELECT * FROM articles ORDER BY FIELD(a_season, "весна","лето","осень","зима")

Эта функция ищет значение, указанное в первом параметре, среди значений, перечисленных в остальных параметрах, и возвращает его порядковый номер. При выполнении запроса в первый параметр функции FIELD будут передаваться значения из поля a_season и, таким образом, записи будут отсортированы в заданном нами порядке.

Сортировка строк по их длине

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

SELECT * FROM articles ORDER BY CHAR_LENGTH(a_title)

Как видите, «фокус» заключается в использовании функции CHAR_LENGTH, которая определяет количество символов в строке.

Заключение

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

Интересное в Интернете

Заказ свадебных фотоальбомов с доставкой по РФ и СНГ

Последнее время мне довольно часто приходится работать с фреймворком 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 – для сортировки и т.д.

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

Удачи!

Приветствую всех!

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

Принцип создания такого поля довольно прост. На странице нужно поместить обычное текстовое поле и назначить событию onKeyUp обработчик, который будет отправлять AJAX запросы серверу. В этих запросах нужно передавать введённый посетителем текст. Сервер ищет совпадения с этим текстом в БД и возвращает результат браузеру. JavaScript обработчик создаёт список с вариантами, полученными от сервера, и показывает его под полем.

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

Теперь, давайте разберёмся, что сделает за вас виджет, а что придётся делать вам.

Для работы виджет использует плагин Autocomplete библиотеки jQuery, т.е. писать JS код от вас не потребуется (если, конечно, вы не хотите изменить стандартное поведение плагина).

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

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

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

Допустим, у нас есть база данных с названиями стран. Таблица называется countries, а поле, в котором хранятся названия – c_name.

Создаём для этой таблицы модель.

yiic shell
model countries

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

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

Код вставки виджета выглядит так.

$this->widget('CAutoComplete',
	array(
		'model'=>'countries',
		'name'=>'country',
		'url'=>array('countries/autocomplete'),
		'minChars'=>2,
	)
);

Во втором параметре необходимо передать массив с параметрами. Обязательными являются первые два.
model – имя модели.
name – атрибут name текстового поля.
url – адрес скрипта, который будет обрабатывать AJAX запросы.
minChars – минимальное количество символов, при котором выполняется отправка запроса.

Естественно, это не все параметры. Подробный их перечень вы найдете на странице документации.

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

index.php?r=countries/autocomplete&q=%D0%B0%D0%BB&limit=10&timestamp=1273944702297

В параметре q передаётся введённый посетителем текст, а в параметре limit – максимальное количество подстановок.

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

public function actionAutoComplete() {

	if (isset($_GET['q'])) {

		$criteria = new CDbCriteria;
		$criteria->condition = 'c_name LIKE :country';
		$criteria->params = array(':country'=>$_GET['q'].'%');

		if (isset($_GET['limit']) && is_numeric($_GET['limit'])) {
			$criteria->limit = $_GET['limit'];
		}

		$countries = countries::model()->findAll($criteria);

		$resStr = '';
		foreach ($countries as $country) {
			$resStr .= $country->c_name."\n";
		}
		echo $resStr;
	}
}

Здесь мы проверяем, пришли ли параметры и формируем запрос.

Условие записываем с помощью класса CDbCriteria. В атрибуте condition указываем название поля и операцию сравнения (LIKE). В атрибуте params – текст, введенный пользователем. Обратите внимание, мы добавляем к нему знак %, т.е. найдены будут все страны, названия которых начинаются с указанных букв.

Затем добавляем параметр limit и выполняем запрос (findAll).

Из результатов поиска формируем строку с найденными названиями стран. Разделителем служит символ новой строки (это требование плагина). И отправляем результат браузеру.

Как видите, пользоваться виджетом совсем не сложно.

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

Удачи!

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

В новых версиях фреймворка Yii (1.1.х) немного изменился принцип использования встроенной библиотеки для работы с базой данных, точнее она стала по-другому формировать SQL запросы при использовании связанных таблиц.

Речь идет об этом изменении.

По умолчанию для всех отношений, включенных в 'жадную' загрузку, будет сгенерировано и выполнено одно выражение с использованием JOIN. Если в основной таблице есть опции запроса LIMIT или OFFSET, то сначала будет выполнен этот запрос, а затем другой SQL-запрос, который возвращает все связанные объекты. Раньше, в версии 1.0.x, по умолчанию вызывалось N+1 SQL-запросов, если 'жадная' загрузка включала N отношений HAS_MANY или MANY_MANY.
(перевод взят отсюда)

В моем примере с игровым сайтом как раз возникла такая ситуация. Есть две таблицы, с играми (ygs_games) и их жанрами (ygs_types). Отношение между таблицами многие-ко-многим.

При этом необходимо выводить игры определённого жанра с разбивкой на страницы (пагинацией), т.е. использовать в запросе limit и offset.

Yii позволяет сформировать запросы на получение этих данных двумя способами, которые называются: "жадная" загрузка и "ленивая" загрузка. Первый предполагает формирование одного запроса, в котором будут получены все необходимые данные. В этом запросе будут использованы объединения (JOINs). Во втором случае используется несколько запросов. Сначала выбираются нужные записи из первой таблицы (первый запрос), затем – данные из связанной таблицы (для каждой записи из первой таблицы выполняется дополнительный запрос).

Проблема, с которой я столкнулся.

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

$criteria=new CDbCriteria;
$criteria->condition = 't_id=:t_id';
$criteria->params = array(':t_id'=>$_GET['type_id']);
$criteria->with = array('ygs_types'=>array('together'=>true));

$pages=new CPagination(Games::model()->published()->count($criteria));
$pages->pageSize=self::PAGE_SIZE;
//этот метод добавляет параметры limit и offset в объект $criteria, т.е. в запрос
$pages->applyLimit($criteria);

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

здесь t_id – первичный ключ в таблице жанров.
ygs_types – название элемента в массиве, который возвращает метод relations() модели (этот элемент просто описывает отношение многие-к-многим).

При этом формировался один запрос по методу "жадной" загрузки, который возвращал все необходимые данные.

Но в новых версиях Yii этот код не работает.

Дело в том, что как только мы указываем LIMIT или OFFSET в запросе, который включает связанные таблицы, библиотека Yii разбивает запрос на два. Сначала выполняется запрос только к первой таблице и именно к нему применяется LIMIT.

SELECT `t`.`g_id` AS `t0_c0`, ... FROM `ygs_games` `t`  WHERE ((g_state=0) AND
(t_id=:t_id)) LIMIT 10. Bind with parameter :t_id='2'

И сразу же возникает ошибка.

Column not found: 1054 Unknown column 't_id' in 'where clause'

Причина ошибки в том, что yii пытается вставить параметр для поля t_id, которого нет в таблице ygs_games. Таблица ygs_types будет присоединена в следующем запросе (с помощью JOIN), но LIMIT применяется именно в первом запросе к первой таблице, а нужно, чтобы он применялся к результату объединённого запроса.

Отключить это поведение, судя по всему, нельзя.

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

Первым запросом мы находим нужный жанр в таблице ygs_types.

$type = Types::model()->findByPk($_GET['type_id']);

Тут выполняется следующий запрос

SELECT * FROM `ygs_types` `t` WHERE `t`.`t_id`=8 LIMIT 1

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

$type->ygs_games

нам не подходит, т.к. мы не сможем указать параметры, например тот же limit (если нужно его изменять).

Примечание. Можно, конечно, указать параметры в массиве, который возвращает метод relations, но этот метод имеет свои недостатки. Например, чтобы изменить параметры (тот же limit), их придется хранить в отдельном массиве, и его нужно будет объединять с массивом, который возвращает relations().

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

$params = array(
        'limit'=>self::PAGE_SIZE,
        'condition'=>'g_state='.Games::PUBLISHED,
        'order'=>'g_added DESC',
);
$games = $type->getRelated('ygs_games',false, $params);

При этом Yii формирует следующий запрос (self::PAGE_SIZE = 10)

SELECT `ygs_games`.`g_id` AS `t1_c0`, ... FROM `ygs_games` `ygs_games` INNER JOIN
`ygs_games_types` `ygs_games_ygs_games` ON
(`ygs_games_ygs_games`.`gt_type_id`=:ypl0) AND
(`ygs_games`.`g_id`=`ygs_games_ygs_games`.`gt_game_id`) WHERE (g_state=0)
ORDER BY g_added DESC LIMIT 10. Bind with parameter :ypl0='8'

Т.е. именно то, что нам нужно.

Тут есть один недостаток – усложняется код настройки пагинации. Мы должны вручную установить параметры limit и offset.

Полностью метод, формирующий страницу с играми одного жанра выглядит так.

public function actionShowGames()
{
	if (isset($_GET['type_id']) && is_numeric($_GET['type_id'])) {
		$criteria = new CDbCriteria;

		$type = Types::model()->findByPk($_GET['type_id']);
		//нужно использовать "ленивую" загрузку (не использовать with)
		//иначе не получится указать limit для связанной таблицы
		$params = array(
			'limit'=>self::PAGE_SIZE,
			'condition'=>'g_state='.Games::PUBLISHED,
			'order'=>'g_added DESC',
		);
		//настраиваем пагинацию
		if (isset($_GET['page']) && is_numeric($_GET['page'])) {
			$params['offset'] = ($_GET['page'] - 1) * self::PAGE_SIZE;
		}
		$pages=new CPagination(count($type->getRelated('ygs_games')));
		$pages->pageSize=self::PAGE_SIZE;

		$games = $type->getRelated('ygs_games',false, $params);

		$this->render('showGames'
			,array('games'=>$games, 'pages'=>$pages));
	} else {
		$this->redirect('/games/list');
	}
}

Обратите внимание на строки 16 и 18. В них мы устанавливаем смещение (offset) и создаём объект CPagination. Последнему передаём количество всех игр данного жанра. Для этого просто используем функцию count.

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

Чтобы удобнее было сравнивать работу библиотеки, я не удалял старый код создания страниц с жанрами (GamesController.php метод actionList). Новый метод находится в контроллере TypesController.php (метод actionShowGames).

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

Я всё-таки решил продолжить обсуждение фреймворка Yii. Но на этот раз затяжных циклов я не планирую , просто хочу рассказать о некоторых нововведениях в версиии 1.1.

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

Но есть момент, который может вызвать вопросы у тех, кто начинает знакомство с фреймворком с версии 1.1. Речь о классе CActiveDataProvider. Как несложно догадаться по названию, он предназначен для работы с базой данных. И если вы создадите сайт с помощью консольной утилиты yiic, то этот класс будет использован в методах actionIndex и actionAdmin контроллеров.

Класс очень удобный и позволяет сократить объём кода. Проблема в том, что документация немного отстаёт от жизни. В разделе о работе с базой данных подробно рассказывается об использовании классов CActiveRecord, CDbCriteria и других, но информация о CActiveDataProvider есть только в API.

Итак, что представляет собой этот класс.

По большому счёту это обёртка вокруг четырёх классов CActiveRecord, CDbCriteria, CPagination и CSort. Именно с их помощью выполняется основная работа с базой данных и очень часто все эти классы используются одновременно. Поэтому вполне логично, что разработчики решили создать общую оболочку для работы с ними.

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

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

$criteria=new CDbCriteria;

$pages=new CPagination(Screenshots::model()->count($criteria));
$pages->pageSize=self::PAGE_SIZE;
$pages->applyLimit($criteria);

$sort=new CSort('Screenshots');
$sort->applyOrder($criteria);

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

$this->render('admin',array(
	'models'=>$models,
	'pages'=>$pages,
	'sort'=>$sort,
));

Обратите внимание, что здесь создаются экземпляры CDbCriteria, CPagination и CSort. При этом с помощью CDbCriteria мы можем изменять SQL запросы, которые создаёт модель (Screenshots). CPagination используется для настройки пагинации, а CSort – сортировки записей. Массив с объектами CActiveRecord возвращает метод findAll модели. Обратите внимание, что для настройки, которые хранятся в CDbCriteria используются всеми остальными классами.

Теперь взгляните на то, как решается эта же задача в версии 1.1.

$dataProvider=new CActiveDataProvider('Screenshots', array(
	'pagination'=>array(
		'pageSize'=>self::PAGE_SIZE,
	),
));

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

Правда, значительно лучше выглядит? Хотя, на самом деле, работает код точно также. Просто все экземпляры объектов CPagination, CSort и CDbCriteria находятся внутри CActiveDataProvider.

Обратите внимание, что в первом параметре конструктора мы передаём название модели, данные которой нужно получить. CActiveDataProvider сам вызовет соответствующие методы find() или findAll().

Тут возникает вполне резонный вопрос: «Каким образом настраивать поиск, разбивку на страницы и т.п.?» Всё очень просто, нужно передать массив с соответствующими параметрами в конструкторе. Например.

$dataProvider=new CActiveDataProvider('Post', array(
	'criteria'=>array(
		'condition'=>'status=1 AND tags LIKE :tags',
		'params'=>array(':tags'=>$_GET['tags']),
		'with'=>array('author'),
	),
	'pagination'=>array(
		'pageSize'=>20,
	),
));

Как видите, настройки указываются точно так же, как и в предыдущих версиях (по большому счёту это они и есть). Т.е. вы можете спокойно использовать документацию по CDbCriteria при настройке CActiveDataProvider.

Кроме того, если возникнет необходимость, можно использовать методы getCriteria(), setCriteria(), getSort(), setSort() для чтения и установки соответствующих объектов.

Передача данных в представление.

Как несложно заметить по листингам, в версиях 1.0.х необходимо было передавать три параметра: с данными, настройками пагинации и сортировки. В новом варианте передаётся только один – сам объект CActiveDataProvider.

При этом если вы будете вручную вытягивать из него данные, код получится довольно объёмным. Но в версию 1.1 входят компоненты zii, один из которых (zii.widgets.grid.CGridView) специально разработан для использования вместе с CActiveDataProvider. Т.е. вы передаёте ему экземпляр CActiveDataProvider и заголовки столбцов, а он на основе этих данных формирует таблицу.

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

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

Раскрутка сайта занятие увлекательное, но ошибки обойдутся недёшево.

В этой части цикла мы рассмотрим некоторые возможности, которые предоставляет нам Yii фреймворк для отладки приложения.

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

Включаем режим отладки

Для этого во входном скрипте (файл index.php, который находится в корневой папки сайта) константе YII_DEBUG должно быть присвоено значение true.

defined('YII_DEBUG') or define('YII_DEBUG',true);

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

Кстати, эти описания сделаны очень неплохо. Вы увидите не только номер, название ошибки и содержимое стека, но и фрагмент кода в котором она возникла (нужная строка будет подсвечена).

Включаем журналирование ошибок

Тут все настройки выполняются в конфигурационном файле (protected/config/main.php). Фреймворк предлагает нам несколько вариантов ведения лога. Это запись в файл, вывод на экран, запись в базу данных, отправка по eMail.

За ведения лога отвечает компонент приложения CLogRouter. Подключаем и настраиваем его.

'components'=>array(
…
	'log'=>array(
		'class'=>'CLogRouter',
		'routes'=>array(
			array(
				//выводим лог внизу страницы
				'class'=>'CWebLogRoute',
				'levels'=>'trace, info, profile',
			),
		),
	),
…
),

В массиве components мы создали элемент под названием log и присвоили ему массив с настройками. В элементе class указываем название класса, который отвечает за работу компонента. В данном случае это CLogRouter.

Затем настраиваем маршрутизацию (routes). Именно здесь мы определяем куда какие сообщения будут выведены.

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

Параметр levels определяет, что будут выведены сообщения имеющие уровень trace, info или profile. Всего существует пять уровней сообщений: trace, info, profile, warning, error. И с их помощью вы можете отфильтровать ненужную в данный момент информацию.

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

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

Yii::log($message, $level, $category);
Yii::trace($message, $category);

Учтите, что метод trace работает только в режиме отладки. В параметре $message нужно указать текст сообщения, $level – уровень, $category – категория к которой относится сообщение (по-умолчанию равна application, но вы можете указать строку в формате xxx.yyy.zzz, например, system.web.CController, в результате сообщение будет добавляться в лог CController).

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

Отладка запросов к БД

В состав Yii фреймворка входит хорошая библиотека для работы с базой данных. Тем не менее, полезно знать какие именно SQL запросы она формирует. Особенно, если у вас нет предварительного опыта работы с ней.

Для того, чтобы включить вывод запросов в лог, необходимо указать параметр 'enableParamLogging'=>true в настройках базы.

'db'=>array(
…
	'enableParamLogging'=>true,
	'enableProfiling'=>true,
…
),

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

Для того, чтобы вывести результаты профайлинга открываем макет страницы (protected/views/layouts/main.php) и добавляем в хвостовик пару строчек

$dbStats = Yii::app()->db->getStats();
echo 'Выполнено запросов: '.$dbStats[0].' (за '.round($dbStats[1], 5).' сек)';

Как видите, мы получили массив в первом элементе которого хранится общее количество запросов, а во втором – время их выполнения.

Выводим информацию об использовании ресурсов

Эти данные мы тоже выведем в хвостовике страницы

$memory = round(Yii::getLogger()->memoryUsage/1024/1024, 3);
$time = round(Yii::getLogger()->executionTime, 3);
echo '<br />Использовано памяти: '.$memory.' МБ<br />';
echo 'Время выполнения: '.$time.' с<br />';

Для получения этой информации мы использовали класс CLogger. Он содержит два нужных нам метода: memoryUsage (возвращает объём использованной памяти, в байтах) и executionTime – время создания страницы.

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

Все разделы цикла.

1. Yii PHP framework: создаём игровой сайт. Часть 1. Постановка задачи.
2. Yii PHP framework: создаём игровой сайт. Часть 2. База данных и установка фреймворка.
3. Yii PHP framework: создаём игровой сайт. Часть 3. Аутентификация.
4. Yii PHP framework: создаём игровой сайт. Часть 4. Работа с жанрами игр.
5. Yii PHP framework: создаём игровой сайт. Часть 5. Импорт игр.
6. Yii PHP framework: создаём игровой сайт. Часть 6. Формируем страницы игр и жанров.
7. Yii PHP framework: создаём игровой сайт. Часть 7. Работа с JavaScript и страницы игр.
8. Yii PHP framework: создаём игровой сайт. Часть 8. Создаём виджеты.
9. Yii PHP framework: создаём игровой сайт. Часть 9. Поиск ошибок.
10. Yii PHP framework: создаём игровой сайт. Часть 10. Панель управления.
11. Yii PHP framework: создаём игровой сайт. Часть 11. Человекопонятные URL.
12. Архив с исходниками

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

Выбираем систему охлаждения для ПК.

В этой части мы поговорим о том, какие средства предоставляет Yii для создания виджетов. Если верить википедии, виджет (widget) – это "контент модуль, который встраивается в веб-страницу или браузер" (вообще, это не совсем точно, в википедии есть несколько определений).

Правда здесь может возникнуть небольшая путаница в терминологии. Дело в том, что некоторые CMS (WordPress, например) используют термин виджет для обозначения особых плагинов, которые предназначены для отображения блоков с информацией в сайдбаре. Но сейчас нас интересует Yii PHP framework, поэтому мы будем считать виджетами объекты, которые наследуют класс CWidget.

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

Для нас важно, что CWidget имеет особенность. Он является потомком класса CComponent, и, следовательно, является компонентом.

Рассмотрим, как создаются компоненты в фреймворке Yii.

Шаг 1. В папке protected/components создаём файл с классом компонента. Этот класс выполняет инициализацию компонента и подготовку данных (например, чтение из БД).

Шаг 2. В папке protected/components/views создаём файл с представлением компонента. По-сути это шаблон, который используется для отображения содержимого компонента.

Шаг 3. Добавляем компонент в макет (layout) нужных страниц сайта. Макеты находятся в папке protected/views/layouts.

Теперь рассмотрим конкретный пример. Создадим виджет, содержащий ссылки на страницы жанров игр.

Назовём класс TypesMenu.

Создаём файл protected/components/TypesMenu.php.

class TypesMenu extends CWidget {
	public function run() {
		$types = Types::model()->findAll();

		$this->render('typesMenu',array('types'=>$types));
	}
}

Как видите, класс содержит один метод (run), который будет вызван фреймворком при создании виджета.

В этом методе мы получаем список всех жанров игр (строка 3) и результат передаём представлению (строка 5).

Создаём представление (файл protected/components/views/typesMenu.php).

<h2>Жанры</h2>
<ul>
<?php
foreach ($types as $type) {
	//каждый пункт списка - ссылка на страницу с играми данного жанра
	//жанр указывается с помощью параметра в get запросе - type_id
	echo '<li>'.CHtml::link($type->t_name, array('games/list', 'type_id'=>$type->t_id)).'</li>';
}
?>
</ul>

Обратите внимание, у нас доступна переменная $types. (её название мы указали при загрузке представления, метод render).

Сами ссылки создаём с помощью метода CHtml::link. В первом параметре указываем текст ссылки, а во втором – массив с параметрами. В данном случае будут созданы url вида
http://yiigame.domen/index.php?r=games/list&type_id=1
где type_id – id соответствующего жанра.

Вставляем виджет в макет страницы. Для этого в файл protected/views/layouts/main.php добавляем следующий код.

<div class="menu">
<?php $this->widget('application.components.TypesMenu'); ?>
</div><!-- menu -->

Посмотрите, как указано имя виджета. Перед названием файла виджета (без расширения) мы добавляем application.components, проще говоря, указываем путь к виджету.

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

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

Популярность игры мы можем определить, используя поле g_rate (таблица ygs_games), т.е. нам нужно будет при поиске игр в базе просто отсортировать их по этому полю.

Показывать виджет нам нужно на страницах с общим перечнем игр и страницах отдельных жанров. И те, и другие страницы формирует метод actionList (класс GamesController). Но на страницах жанров мы будем показывать топ игр, которые относятся к данному жанру, а не все подряд, т.е. в наш запрос нужно будет добавить дополнительное условие.

Если задача ясна, приступаем.

Создаём файл виджета protected/components/TopGames.php.

class TopGames extends CWidget {

	public $title = 'Популярные игры';
	public $showOn = array();
	public $count = 10;

	public function run() {
		//определяем название контроллера и метода (action)
		$controller = Yii::app()->controller->id;
		$action = Yii::app()->controller->action->id;
		//проверяем нужно ли показывать виджет
		if (!in_array($controller.'/'.$action, $this->showOn)) {
			return;
		}
		//проверяем, нужно ли выводить игры только данного жанра
		if (isset($_GET['type_id'])) {
			$id = $_GET['type_id'];
			$params = array('limit'=>$this->count,'order'=>'g_rate DESC'
				,'condition'=>'t_id=:id'
				,'params'=>array(':id'=>$id));
			//ищем игры
			$games = Games::model()->getTopGames($params)->published()->with('ygs_types')->findAll();
		} else {
			$params = array('limit'=>$this->count,'order'=>'g_rate DESC');
			//ищем игры
			$games = Games::model()->getTopGames($params)->published()->findAll();
		}

		//заполняем массивы с жанрами игр для каждой найденной игры
		//для этого раскодируем поле g_type
		foreach ($games as $key=>$game) {
			$games[$key]->g_types = Yii::app()->controller->_decodeTypes($game->g_type);
		}
		//показываем виджет
		$this->render('topGames'
			, array('title'=>$this->title, 'games'=>$games));
	}
}

Прежде всего, обратите внимание на три свойства класса $title, $showOn и $count. Фреймворк позволяет указывать значения для всех отрытых (public) свойств виджета при его создании, т.е. в макете (layout) мы можем задать значения для этих свойств. Таким образом, появляется возможность изменять вид виджета, не трогая его код.

В данном случае в свойстве $title мы указываем заголовок виджета, в свойстве $showOn – массив с перечнем страниц, на которых он должен отображаться, а в свойстве $count – количество игр.

Рассмотрим метод run.

Прежде всего, определяем название контроллера и метода (action) (строки 9, 10). И проверяем, нужно ли показывать виджет. Страницы, на которых нужно отображать виджет указываются в формате «название_контроллера/название_метода». Если массив $showOn не содержит подходящего элемента, мы завершаем работу виджета.

В противном случае, мы:

1) Проверяем, является ли эта страница, страницей жанра (получен параметр $_GET['type_id'] или нет). Если получен, формируем запрос, при этом в его параметрах мы указываем, что нам нужны игры только текущего жанра.

2) Если мы находимся на странице с общим перечнем игр, то просто получаем игры, отсортированные по полю g_rate.

Обратите внимание на метод getTopGames($params). Он объявлен в модели (Games) и нужен только для того, чтобы немного сократить запись запроса.

public function getTopGames($params) {
	$this->getDbCriteria()->mergeWith($params);
	return $this;
}

Примечание. Использовать его не обязательно. Можно было просто создать объект CDbCriteria, как мы и делали в предыдущих частях, но я хотел попробовать разные варианты работы.

3) Расшифровываем поле с перечнем жанров (эту операцию мы рассматривали в предыдущих частях).

4) Показываем представление при этом передаём ему заголовок виджета и данные игр.

Само представление выглядит так (файл protected/components/view/topGames.php).

<h1><?php echo $title; ?></h1>

<?php
$i = 0;
foreach($games as $n=>$model) {
	//шаблон для вывода игры находится в views/games/_short_desc.php
	$this->controller->renderPartial('_short_desc', array('game'=>$model));
	if ($i % 2 !== 0) {
		echo '<div class="clear"></div>';
	}
	$i++;
}
?>

Как видите, для вывода игры мы использовали представление, которое относится к контроллеру Games (views/games/_short_desc.php).

Последний шаг – подключение шаблона в макете (файл protected/views/layouts/main.php)

<div id="top_games" class="grid_9">
<?php $this->widget('application.components.TopGames'
	, array('title'=>'Популярные игры'
		,'showOn'=>array('games/list','types/show')
		,'count'=>4)); ?>
</div><!-- top_games -->

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

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

Продолжение следует

Все разделы цикла.

1. Yii PHP framework: создаём игровой сайт. Часть 1. Постановка задачи.
2. Yii PHP framework: создаём игровой сайт. Часть 2. База данных и установка фреймворка.
3. Yii PHP framework: создаём игровой сайт. Часть 3. Аутентификация.
4. Yii PHP framework: создаём игровой сайт. Часть 4. Работа с жанрами игр.
5. Yii PHP framework: создаём игровой сайт. Часть 5. Импорт игр.
6. Yii PHP framework: создаём игровой сайт. Часть 6. Формируем страницы игр и жанров.
7. Yii PHP framework: создаём игровой сайт. Часть 7. Работа с JavaScript и страницы игр.
8. Yii PHP framework: создаём игровой сайт. Часть 8. Создаём виджеты.
9. Yii PHP framework: создаём игровой сайт. Часть 9. Поиск ошибок.
10. Yii PHP framework: создаём игровой сайт. Часть 10. Панель управления.
11. Yii PHP framework: создаём игровой сайт. Часть 11. Человекопонятные URL.
12. Архив с исходниками

Сегодня я продолжу рассказывать о плагине jqGrid и покажу еще один пример его использования.

Если не ошибаюсь, это уже 5-ый пост об этом плагине, поэтому я не буду останавливаться на его установке и настройке. Лучше приведу ссылки на предыдущие части:

1) Query Grid Plugin – "продвинутое" решение для создания таблиц

2) jqGrid: редактирование табличных данных с помощью inline редакторов

3) jqGrid – создание дополнительных кнопок

4) jqGrid – поиск данных

Но для тех, кто их не читал, кратко поясню, о чем вообще речь.

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

Естественно, у плагина очень много настроек и вариантов использования, но это не означает, что их хватит на все случаи жизни

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

Как это работает, вы можете посмотреть на демо-страничке

либо скачать архив с примером и установить его на своем сервере

Реализовать такую систему не сложно.

Потребуются:

1) Библиотека jQuery.

2) Плагин jqGrid.

3) Плагин для создания поля с автозаполением. Я выбрал Ajax AutoComplete for jQuery.

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

1) Клиентская часть. Тут нам нужно создать только страничку с таблицей и формой, которая содержит поле с автозаполнением (index.html).

1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
2. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
3.  
4. <head>
5.   <title>jqGrid + Autocomplete</title>
6.  
7.   <meta http-equiv="content-type" content="text/html;charset=utf-8" />
8.   <meta http-equiv="Content-Style-Type" content="text/css" />
9.  
10.   <link rel="stylesheet" type="text/css" media="screen" href="css/reset.css" />
11.   <link rel="stylesheet" type="text/css" media="screen" href="css/smoothness/jquery-ui-1.7.2.custom.css" />
12.   <link rel="stylesheet" type="text/css" media="screen" href="css/ui.jqgrid.css" />
13.   <link rel="stylesheet" type="text/css" media="screen" href="css/styles.css" />
14. </head>
15. <body>
16. <div id="container">
17.   <h1>jqGrid + Autocomplete</h1>
18.   
19.   <table id="list"></table>
20.   <div id="pager"></div>
21.   
22.   <form action="#" method="post" id="autocomplete_form">
23.     <p>
24.     <label for="city_field">Название города</label>
25.     <input type="text" id="city_field" name="city_field" size="20" />
26.     </p>
27.   </form>
28.   ...
29. </div>
30. </body>
31. </html>

* This source code was highlighted with Source Code Highlighter.

* This source code was highlighted with Source Code Highlighter.

2) Подключение и настройка плагинов. Этот код добавляем в конец файла index.html перед закрывающим тегом body.

1. <script src="js/jquery-1.3.2.min.js" type="text/javascript"></script>
2. <script src="js/jquery-ui-1.7.2.custom.min.js" type="text/javascript"></script>
3. <script src="js/i18n/grid.locale-ru.js" type="text/javascript"></script>
4. <script src="js/jquery.jqGrid.min.js" type="text/javascript"></script>
5. <script src="js/jquery.autocomplete-min.js" type="text/javascript"></script>
6. <script type="text/javascript">
7. $(function() {
8.   //настройка плагина jqGrid
9.   jQuery("#list").jqGrid({
10.    url:'getdata.php',
11.    datatype: 'json',
12.    mtype: 'POST',
13.    colNames:['Город','Страна'],
14.    colModel :[
15.     {name:'city', index:'city', width:350},
16.     {name:'country', index:'country', width:350}
17.    ],
18.    pager: '#pager',
19.    rowNum:10,
20.    rowList:[10,20,30],
21.    sortname: 'country',
22.    sortorder: 'desc',
23.    viewrecords: true,
24.    caption: 'Города Украины и России'
25.   }).navGrid('#pager', {edit:false,add:false,del:false,refresh:true,search:false});
26.   
27.   //эта функция добавляет GET параметр в запрос на получение
28.   //данных для таблицы и обновляет её
29.   function updateTable(value) {
30.     jQuery("#list")
31.       .setGridParam({url:"getdata.php?sel_city="+value, page:1})
32.       .trigger("reloadGrid");
33.   }
34.   
35.   //настройка плагина Autocomplete
36.   //при возникновении события onSelect вызываем функцию updateTable
37.   $('#city_field').autocomplete({
38.     serviceUrl:'search.php',
39.     maxHeight:150,
40.     onSelect: function(value) {
41.       updateTable(value);
42.     }
43.   });
44.   
45.   //этот обработчик используется если посетитель ввел название города
46.   //и нажал Enter
47.   $('#autocomplete_form').submit(function() {
48.     updateTable($('#city_field').val());
49.     return false;
50.   });
51. });
52. </script>

* This source code was highlighted with Source Code Highlighter.

Для демонстрационных целей я использовал урезанную базу данных городов России и Украины, поэтому таблица содержит 2 поля: название города и название страны. На настройках отображения полей и таблицы я останавливаться не буду, т.к. уже об этом рассказывал.

Тут гораздо интереснее другой момент – источники данных.

И для поля, и для таблицы данные приходят в JSON формате, но для таблицы их формирует скрипт getdata.php, а для поля - search.php. Почему используются разные скрипты? Дело в том, что для плагина автозаполнения нужно меньше данных (только название города), чем для таблицы, и их структура отличается, а вводить какие-нибудь специальные параметры в запрос мне показалось не самым лучшим решением.

3) Связываем плагины между собой. Тут нам нужно чтобы при выборе посетителем города из списка произошло обновление данных в таблице.

Для этого мы в обработчик события onSelect (строки 40-42) добавили вызов функции updateTable и передали ей название города.

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

Для этого с помощью метода setGridParam изменяем параметр url на
getdata.php?sel_city="+value
т.е. мы добавили GET параметр sel_city.
Затем вызываем метод trigger("reloadGrid"), который запускает обновление таблицы.

Еще я добавил вызов функции updateTable в обработчик отправки формы (строки 47-50). На случай если пользователь введет название города и нажмет Enter.

4) Создаем серверные скрипты.

Для автозаполнения (search.php)

1. <?php
2. require_once('dbdata.php');
3.  
4. try {
5.   //читаем параметры
6.   $s_query = $_GET['query'];
7.   
8.   //подключаемся к базе
9.   $dbh = new PDO('mysql:host='.$dbHost.';dbname='.$dbName, $dbUser, $dbPass);
10.   //указываем, что нужно использовать utf8
11.   $dbh->exec('SET CHARACTER SET utf8');
12.  
13.   $stmt = $dbh->prepare('SELECT city FROM cities WHERE city LIKE :query');
14.   $search = $s_query.'%';
15.   $stmt->bindParam(':query', $search);
16.   $stmt->execute();
17.   
18.   $i=0;
19.   $response->query = $s_query;
20.   $response->suggestions = array();
21.   while($row = $stmt->fetch(PDO::FETCH_ASSOC)) {
22.     $response->suggestions[]=$row['city'];
23.   }
24.   echo json_encode($response);
25. }
26. catch (PDOException $e) {
27.   echo 'Database error: '.$e->getMessage();
28. }
29.  
30. // end of search.php

* This source code was highlighted with Source Code Highlighter.

Тут, набранные пользователем буквы мы получаем в параметре $_GET['query'].

После этого выполняется один запрос к базе данных (строки 13-16), который находит список всех городов, начинающихся с этих букв.

Затем мы формируем массив с ответом (строки 19-23) и отправляем его браузеру.

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

Скрипт для заплнения таблицы (getdata.php).

1. <?php
2. require_once('dbdata.php');
3.  
4. try {
5.   //читаем параметры
6.   $curPage = $_POST['page'];
7.   $rowsPerPage = $_POST['rows'];
8.   $sortingField = $_POST['sidx'];
9.   $sortingOrder = $_POST['sord'];
10.   
11.   $selCity = null;
12.   if (isset($_GET['sel_city'])) {
13.     $selCity = $_GET['sel_city'];
14.   }
15.   
16.   //подключаемся к базе
17.   $dbh = new PDO('mysql:host='.$dbHost.';dbname='.$dbName, $dbUser, $dbPass);
18.   //указываем, что нужно использовать utf8
19.   $dbh->exec('SET CHARACTER SET utf8');
20.  
21.   //определяем количество записей в таблице
22.   if (null === $selCity) {
23.     $rows = $dbh->query('SELECT COUNT(id) AS count FROM cities');
24.   } else {
25.     $rows = $dbh->query('SELECT COUNT(id) AS count FROM cities WHERE city='.$dbh->quote($selCity));
26.   }
27.   $totalRows = $rows->fetch(PDO::FETCH_ASSOC);
28.  
29.   $firstRowIndex = $curPage * $rowsPerPage - $rowsPerPage;
30.   //получаем список городов из базы
31.   if (null === $selCity) {
32.     $res = $dbh->query('SELECT * FROM cities ORDER BY '.$sortingField.' '.$sortingOrder.' LIMIT '.$firstRowIndex.', '.$rowsPerPage);
33.   } else {
34.     $res = $dbh->query('SELECT * FROM cities WHERE city='.$dbh->quote($selCity).' ORDER BY '.$sortingField.' '.$sortingOrder.' LIMIT '.$firstRowIndex.', '.$rowsPerPage);
35.   }
36.   
37.   //сохраняем номер текущей страницы, общее количество страниц и общее количество записей
38.   $response->page = $curPage;
39.   $response->total = ceil($totalRows['count'] / $rowsPerPage);
40.   $response->records = $totalRows['count'];
41.  
42.   $i=0;
43.   while($row = $res->fetch(PDO::FETCH_ASSOC)) {
44.     $response->rows[$i]['id']=$row['id'];
45.     $response->rows[$i]['cell']=array($row['city'], $row['country']);
46.     $i++;
47.   }
48.   echo json_encode($response);
49. }
50. catch (PDOException $e) {
51.   echo 'Database error: '.$e->getMessage();
52. }
53.  
54. // end of getdata.php

* This source code was highlighted with Source Code Highlighter.

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

Обратить внимание нужно на обработку параметра sel_city (строки 12, 22 и 31).

Если этот параметр получен, то в запрос на поиск данных мы добавляем условие WHERE city=…, если нет – берем из базы все города подряд.

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

Инструкции по установке и настройке примера есть в архиве.

И, конечно, я буду рад услышать ваше мнение

UPD 21.06.2010 В этом примере обнаружилась недоработка. Оказалось, что IE не хочет передавать название города в UTF-8 (название вставляется в URL, т.е. на сервер приходит в GET параметре). Для решения необходимо перед отправкой закодировать название города с помощью encodeURIComponent (в браузере) и раскодировать с помощью rawurldecode (на сервере).

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

Несколько способов о том как заработать студенту в наше время.

Руководителям: оказание услуг бухучета позволяет сэкономить на штатном бухгалтере

Приветствую всех!

Сегодня я хочу рассказать о небольшой ORM библиотеке под названием RedBean с которой я на днях экспериментировал.

Прежде всего, пару слов о ORM (англ. Object-relational mapping, русск. Объектно-реляционная проекция) вообще.

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

Дело в том, что все данные в БД хранятся в таблицах (аналог двумерных массивов), а объекты могут быть организованы в сложные иерархии (например, объект типа «Post» может содержать массив объектов типа «Comment»). И для того, чтобы сохранить такую структуру в БД нужно использовать несколько таблиц с дополнительными полями, которые устанавливают связи между записями.

Все это увеличивает сложность SQL запросов и время разработки.

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

Вернемся к RedBean.

Проиллюстрировать работу любой библиотеки проще всего на примере. Поэтому я написал небольшой скрипт.

<?php
include 'oodb.php';

//подключаемся к БД
RedBean_Setup::kickstartDev('Post,Comment','mysql:host=localhost;dbname=my_database', 'user_name', 'password');

$post = new Post();
$post->title = 'Новая запись';
$post->content = 'Просто какой-то текст';
$id = $post->save();

$comment = new Comment;
$comment->author = 'admin';
$comment->text = 'Очень простой комментарий';
$comment->belongsTo($post);
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="language" content="en" />
<title>Test RedBean</title>
</head>

<body>

<ul>
<?php
$posts = Post::listAll();
foreach ($posts as $post) {
	$curPost = new Post($post['id']);
	echo '<li><strong>'.$curPost->getTitle().'</strong><br />';
	echo $curPost->getContent();
	$comments = $curPost->getRelatedComment();
	echo '<ol>';
	foreach ($comments as $comment) {
		echo '<li>'.$comment->text.' ('.$comment->author.')</li>';
	}
	echo '</ol></li>';
}
?>
</ul>

</body>
</html>

Посмотрим, что он делает.

1) Подключаем библиотеку (строка 2). Тут объяснять нечего, RedBean состоит всего из одного файла.

2) Подключаемся к базе данных и создаем объекты, которые будем в ней хранить (строка 5).
Обе операции выполняются с помощью метода kickstartDev. В первом параметре мы указываем перечень нужных объектов (они будут создаваться динамически). В остальных параметрах – данные, необходимые для подключения к базе (dns, имя пользователя и пароль).

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

Примечание. Метод kickstartDev переводит библиотеку в т.н. fluid режим. При этом если вы измените, количество или названия свойств объектов, то RedBean автоматически изменит структуру таблиц в БД. Этот режим имеет смысл использовать во время разработки. После переноса приложения на «боевой» сервер kickstartDev лучше заменить на kickstartFrozen. Библиотека перейдет во frozen режим, при этом таблицы автоматически изменяться не будут, но и потребление ресурсов сократится.

3) Создаем данные и сохраняем их в БД (строки 7-15).

В данном случае создано два объекта типов Post и Comment, каждый из которых содержит несколько свойств.
Обратите внимание, что свойства создаются автоматически. От нас требуется указать только название свойства и его значение.
Мы просто присваиваем значения нужным свойствам и вызываем метод save(), который записывает объект в БД (строка 10).

Объект Comment принадлежит Post. Эту связь мы устанавливаем с помощью метода belongsTo. При этом использовать save не нужно. Сохранение в БД произойдет автоматически.

4) Читаем данные из базы (строки 29-40).
Тут тоже все достаточно прозрачно. С помощью статического метода listAll мы получаем массив со всеми объектами типа Post, находящимися в БД.

Чтобы получить доступ к комментариям мы создаем объект типа Post (строка 31) и при этом в качестве параметра указываем id.

После этого мы можем использовать метод getRelatedComment для получения массива с комментариями.
Примечание. Название метода getRelatedComment формируется следующим образом. К приставке getRelated добавляется имя объекта, который мы хотим получить.

Затем в цикле мы выводим комментарии.

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

Теперь посмотрим, что у нас делается с базой данных.

Прежде всего, взгляните на перечень таблиц.

Как видите, RedBean создал 6 таблиц. Три из них (post, comment_post и comment) используются для хранения данных приложения, остальные – используются самой RedBean.

Теперь посмотрим, что сохранено в самих таблицах.

post

comment_post

comment

Думаю, вы уже догадались, в чем дело.

Между объектами Post и Comment отношение типа ОДИН-К-МНОГИМ и для его реализации не нужна промежуточная таблица. Т.е. если бы база создавалась вручную, мы бы обошлись всего двумя таблицами. Соответственно, упрощаются и SQL запросы.

Использовать или не использовать?

Это вопрос философский . RedBean не единственная ORM библиотека. Например, существуют более мощные Propel и Doctrine.

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

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

В общем, думаю, что в ряде случаев использование RedBean будет вполне оправданно.

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