Блог обыкновенный

Правильный символ тенге в вебе

resurtm@gmail.com (resurtm) — Tue, 21 Feb 2012 20:36:16 +0600

Введение

Часто бывает так, что при верстке нам нужен правильный символ тенге. Хорошо, когда разработчик или владелец сайта понимает, что символ «╤» — это символ псевдографики, а не символ тенге, потому как получить его в тексте (без помощи inline элемента <img>) можно довольно просто и быстро. Для этого нам понадобится:

Шрифт в формате TrueType для которого мы хотим сделать символ тенге;
Набор символов тенге для разных шрифтов, подготовленных Анатолием Карасовым и Ярославом Седышевым в формате OpenType. Скачать его можно тут: tenge.zip;
Редактор шрифтов (напр. FontLab Studio пятой версии).

Для примера мы возьмем обычный Times New Roman с засечками. Приступим.

Подготовка шрифта

1. Открываем times.ttf и tenge.otf в FontLab Studio:

2. В times.ttf ищем глифы кириллической «г» в нижнем регистре (U+0433, Cyrillic Small Letter Ghe) и точки (U+002E, Full Stop).

3. Удаляем все кривые в обоих глифах и устанавливаем толщину каждому из них в ноль. Зачем это нужно — будет показано дальше.

4. Теперь ищем глиф символа тенге в tenge.otf для Times New Roman. Судя по tenge.txt внутри tenge.zip, tenge.otf — это глиф с номером U+0050 (Latin Small Letter P). Копируем этот глиф в буфер обмена операционной системы.

5. Возвращаемся к times.ttf и ищем малую кириллическую «т» (U+0442, Cyrillic Small Letter Te). Ее заменяем на тот глиф, что находится сейчас у нас в буфере обмена. Результат операции:

6. Сам шрифт почти готов. Осталось скомпилировать его в новый шрифт формата TrueType и можно приступать к верстке. Компилируем и сохраняем его как times-tenge.ttf.

Верстка

Ничего сложного и необычного в верстке нет. Каскадные стили:

@font-face{
	font-family:Times New Roman Tenge;
	/* для нормального начертания, не жирное и не курсивное */
	font-style:normal;
	font-weight:normal;
	src:url(/fonts/times-tenge.eot);
	src:url(/fonts/times-tenge.eot?iefix) format('☺'),
		url(/fonts/times-tenge.woff) format('woff'),
		url(/fonts/times-tenge.ttf) format('truetype'),
		url(/fonts/times-tenge.svg#times-tenge) format('svg');
}
p{
	font-family:Times New Roman;
	font-size:24px;
}
p span.tenge{
	font-family:Times New Roman Tenge;
}

Разметка:

<p>Красивые женские сапоги. Цена 16 000 <span class="tenge">тг.</span>, размеры 36, 37, 38, 39.</p>

Результат:

Красивые женские сапоги. Цена 16 000 тг., размеры 36, 37, 38, 39.

Сконвертировать наш шрифт из формата TrueType в Embedded OpenType, WOFF и SVG можно много где в сети.

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

Данный способ работает во всех браузерах, которые поддерживают встраиваемые шрифты, а в их число входит и Microsoft Internet Explorer шестой версии. Хотя, конечно, для него приходится конвертировать шрифт в формат Embedded OpenType. :-)

Дополнения и замечания по данному способу приветствуются.

Правильная интеграция KFM (Kae’s File Manager) с Yii

resurtm@gmail.com (resurtm) — Wed, 28 Sep 2011 03:55:49 +0600

Правильная интеграция KFM (Kae’s File Manager) с Yii

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

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

Для начала нужно создать новое действие actionIsAuthenticated в основном контроллере приложения управления сайтом:

class SiteController extends BackendController
{
    // фильтры контроллера
    public function filters()
    {
        return array(
            'accessControl',
            'postOnly + logout',
        );
    }
 
    // настраиваем права доступа к действиям контроллера
    public function accessRules()
    {
        return array(
            // isAuthenticated доступен всегда и всем
            array('allow', 'actions'=>array('isAuthenticated'), 'users'=>array('*')),
 
            // страница логина доступна только не аутентифицированным пользователям
            array('allow', 'actions'=>array('login'), 'users'=>array('?')),
            array('deny', 'actions'=>array('login'), 'users'=>array('*')),
 
            // остальные действия по умолчанию доступы только аутентифицированным пользователям
            array('allow', 'users'=>array('@')),
            array('deny', 'users'=>array('*')),
        );
    }
 
    // главная страница системы управления
    public function actionIndex()
    {
        $this->render('index');
    }
 
    // ...
 
    // выход из системы управления сайтом
    // доступен только по HTTP POST
    public function actionLogout()
    {
        Yii::app()->user->logout();
        $this->render('logout');
    }
 
    // возвращает статус аутентификации пользователя
    public function actionIsAuthenticated()
    {
        $this->layout='';
        echo Yii::app()->user->isGuest ? 'no' : 'yes';
    }
}

Теперь открываем и редактируем конфигурационный файл KFM configuration.php. Нужно добавить следующий код в самом начале этого файла:

$curl=curl_init();
curl_setopt($curl, CURLOPT_URL, 'http://'.$_SERVER['HTTP_HOST'].'/backend/site/isAuthenticated');
curl_setopt($curl, CURLOPT_RETURNTRANSFER , 1);
curl_setopt($curl, CURLOPT_COOKIE , 'PHPSESSID='.$_COOKIE['PHPSESSID']);
$status=curl_exec($curl);
if(curl_errno($curl))
    $status='';
curl_close($curl);
 
if($status!='yes')
    die;

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

Реестр в Yii

resurtm@gmail.com (resurtm) — Tue, 27 Sep 2011 21:32:36 +0600

Введение

Это вольный перевод вики-статьи Yii registry, how to use it, is it exists at all.

Время от времени люди интересуются использованием реестра в том или ином фреймворке. Если вы использовали ранее, например, Zend Framework, то более чем вероятно, что пользовались кодом:

Zend_Registry::get('paramName');
Zend_Registry::set('paramName');

Реестр в Yii

В Yii тоже существует своя реализация реестра. Изменить существующее или задать новое значение реестра можно так:

Yii::app()->params['paramName']='paramValue';

Получить значение из реестра можно следующим образом:

echo Yii::app()->params['paramName'];

Получение всех значений реестра:

Yii::app()->getParams();
Yii::app()->params;

Можно использовать удобный класс CVarDumper:

CVarDumper::dump(Yii::app()->getParams(), 10, true);

Если вы используете CVarDumper, то вывод будет выглядеть примерно так:

CAttributeCollection#1
(
    [caseSensitive] => true
    [CMap:_d] => array
    (
        'abc' => 123
        'a' => 123
        'c' => 1316855672
        'd' => 'cookie'
    )
    [CMap:_r] => false
    [CComponent:_e] => null
    [CComponent:_m] => null
)

Возможно и массовое присваивание значений посредством массива:

Yii::app()->setParams(array('a'=>123, 'c'=>time(), 'd'=>'cookie'));

Для удаления можно воспользоваться стандартной функцией unset:

unset(Yii::app()->params['abc']);

CMap

Т.к. атрибут params является экземляром класса CMap, то мы имеем в наличии множество методов, которые упрощают нам работу в целом.

Общее количество установленных значений (для примера выше распечатает значение 4):

echo Yii::app()->params->getCount();

Код выше делает тоже самое, что и примеры ниже.

echo Yii::app()->params->count;
echo Yii::app()->params->count();

Можно получить только перечень ключей реестра:

Yii::app()->params->keys;

Вызов выше возвратит массив со следующим содержимым:

'0' => 'abc'
'1' => 'a'
'2' => 'c'
'3' => 'd'

Функция unset уже была упомянута выше, но тем не менее удалять значения можно и так:

Yii::app()->params->remove('abc');

Удаление вообще всех значений в реестре:

Yii::app()->params->clear();

Совет №1

Получение значения атрибута вызовом ->params является тем же самым, что и вызов метода ->getParams(). Присваивание значения атрибуту в виде params['sdf']=$val является тем же самым, что и вызов метода setParams('sdf', $val). Это правило действует и для всего фреймворка в целом: магический метод выполняет всю магию сам. Просто добавьте к классу, который был унаследован от CComponent, метод getSomething и вы сможете использовать одноименный атрибут something, получать и присваивать значения которого можно так:

$object->something=100;
echo $object->something;

Совет №2

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

return array(
    // ...
    'params'=>array('abc'=>123),
    // ...
);

Начальные параметры можно выделить в отдельный конфигурационный файл params.php, а затем можно просто подключить его из основного конфигурационного файла. Для PHP версии 5.3 или выше:

'params'=>require(__DIR__.'/params.php'),

Для PHP версии ниже 5.3:

'params'=>require(dirname(__FILE__).'/params.php'),

Файл config/params.php будет содержать следующий код:

return array(
    'abc' =>123,
);

Как отображать статичные страницы в Yii?

resurtm@gmail.com (resurtm) — Mon, 15 Aug 2011 13:54:37 +0600

Данная заметка является вольным переводом вики-статьи How to display static pages in Yii.

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

Можно хранить такие страницы в виде простых отдельных HTML файлов. Веб сервер будет отправлять такие страницы напрямую конечным пользователям минуя PHP. Недостаток данного подхода заключается в том, что в этом случае поддержка общего шаблона и кода между такими статичными и другими динамическими страницами сайта очень сильно усложняется.
Другим способом решения проблемы является написание новых экшнов контроллера, соответствующих каждой новой странице. Это решает проблему с общим шаблоном, однако процесс сводится к рутине: каждый раз мы должны писать новый экшн для каждой страницы, который ничего, кроме вывода шаблона и не делает (противоречие принципу DRY).
Мы можем воспользоваться стандартным классом фреймворка CViewAction для создания таких страниц. Данная заметка описывает именно этот подход.

Для начала в контроллере по умолчанию SiteController (или в любом другом контроллере, который вам нужен) переопределите метод actions():

public function actions()
{
    return array(
        'page'=>array(
            'class'=>'CViewAction',
        ),
    );
}

Код выше определяет внешний экшн page у текущего контроллера, классом которого является CViewAction. Добавление внешних экшнов контроллеров описано в руководстве.

Затем создайте директорию protected/views/site/pages.

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

Мы закончили! Наша страница about должна быть доступна данной ссылке:

http://www.example.com/index.php?r=site/page&view=about

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

Если у нас имеется множество страниц, то мы можем разместить их в под-директориях в protected/views/site/pages. Страница, которая расположена на диске в директории protected/views/site/pages/help/contact.php будет доступна по ссылке:

http://www.example.com/index.php?r=site/page&view=help.contact

Если CViewAction работает не так, как вам нужно, то его поведение можно изменить. Более подробно класс CViewAction описан в документации по API фреймворка.

Расширяемая структура директорий в Yii

resurtm@gmail.com (resurtm) — Sat, 13 Aug 2011 17:51:44 +0600

Это адаптированный вольный перевод вики-статьи The directory structure of the Yii project site. Дополнения и багфиксы приветствуются.

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

Общая структура

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

/
    backend/
    common/
        components/
        config/
            params.php
            params-local.php *
        lib/
            Pear/
            yii/
            Zend/
        migrations/
        models/
            Comment.php
            Extension.php
            ...
    console/
        commands/
            SitemapCommand.php
            ...
        config/
            main.php
            main-local.php *
            params.php
            params-local.php *
        runtime/
        yiic.php *
    frontend/
        components/
        config/
            main.php
            main-local.php *
            params.php
            params-local.php *
        controllers/
            SiteController.php
            ...
        lib/
        models/ 
            ContactForm.php
            SearchForm.php      
        runtime/
        views/
            layouts/
            site/
        www/
            assets/
            css/
            js/
            index.php *
    yiic
    yiic.bat

В командной разработке мы должны использовать какую-либо систему контроля версий (git, Subversion, Mercurial и т.д.) для кода разрабатываемого проекта. Файлы, помеченные звездочками в структуре директорий выше, не должны находиться в репозитории системы контроля версий (почему, поясняется ниже).

Директории верхнего уровня

На верхнем уровне мы имеем 4 директории:

backend: приложение-бэкэнд предназначенное для управления и администрирования всей системы;
frontend: приложение-фронтенд, которое содержит в себе основной функционал системы для конечных пользователей;
console: консольное приложение с консольными командами;
common: директория, содержащая все те вещи, которые используются в более чем одном приложении системы.

Мы делим всю систему на три приложения: backend, frontend и console. Если появится необходимость в добавлении нового приложения (например, приложение api, которое будет предоставлять API сайта в виде веб-сервиса), то нужно просто добавить новую директорию верхнего уровня с нужной внутренней структурой директорий. Директорию common мы используем для хранения файлов, которые будут использоваться в нескольких приложениях проекта.

Директории приложений

Структуры директорий всех приложений схожи. Приложения frontend и backend имеют следующие директории:

components: содержит компоненты (хелперы и виджеты) которые используются только в данном приложении;
config: настройки приложения;
controllers: тут находятся контроллеры приложения;
lib: здесь размещаются сторонние библиотеки, используемые только в данном приложении;
models: содержит в себе модели классов, специфичные для данного приложения;
runtime: хранит динамически генерируемые файлы во время выполнения приложения;
views: тут находятся шаблоны действий контроллеров;
www: корневая директория хоста веб-сервера данного приложения.

Структура директорий консольного приложения console выглядит иначе, потому как это приложение не нуждается в контроллерах, шаблонах и директории хоста веб-сервера (controllers, views и www соответственно). В отличие от других приложений консольное приложение содержит директорию commands в которой находятся файлы классов консольных команд.

Общая директория

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

Чтобы упростить поддержку кода, организация структуры директорий в common примерно такая же, как и в приложениях. Например, вполне возможно, что там будут такие директории, как components, models, lib и прочие.

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

Во время создания крупных проектов с длинным циклом разработки нам периодически приходится менять структуру базы данных. Потому мы используем функционал миграций базы данных для того, чтобы следить за изменениями в ней. Мы храним все эти миграции базы данных в директории migrations внутри общей директории common.

Конфигурации приложений

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

Разные разработчики одного проекта могут иметь разные рабочие окружения (операционные системы, настройки соединения с базой данных, директория проекта могут быть разными). Среда боевого сервера также отлична от сред разработчиков. Для того, чтобы разработчики не мешали друг другу особенностями своих сред, мы разделяем конфигурацию каждого приложения на две части: базовая конфигурация (например, main.php и params.php) и локальная конфигурация (например, main-local.php и params-local.php).

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

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

Для слияния базовой и локальной конфигураций в бутстрап-скрипте index.php мы можем воспользоваться следующим кодом:

require('path/to/yii.php');
$local=require('path/to/main-local.php');
$base=require('path/to/main.php');
$config=CMap::mergeArray($base, $local);
Yii::createApplication($config)->run();

Алиасы путей

Для того, чтобы облегчить обращение к файлам других приложений мы можем создать корневой алиас пути site который указывает на корневую директорию всей системы с 4 приложениями в ней. В результате мы можем использовать алиас site.frontend.models.ContactForm для того, чтобы указать на класс ContactForm который был объявлен в приложении frontend.

Развертывание

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

Боевой сервер можно рассматривать как отдельного разработчика, средой разработки которого и является сам сервер.

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

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

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

Возможный способ ускорения работы PHPUnit тестов

resurtm@gmail.com (resurtm) — Sat, 13 Aug 2011 17:49:46 +0600

Если в файле phpunit.xml директории для тестирования (XPath: /phpunit/filter) указывать через whitelist, а не через blacklist путем запрета тестирования определенных директорий, то можно хорошо ускорить процесс тестирования приложения.

Например вот так будет довольно медленно:

<?xml version="1.0" encoding="UTF-8"?>
<phpunit bootstrap="bootstrap.php" colors="false" convertErrorsToExceptions="true" convertNoticesToExceptions="true"
        convertWarningsToExceptions="true" stopOnFailure="false">
    <selenium>
        <browser name="Firefox" browser="*firefox"/>
        <!--<browser name="Internet Explorer" browser="*iexplore"/>-->
    </selenium>
 
    <filter>
        <blacklist>
            <directory suffix=".php">C:/php</directory>
            <directory suffix=".php">../../common</directory>
            <directory suffix=".php">../../framework</directory>
            <directory suffix=".php">../forms</directory>
            <directory suffix=".php">../tests</directory>
        </blacklist>
    </filter>
 
    <logging>
        <log type="coverage-html" target="./report"/>
    </logging>
</phpunit>

Вывод Ant:

Buildfile: C:\_work\eclipse\anotherproject.kz\build.xml
props:
unit-tests:
     [echo] Running unit tests.
     [exec] PHPUnit 3.5.13 by Sebastian Bergmann.
     [exec] ................................................................. 65 / 82 ( 79%)
     [exec] .................
     [exec] Time: 21 seconds, Memory: 20.75Mb
     [exec] OK (82 tests, 2998 assertions)
     [exec] Generating code coverage report, this may take a moment.
BUILD SUCCESSFUL
Total time: 33 seconds

А вот так уже гораздо быстрее:

<filter>
    <whitelist>
        <directory suffix=".php">../models</directory>
        <directory suffix=".php">../components</directory>
    </whitelist>
</filter>

Вывод Ant:

     [exec] Generating code coverage report, this may take a moment.
BUILD SUCCESSFUL
Total time: 21 seconds

Суть проблемы заключается в том, что в MS Windows PHPUnit сравнительно долго парсит богатые на PHP файлы директории, указанные в blacklist (в моем случае там было указано все, что находилось в include_path, а внутри было много тяжелого). blacklist стоит избегать.

Yii 1.1 Application Development Cookbook

resurtm@gmail.com (resurtm) — Sat, 13 Aug 2011 15:45:20 +0600

Прикупил примерно месяц назад электронный RAW вариант книги Yii 1.1 Application Development Cookbook. Очень хороший сборник рецептов для тех, кому интересны именно наборы tips'n'tricks'ов и улучшение навыков через готовые хорошие примеры.

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

Ждем финального релиза в сентябре. Рекомендую всем Yii'стам. :-)

UPD: Книга наконец релизнулась.

Работа с кукисами в Yii

resurtm@gmail.com (resurtm) — Thu, 11 Aug 2011 20:36:53 +0600

Это адаптированный перевод wiki-страницы Cookie management in Yii.

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

Работа с кукисами

Чтение кукисов

Чтобы прочитать одно значение из кукисов воспользуйтесь следующим кодом:

$cookie = Yii::app()->request->cookies['cookie_name']->value;

Запись кукисов

Записать одно значение в кукисы можно следующим образом:

Yii::app()->request->cookies['cookie_name'] = new CHttpCookie('cookie_name', $value);

Имейте ввиду, что название значения используется дважды. Один раз в конструкторе класса CHttpCookie и во второй раз в ассоциативном массиве cookies.

Удаление кукисов

Значение в кукисах можно удалить так:

unset(Yii::app()->request->cookies['cookie_name']);

Удалить вообще все значения в кукисах можно так:

Yii::app()->request->cookies->clear();

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

Что нужно помнить?

Значения кукисов — это объекты

Значения кукисов в Yii хранятся в объектах класса CHttpCookie. Для того, чтобы получить реальное значение из кукисов нужно воспользоваться атрибутом value класса CHttpCookie. Если вы не сделаете этого, то получите ошибку или предупреждение о том, что объект класса CHttpCookie не может быть сконвертирован в строку.

Безопасное чтение

Так как уже было сказано о том, что кукисы в Yii — это объекты класса CHttpCookie, то в том случае, если нужного значения в кукисах не существует, то и соответствующий объект не будет создан. При попытке получить значение атрибута null-объекта произойдет ошибка Trying to get property of non-object. Чтобы обойти это всегда рекомендуется использовать тернарный оператор для чтения:

$cookie = (isset(Yii::app()->request->cookies['cookie_name']->value)) ?
    Yii::app()->request->cookies['cookie_name']->value : '';

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

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

$is_cookie = !isset(Yii::app()->request->cookies['cookie_name']->value);

Перезагрузка страницы

Помните, что в действительности сервер ничего сам не делает с кукисами. Он только информирует браузер (в HTTP ответе) о том, что кукисы каким-то образом изменились. Браузер отвечает за большую часть работы с кукисами.

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

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

Проблема истечения кукисов

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

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

$cookie = new CHttpCookie('cookie_name', $value);
$cookie->expire = time()+60*60*24*180; 
Yii::app()->request->cookies['cookie_name'] = $cookie;

Как видите мы устанавливаем дату истечения относительно текущего времени (первый подводный камень) и в виде UNIX timestamp, а не в виде форматированных даты и времени (второй подводный камень). Потому в примере выше мы используем PHP функцию time().

Мы считаем время истечения только в секундах (третий подводный камень), потому в примере выше дата будет равняться текущему времени плюс 180 дней (15 552 000 секунд). Для программиста, разумеется, понятнее будет если мы запишем эти полгода в виде математического выражения, а не просто в виде одного числа.

Количество секунд в разных, часто используемых, временных единицах:

час: 3 600 секунд;
день: 86 400 секунд;
неделя: 6 048 000 секунд;
месяц (30 дней): 2 592 000 секунд;
полгода (6 месяцев по 30 дней): 15 552 000 секунд;
год (12 месяцев по 30 дней): 31 104 000 секунд.

Кукисы в Javascript

Обычно, вы имеете доступ к вашим кукисам как из PHP кода, так и из Javascript кода. Так как Javascript выполняется в браузере, то и проблем с перезагрузкой страниц здесь нет.

httpOnly

Атрибут CHttpCookie.httpOnly определяет то, является ли значение кукисов доступным только в PHP коде. Значение по умолчанию «ложь» (false). При установке этого значения в «истину» (true) вы повышаете безопасность вашего приложения (это предовращает возможность получения значения кукисов посредством XSS), но ваши кукисы не будут доступны из Javascript.

jQuery

Если вы используете jQuery в своих проектах, то существует специальный плагин для работы с кукисами. Плагин jquery.cookie.js поставляется вместе с Yii и очень сильно упрощает работу с кукисами из Javascript. Пример установки значения кукисов:

$.cookie('the_cookie', 'the_value');

Для того, чтобы получить значение из кукисов:

var cookie = $.cookie('the_cookie');

Удаление кукисов:

$.cookie('the_cookie', null);

В файле jquery.cookie.js содержится большее количество примеров и более подробная документация по его использованию.

Способ без использования jQuery

Если вы не используете jQuery в вашем приложении или по какой-то причине не хотите использовать специальный jQuery-плагин для работы с кукисами, то вы можете воспользоваться следующими двумя функциями:

function readCookie(cookieName)
{
    var theCookie = '' + document.cookie;
    var ind = theCookie.indexOf(cookieName);
    var ind1 = theCookie.indexOf(';', ind);
    if(ind1 == -1) ind1 = theCookie.length;
 
    if(ind == -1 || cookieName == '') return '';
 
    return unescape(theCookie.substring(ind + cookieName.length + 1, ind1));
}
 
function setCookie(cookieName, cookieValue, nDays)
{
    var today = new Date();
    var expire = new Date();
 
    if(nDays == null || nDays == 0) nDays = 1;
 
    expire.setTime(today.getTime() + 3600000 * 24 * nDays);
 
    document.cookie = cookieName + '=' + escape(cookieValue) + ';expires=' + expire.toGMTString();
}

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

Дополнительная информация

документация класса CHttpCookie;
документация класса CCookieCollection;
ветка форума по работе с кукисами.

Дополнения, найденные неточности и ошибки в тексте приветствуются.

Загружаем фикстуры в базу данных без тестирования в Yii

resurtm@gmail.com (resurtm) — Mon, 01 Aug 2011 11:00:00 +0600

Введение

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

Подготовка

скачиваем последнюю актуальную версию ветки 1.* фреймворка;
создаем и настраиваем виртуальный хост приложения на локальном веб-сервере;
распаковываем содержимое архива фреймворка в document root нового виртуального хоста;
генерируем стандартное свежее Yii-приложение, выполнив команду framework\yiic webapp . в document root директории;
открываем в браузере наше свежее приложение по ссылке http://domain.com/.

Теперь нужно создать таблицу, в которую мы будет загружать фикстуры:

создайте в базе данных таблицу tbl_post с тремя столбцами: id, title, content;
установите правильные настройки соединения с базой данных в конфигурационных файлах protected/config/main.php и protected/config/console.php (компонент db в разделе components);
включите в конфигурационном файле protected/config/main.php кодогенератор gii и установите пароль на доступ к нему;
сгенерируйте модель для таблицы tbl_post при помощи gii, который находится по адресу http://domain.com/index.php?r=gii, а внутри раздел Model Generator.

Фикстуры и их загрузка

Создаем файл с фикстурами tbl_post.php в директории protected/tests/fixtures и пишем туда тестовые данные, которые мы хотим хранить в фикстурах и в будущем загружать в наши таблицы.

return array(
    'post1'=>array(
        'id'=>1,
        'title'=>'First testing post',
        'content'=>'<p>Content</p>',
    ),
    'post2'=>array(
        'id'=>2,
        'title'=>'Второй пост',
        'content'=>'<p>Контент</p>',
    ),
    'post3'=>array(
        'id'=>3,
        'title'=>'3rd post',
        'content'=>'<p>Еще немного контента</p>',
    ),
);

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

'components'=>array(
    // другие компоненты
 
    'fixture'=>array(
        'class'=>'system.test.CDbFixtureManager',
        'basePath'=>dirname(__FILE__).'/../tests/fixtures',
    ),
),

Исходный код консольной команды для работы с базой данных и фикстурами выглядит следующим образом:

// файл protected/commands/DbCommand.php
 
class DbCommand extends CConsoleCommand
{
    public function actionFixture($all=true, $tables='')
    {
        $fm=Yii::app()->fixture;
        $fm->checkIntegrity(false);
 
        // читаем список таблиц из директории с фикстурами
        if($all && !$tables)
        {
            echo 'Loading fixtures for all tables...'."\n";
 
            $handle=opendir($fm->basePath);
            while($file=readdir($handle))
            {
                if($file=='.' || $file=='..')
                    continue;
                $tables.=mb_substr($file, 0, -4).',';
            }
            closedir($handle);
 
            $tables=mb_substr($tables, 0, -1);
        }
        else
            echo 'Loading fixtures for specified tables...'."\n";
 
        // грузим данные в таблицы
        $tableNames=explode(',', $tables);
        foreach($tableNames as $tableName)
        {
            echo $tableName."\n";
            $fm->resetTable($tableName);
            $fm->loadFixture($tableName);
        }
 
        $fm->checkIntegrity(true);
        echo 'Done.';
    }
}

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

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

C:\domain.com\www\protected>yiic db fixture
Loading fixtures for all tables...
tbl_post
Done.

C:\domain.com\www\protected>yiic db fixture --all
Loading fixtures for all tables...
tbl_post
Done.

C:\domain.com\www\protected>yiic db fixture --tables=tbl_post
Loading fixtures for specified tables...
tbl_post
Done.

Полноценное приложение-пример со всем исходным кодом из рецепта можно скачать тут.

Much Ado About Traversal — траверс в Pyramid (перевод)

resurtm@gmail.com (resurtm) — Sun, 27 Mar 2011 11:00:00 +0600

О переводе

Это вольный перевод полезной статьи в блоге Роба Миллера (Rob Miller) об альтерантивном URL матчингу способе обработки HTTP запросов в фреймворке Pyramid. Статья также стала частью документации самого фреймворка. Читатель данной статьи должен обладать определенным уровнем знаний и иметь представления о многих аспектах разработки.

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

Введение

Обычно люди, которые долгое время работали с Pylons или с каким-либо другим фреймворком, и с их роутингом URL немного удивляются тому, как устроена обработка и роутинг HTTP запросов в Pyramid и таким понятиям, как траверс и поиск представлений. Другие люди считают, что траверс сложен для понимания. Кто-то думает, что траверс бесполезен, потому как они успешно работали со стандартным URL матчингом и он полностью подходил для их задач. Почему они должны переходить на другой, более сложный, способ роутинга?

Если вы не хотите понимать траверс, то вы можете обойтись без него. Можно без проблем создавать Pyramid приложения и без понимания этой концепции. Тем не менее, в реальной разработке встречается множество задач, которые траверс решает изящнее и лучше, чем классический URL матчинг, основанный на регулярных выражениях. Возможно, вы не сталкивались с такими ситуациями ранее, однако понимание их может помочь вам в будущем. Траверс (traversal) — это, по сути, метафора, легко понятная тем, кто хорошо представляет себе суть директорий и файлов в них.

URL диспетчер

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

Множество систем, в том числе и Pyramid, предлагают простое решение — обычный URL матчинг. URL матчинг работает так, что парсит URL и сравнивает результаты с множеством явно заданных шаблонов (элементов роутинга), заданных обычными регулярными выражениями (или другим синтаксисом). Каждый такой шаблон (один элемент из множества правил роутера) связан с представлением. Если путь запроса соответствует какому-либо заданному шаблону, то вызывается связанная с ним функция-представление. Если путь запроса подходит сразу нескольким шаблонам, то применяется несколько иная схема разрешения конфликтов, обычно основанная на том, что вызывается та функция-представление, которая совпала с заданным путем запроса раньше и вызывается. Если из всего множества шаблонов, предопределенных разработчиком, не подошел ни один шаблон, то отдается ответ 404 Not Found.

В Pyramid предлагается для использования реализация классического URL матчинга. Используя синтаксис Pyramid мы можем связать шаблон /{userid}/photos/{photoid} с функцией-представлением photo_view(), которая определена в коде. Запрос вида /joeschmoe/photos/photo1 подойдет к этому шаблону и будет вызвана функция photo_view() для обработки запроса. Точно также шаблон /{userid}/blog/{year}/{month}/{postid} может быть привязан к функции blog_post_view() и запрос пути /joeschmoe/blog/2010/12/urlmatching вызовет функцию, которая наверное, знает, как найти и отобразить запрошенный пост блога.

Историческая справка

Когда мы немного освежили знания по классическому URL диспетчеру мы можем углубиться в идею траверса. Перед тем, как мы это сделаем давайте немного вспомним историю. Если вы работали некоторое время в веб-разработке, то вы, возможно, помните время, когда не было таких прекрасных фреймворков, как Pylons или Pyramid. Вместо этого, были HTTP серверы общего назначения, которые работали просто как серверы файловой системы. Корень определенного сайта был связан с определенной директорией. Каждый сегмент URL запроса представлял из себя поддиректорию. Последний сегмент пути обычно являлся или директорией или файлом. Когда сервер находил нужный файл, то упаковывал его в HTTP ответ и отправлял обратно клиенту. Таким образом, обслуживание запроса по адресу /joeschmoe/photos/photo1 фактически означало, что на диске должна быть директория joeschmoe, которая в свою очередь содержала директорию с фотографиями, в которой находился файл photo1. Если в процессе обработки пути нужный файл или директория не надились, то отдавался ответ 404 Not Found.

По мере того, как веб становился все более динамичным, добавилась некоторая сложность. Были придуманы технологии: CGI, FastCGI и встраиваемые в веб-сервер модули. Файлы все еще искались в файловой систем, но если имя запрашиваемого файла заканчивалось, например, на .cgi, .pl или .php, или если они были размещены в определенной специальной директории, то в этом случае веб-сервер не отдавал файл в сыром выде, а читал этот файл, исполнял его, используя какой-то интерпретатор, и только потом результат его исполнения отдавал клиенту (HTTP ответ на HTTP запрос). Сервер конфигурировался так, что некоторые файлы вызывали динамический обработчик, а другие файлы просто отдавались в сыром виде веб-сервером (поведение по умолчанию).

Траверс или поиск ресурсов

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

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

Путь /joeschmoe/photos/photo1 содержит четыре сегмента: /, joeschmoe, photos и photo1. При поиске в файловой системе у нас была бы корневая директория (/), которая содержит в себе поддиректории (joeschmoe), которая, в свою очередь, содержит другие вложенные директории (photos), а та, в конце концов, содержит JPEG файл (photo1). С траверсом мы имеем корневой объект словарного типа. Поиск по ключу joeschmoe возвращает нам другой словарный объект. Запрашивая вновь у этого объекта по ключу photos, мы получаем другой словарный объект, который в итоге содержит ресурсы, которые мы ищем и значения, которые нам нужны и доступны по ключу photo1.

В понятиях Python траверс или поиск ресуров, который соответствует пути запроса /joeschmoe/photos/photo1 будет выглядеть примерно так:

get_root()['joeschmoe']['photos']['photo1']

get_root() — это функция, которая возвращает корневой ресурс траверса. Если все указанные ключи существуют, то возвращаемый ресурс и будет тем ресурсом, который был запрошен, по аналогиии с примером с JPEG файлом, который был бы найден в файловой системе. Если по мере поиска нужного ресурса было создано исключение KeyError, то Pyramid вернет 404 Not Found. (Это не тоже самое, что происходит на самом деле, но основная идея показана верно.)

Что такое ресурс?

Вы можете сказать «я понимаю файлы в файловой системе, но что такое эти вложенные словари? Где эти объекты и ресурсы находится? Чем они являются фактически?»

Так как Pyramid не является строгим фреймворком и его целью не является ограничение разработчика, то он и не делает ограничений на то, как ваш ресурс реализован фактически. Разработчик может реализовать ресурс так, как ему угодно. Используется один единственный способ для хранения всех ресурсов (корневой ресурс в том числе), в базе данных в виде графа. Корневой объект — это объект словарного типа. Любой словарный объект в Python реализует метод __getitem__ который вызывается по мере поиска ресурса. Например, если adict является объектом словарного типа, то Python трансформирует вызов типа adict['a'] в adict.__getitem__('a'). Попробуйте это сделать сами, если вы нам не верите:

Python 2.4.6 (#2, Apr 29 2010, 00:31:48)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> adict = {}
>>> adict['a'] = 1
>>> adict['a']
1
>>> adict.__getitem__('a')
1

Корневой объект словарного типа хранит в себе все идентификаторы его подресурсов как ключи и реализует метод __getitem__, который и отдает их. То есть get_root() отдает уникальный корневой объект, тогда как get_root()['joeschmoe'] отдает объект другого типа, который также хранится в базе данных, который тоже имеет свои собственные подресурсы и реализует метод __getitem__ и так далее вниз по иерархии. Эти ресурсы могут храниться как в реляционной базе данных, так и в одном из популярных сегодня NoSQL хранилищ или где-либо еще. Реального значения это не имеет. До тех пор пока объекты будут представлять API для доступа как к словарю (т.е. будут иметь реализацию метода __getitem__) траверсинг будет работать.

Фактически, вам не нужна база данных. Вы можете использовать обычные простые словари, со структурой вашего сайта, которые буду захардкодены в исходном коде Python. Или вы можете просто реализовать множество объектов с методом __getitem__, который будет искать файлы в нужной директории на диске, и таким образом определить классический традиционный механизм сопоставления пути URL с физическими файлами и директориями в файловой системе через траверс. Другими словами, в этом случае траверс будет являться надмножеством поиска ресурсов в файловой системе.

Поиск представлений

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

Необходимость в поиске представлений такова: может быть несколько действий, которые вы можете выполнить после того, как ресурс будет найден. В нашем примере с фотографиями вы можете посмотреть фотографию на странице, но вы также можете захотеть предоставить способ редактирования фотографии и сопутствующей ей мета-информации. Первое представление мы назовем view, а второе будет называться edit. (Оригинально, я знаю.) Pyramid имеет централизованный реестр представлений где именованные представления могут быть проассоциированны со специфичными типами ресурсов. То есть в нашем примере мы предполагаем то, что мы зарегистрировали представления view и edit для объекта «фотография» и мы указали, что представление view является представлением по умолчанию. Путь /joeschmoe/photos/photo1/view тождественен пути /joeschmoe/photos/photo1. Представление редактирования будет доступно по запросу /joeschmoe/photos/photo1/edit.

Надеемся на то, что понятно, что первая часть часть URL будет возвращать тот-же самый ресурс, что и версия чуть выше, которая не имеет возможности редактирования фотографии, а именно ресурс возвращаемый по вызову get_root()['joeschmoe']['photos']['photo1']. Но траверс заканчивается здесь. photo1 не имеет ключа edit. Фактически он (объект типа «фотография») даже может и не быть словарным объектом, в котором photo1['edit'] будет бессмысленным. Когда поиск ресурсов в Pyramid будет закончен и будет найден конечный фрагмент дерева (нужный ресурс), но весь путь запроса все еще не кончился, то следующие сегменты будут трактоваться как названия представлений. Реестр далее будет проверять является ли нужное представление проассоциированным с ресурсом данного типа. Если так, то представление будет вызвано с ресурсом, переданным как соотвествующий контекстный объект (также доступный как request.context). Если представление для вызова не будет найдено, то Pyramid просто вернет ответ 404 Not Found.

Можно переписать запрос /joeschmoe/photos/photo1/edit в следующий кусок питонического псевдокода:

context = get_root()['joeschmoe']['photos']['photo1']
view_callable = get_view(context, 'edit')
request.context = context
view_callable(request)

Функций get_root() и get_view() не существует на самом деле. Внутри себя, Pyramid работает немного иначе и сложнее. Однако пример выше является разумным приближением алгоритма поиска вьюшек в псевдокоде.

Случаи применения

Почему мы должны думать о траверсе? URL матчинг проще пояснить и он достаточно хорош, верно?

В некоторых случах, да, но, конечно, не во всех случаях. До сих пор у нас были очень структурированные URLы, где наш путь имел специфичные, маленькие кусочки:

/{userid}/{typename}/{objectid}[/{view_name}]

Во всех этих примерах до сих пор мы захардкодивали название определенного кусочка, предполагая, что мы знаем во время разработки какие имена будут использоваться (photos, blog и так далее). Но что если мы не знаем какие имена это будут в итоге? Или, что еще хуже, что если мы не знаем вообще ничего о будущей структуре URL внутри директории пользователя? Мы можем писать CMS в которой мы хотим, чтобы конечный пользователь имел возможность произвольно добавлять содержимое и другие директории внутри его директории. Он может решить сделать иерархию глубиной в дюжину. Какими будут ваши шаблоны сопоставления в классическом роутинге, которые позволят каждой учетной записи пользователя использовать любые комбинации путей?

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

С траверсом, однако, это очень просто и логично. Двадцать слоев иерархии не будет проблемой. Pyramid с удовольствием сделает вызов __getitem__ столько раз, сколько надо до тех пор пока не кончится сегменты пути или пока ресурс создаст исключение KeyError. Каждый ресурс должен знать только лишь то, как получить его непосредственных потомков на один уровень ниже (дети), обо всем остальном позаботится алогоритм траверса. И еще, так как структура дерева ресурсов может находится в базе данных, а не в коде, то будет очень просто дать пользователям возможность модифицировать дерево во время исполнения для установки персонализированной структуры директорий.

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

Если каждый ресурс будет генерировать контекстно-ориентированные ACL, тогда код представления может попытаться выполнить нужное действие и проверит перед этим через ACL может ли текущий пользователь совершить это действие. Таким образом вы достигаете instance based или row level безопасности, которую значительно более сложно реализовать стандартным табличным способом и классическом роутингом. Pyramid активно поддерживает такие схемы и фактически если вы регистрируете ваши вьюшки с правами защиты и используете авторизационную политику, Pyramid может проверять через ACL и решать доступна ли или нет текущая вьюшка текущему пользователю.

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

Более того, возможно смешение и сочетание траверса с классическим роутингом в одном и том-же Pyramid приложении.

Роб Миллер (Rob Miller), 31 декабря, 2010.
Перевод: Тимур Рузиев aka resurtm, 27 марта, 2011.
Редактура, корректура: Тимур Тимирханов aka TLemur, 27 марта, 2011.