Update. Метод Folder::findRecursive возвращал слишком много файлов, в том числе и ненужных. Переписал немного, теперь опрашиваем только директорию с плагином и его контроллерами.

/**
 * Lists the names of controllers including plugin controllers
 * 
 * @return array
 */
static function listControllers()
{
    App::import('Core', array('File', 'Folder'));
 
    $controllers = Configure::listObjects('controller');
 
    $config = Configure::getInstance();
 
    foreach ($config->pluginPaths as $pluginPath)
    {
        $folder = new Folder($pluginPath);
        list($plugin_dirs) = $folder->read();
        foreach($plugin_dirs as $plugin_dir)
        {
            $pluginName = Inflector::camelize($plugin_dir);
            $folder->cd($pluginPath . $plugin_dir);
            $controllerFiles = $folder->find('.*_controller\.php');
            $folder->cd(Folder::addPathElement($folder->path, 'controllers'));
            $controllerFiles = array_merge($controllerFiles,$folder->find('.*_controller\.php'));
            foreach ($controllerFiles as $file)
            {
                $file = basename($file);
                $controllers[] = $pluginName . '.' .
                    Inflector::camelize(substr($file, 0, strlen($file)-
                    strlen('_controller.php')));
            }
        }
    }
    return $controllers;
}

App::import('Model', 'MyModel');

Но загрузить контроллер так не получится. Получим сообщение об ошибке из-за невозможности найти базовый класс Controller. Вот найти класс Model кейк может, а Controller – нет. Во всяком случае 1.2.5. В версии 1.3 не пробовал.

Поэтому приходится загружать его явно и напрямую:

App::import('Core', 'Controller');
App::import('Controller', 'MyController');

Этот код приложения, изначально крутившийся по Cake 1.1, был переписан для какой-то беты Cake 1.2. С текущей версией, 1.2.5, он работает без проблем, но, возможно, нуждается в чистке.

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

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

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

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

Увы, все файлы с компонентами находятся в каталоге components. Зато после перегрузки можно к загруженному компоненту обращаться по имени базового:

$this->SupplierCsv->parse($data);

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

if (!App::import('Component', 'SupplierCsv'))
    die('Cannot load SupplierCsv component');

Еще у базового компонента есть метод factory. Я не помню, почему я его статическим объявил, честно. :-) Он получает в качестве параметра ссылку на контроллер и название компонента для обработки данных от конкретного поставщика:

SupplierCsvComponent::factory($this, array('CsvComponentName'=>$component_name));

Теперь методы базового компонента, SupplierCsvComponent:

function startup(&$controller)
{
    $this->controller = $controller;
    $controller->SupplierCsv = $this;
}
 
static function factory(&$controller, $supplier)
{
    App::import('Component', $supplier['CsvComponentName']);
    $componentclass = $supplier['CsvComponentName'] . 'Component';
    $controller->SupplierCsv = new $componentclass;
    $controller->SupplierCsv->startup($controller);
}

ну и код метода startup дочерних классов:

function startup(&$controller)
{
    parent::startup($controller);
    $this->init = $this->name;
}

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

Откровенно говоря, огород можно было бы и не городить. Можно через App::import() загрузить класс компонента, а потом какой-нибудь переменной контроллера присвоить экземпляр этого класса.

Наверное, я раньше грузил компонент, указывая его в массиве $components, потому и сделал такую навернутую схему.

А может мне не хотелось require_once использовать… Ну не помню. :)

Update: Если соберусь переписывать, надо будет рефлексию попробовать использовать. :)

В качестве кэша байткода и переменных я использую XCache. Но при запуске консольных приложений, он у меня не работает. Должен или нет, не знаю, не разбирался. Наверное, не должен, если подумать. :-) Просто отметил, что консольные приложения Cake, включая ‘cake bake‘ высыпают кучу ошибок, если XCache используется, как кэш по умолчанию. Поэтому в конфигурации кэша приложения (APP/config/core.php) на CakePHP добавляю маленькую проверку на тип API.

Вот как-то так:

if (PHP_SAPI == 'cli') {
  Cache::config('default', array('engine' => 'File'));
} else {
  Cache::config('default',
    array(
      'engine' => 'Xcache',
          'prefix' => 'mypfx_',
          'user'=>'IamAdmin',
          'password'=>'c00leztPass'));
}

Можно пользоваться константой PHP_SAPI или функцией php_sapi_name(), не важно.

http://www.oursite.com/controller/action.json

Чтобы Cake не пугался этого расширения и вызывал правильное действие (action), в файл APP/config/routes.php добавим строку:

Router::parseExtensions('json');

Теперь надо разобраться с разными представлениями наших данных, чтобы по запросам к /action и /action.json возвращались разные виды. Для этого нужен компонент RequestHandler. Подключим его либо в самом контроллере, либо в родительском AppController:

var $components = array('RequestHandler');

Теперь шаблоны для view и layout Cake будет искать в поддиректориях /json. Т.е для layout надо будет создать файл /views/layout/json/default.ctp:

<?php echo $content_for_layout; ?>

и файл для действия /views/controller/json/action.ctp. Какой-то такой:

<?php echo $javascript->object($data); ?>

Это все и без меня все знают, ничего нового тут нет. Разве что cakebaker советует воспользоваться Zend::Json вместо стандартного помощника Javascript, дескать Zend’овская библиотека автоматом кодирует некоторые спецсимволы.

Но есть одна тонкость, недостаточно отраженная в документации — заголовок ответа Content-type. По всем ожиданиям он должен быть ‘application/json’, как это определено в коде компонента RequestHandler.

Однако, если включен режим отладки, т.е. Configure.debug > 0, то RequestHandler устанавливает Сontent-Type в text/html без вариантов. Это, в общем-то описано в документации и докопаться до этого можно.

Но совершенно неочевидно, что если режим отладки выключить в коде самого action, написав

Configure::write('debug', 0);

то это ничего уже не изменит! RequestHandler устанавливает заголовок во время загрузки компонента. Его метод startup() вызывает метод renderAs(), который вызывает метод respondAs(). Таким образом шаблоны подключаются нужные, те, которые из директорий /json, а Content-Type неправильный.

Лично я, пока, в acton, который должен отдавать данные в json, явно вызывываю RequestHandler->respondAs() повторно:

if (Configure::read()) {
    Configure::write('debug', 0);
    $this->RequestHandler->__responseTypeSet = null;
    $this->RequestHandler->renderAs('json');
}

Это заставляет RequestHandler изменить заголовок Content-type еще раз. Можно похожий код, с проверкой типа запроса и установкой режима отладки и заголовков попробовать запихнуть, скажем, в beforeRender. Обратите внимание на грязный хак с установкой свойства __responseTypeSet в NULL. Метод respondAs сохраняет в эту переменную тип ответа и повторно не будет срабатывать, если он уже был вызван.

Известно, что метод контроллера paginate() вызывает последовательно два метода модели — первый для подсчета общего числа записей, удовлетворяющих заданным условиям, и второй на выборку указанного числа записей начиная с заданной. Т.е. первый это фактически функция SQL COUNT(*), второй — SELECT … LIMIT n,m.

Именно из-за того, что вызовов методов больше одного, не срабаывает временная привязка/отвязка подчиненных моделей с помощью bindModel()/unbindModel(). Этим методам, для корректной работы с paginate() приходится передавать второй параметр, равный false. К счастью, еть ContainableBehavior, решающий эту проблему.

Эти запросы не всегда оптимальны и есть возможность улучшить производительность метода paginate() именно за счет оптимизации собственно самих запросов.

Для того, чтобы влиять на работу метода paginate(), в контроллере CakePHP предусмотрены вызовы двух специальных методов модели: Model::paginateCount() и Model::paginate(). Метод paginate() контроллера ищет у модели указанные методы и, если они определены, вызывает их. Если у модели методы не определены, вызываются стандартные Model::find(‘count’ …) и Model::find(‘all’,..), которым в качестве параметров передаются условия выборки, условия для Containable и все прочее.

Понятно, что определив эти методы в модели, все вместе или любой на выбор, можно творить все, что захочется. А сам метод Controller::paginate() (не путайте с нашим Model::paginate()!) тогда будет заниматься исключительно вспомогательной работой — опредять параметры для LIMIT и настраивать переменные вида (View). Самое главное, чтобы наш метод Model::paginateCount() возвращал (int) количество записей, а Model::paginate() — массив записей.

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

Model::paginateCount

Первым займемся методом для подсчета количества записей. Этот метод я уже описывал чуть более года назад, но то описание во-первых устарело, потому, что в итоге в CakePHP сменился синтаксис вызова COUNT(*), а во-вторых здесь я постараюсь дать более развернутое описание.

При вызове метода Model::paginateCount(), контроллер передает ему три параметра: $conditions, $recursive и $extra.

• (array) conditions — ассоциативный массив условий, такой же, как массивы условий для любых других методов модели. В нашем случае в него копируются условия из массива Controller::paginate['conditions'].
• (int) recursive — значение параметра $recursive. Если это значение установлено в переменной Controller::raginate['recursive'], то оно. Если нет, то берется из значения свойства Model::recursive
• (array) extra — ассоциативный массив всех остальных переменных, передаваемых в Controller::paginate, ‘contain’ (для ContainableBehavior), ‘fields’ и т.д. В общем, содержимое переменной Controller::paginate без первых двух параметров.

Хочу отметить, что никто не запрещает указывать в массиве Controller::paginate какие-то свои собственные ключи. Так что, если в методе нашего контроллера определить что-то типа:

$this->paginate['my-cool-param']='YES!';

то эта пара ключ-значение тоже попадет в параметр extra.

Чаще всего для разбивки на страницы используется модель, связанная с другими. Классический пример с моделью Article, которая принадлежит (belongsTo) модели Author. Для окончательного вывода нам нужны данные из обоих моделей, но для подсчета записей достаточно посчитать только записи в Article. Т.е. для подсчета строк достаточно выполнить COUNT(*) только для таблицы articles, без лишних JOIN’ов. MySQL работает гораздо веселее, когда удается обойтись без связанных таблиц. Для этого простого случая вполне можно вызывать $this->Article->unbindModel(array(‘belongsTo’=>array(‘Author’)))) и связанная модель Author не будет участвовать в подсчете, но будет в выборке результатов. Помните, что метод unbindModel() по умолчанию «отвязывает» модель только на один, следующий, запрос?

Но если связанных моделей много, что, надо помнить их все? Да и дергать unbindModel() перед Controller::paginate() что-то не улыбается. Особенно с точки зрения парадигмы «тонкий контроллер, толстая модель».

Иными словами, я считаю, что надо написать такой метод paginateCount, который будет подсчитывать записи в таблице без присоединения зависимых моделей. Сделать это можно жестко задавая параметр $recursive при вызове Model::find(‘count’…). Получится примерно такой код:

function paginateCount($conditions, $recursive, $extra)
{
    return $this->find('count',
        array(
            'conditions'=>$conditions,
            'recursive'=>-1
        )
    );
}

Теперь при вызове COUNT(*) не будет совсем никаких JOIN’ов, несмотря ни на какие отношения.

Я довольно долго пользовался этим вариантом метода и быль вполне им доволен. Но совсем недавно возникла необходимость все-таки в полном подсчете записей — из-за условия отбора по полю присоединенной модели. Совсем убирать этот метод мне не хотелось и я решил просто добавить возможность указания — надо ли использовать для подсчета запрос с присоединенными моделями или можно обойтись подсчетом записей только в одной. Если конкретнее, то для frontend метода index использую «быстрый» метод подсчета, а в админской части есть более сложные фильтры, требующие использования «медленного» метода. Чтобы указать необходимость использования «медленного» метода, с использованием присоединенных моделей, используется дополнительный ключ в массиве Controller::paginate. Что я, зря, чтоль столько букв про $extra написал? :-) Теперь если задан сложный фильтр по записям, кроме условий в Controller::paginate['conditions'], добавляю ключ Controller::paginate['count_recursive']=1. А метод стал выглядить так:

function paginateCount($conditions, $recursive, $extra)
{
    if (@$extra['count_recursive']) {
        unset($extra['count_recursive']);
    } else {
        $recursive=-1;
    }
 
    return $this->find('count', 
        array_merge(
            array(
                'conditions'=>$conditions,
                'recursive'=>$recursive),
                $extra
            )
        );
}

Получилось, на мой взгляд вполне неплохо.

Model::paginate

После доработки подсчета я решил посмотреть, что можно сделать с самим запросом на выборку. По сути, find(‘all’, …) он и есть find(‘all’, …) чего там еще с ним сделаешь? Тем не менее, из метода контроллера Controller::paginate(), одноименный метод модели Model::paginate() вызывается с множеством параметров.

function paginate($conditions, $fields, $order, $limit, $page = 1, $recursive = null, $extra = array())

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

В качестве примера, простая ситуация с цепочкой из трех моделей. Таблица с продуктами, у которых есть много цен (розничная, опт1, и т.д.) в разных валютах (их всего три, так получилось). Для работы только с розничными ценами мы перепривязали с помощью unbindModel() и bindModel() модель с ценами как hasOne с условием Price.price_type=’retail’. Но цепочка из трех моделей осталась:

• модель Product владеет ценой (hasOne) Price;
• Price принадлежит валюте (belongsTo) Currency

Обычный Model::find(‘all’…) поступит просто. Выберет все записи Product-JOIN-Price, а потом для каждого элемента массива выберет Currency. С учетом того, что в самом худшем варианте, на странице будут цены в трех валютах, двадцать запросов ‘SELECT Price … ‘ все равно выглядят удручающе. В похожей ситуации я поступил так:

• С помощью recursive при вызове Model::find(‘all’,…) ограничил выборку только связью Product-Price
• Используя Set::classicExtract получил массив id нужных валют. Можно было и с помощью SQL запроса SELECT DISTINCT это сделать, но Set::classicExtract мне ближе ;-)
• Выбрал нужные вылюты из модели Currency
• Добавил в массив, полученный в первом пункте выбранные валюты в соответствии с Price.currency_id

Получилось всего три запроса, включая запрос на подсчет!

Возможность оптимизации менее сложных запросов при вызове Controller::paginate() тоже есть.

Когда я сделал свой метод Model::paginateCount() для общей и админской части, обратил внимание, что возможен вариант, когда в админской части заданы такие условия выборки, под которые не попадает ни одной записи. Например, в указанном разделе автор не опубликовал ни одной записи. В этом случае возвращается, как нетрудно догадаться, пустой массив. Поскольку меня уже было не остановить :-) , я задался вопросом — а если нет ни одной записи, и paginateCount() это уже определил, то зачем вообще выполнять запрос к БД на выборку? Можно же просто вернуть пустой массив! Так и поступил.

В модель добавил переменную, в которую Model::paginateCount() записывал полученное количество записей.

private $_lastPaginationCountResult = 0;
 
function paginateCount($conditions, $recursive, $extra)
{
    if (@$extra['count_recursive']) {
        unset($extra['count_recursive']);
    } else {
        $recursive=-1;
    }
 
    $this->_lastPaginationCountResult = $this->find('count', 
        array_merge(
            array(
                'conditions'=>$conditions,
                'recursive'=>$recursive),
                $extra
            )
        );
 
    return $this->_lastPaginationCountResult;
}

И написал маленький метод Model::paginate(). Мною собственноручно написана только одна строка, проверка переменной с результатами paginateCount(), которая была вызвана до того. Весь остальной код просто скопировал из соответствующего метода Controller::paginate().

function paginate($conditions, $fields, $order, $limit, $page = 1, $recursive = null, $extra = array()) {
 
    if ($this->_lastPaginationCountResult === 0) return array();
 
    $parameters = compact('conditions', 'fields', 'order', 'limit', 'page');
 
    if ($recursive != $this->recursive) {
        $parameters['recursive'] = $recursive;
    }
 
    if (array_key_exists('type', $extra)) {
        $type = $extra['type'];
        unset($extra['type']);
    }
    else $type='all';
 
    return $this->find($type, array_merge($parameters, $extra));
}

Кстати, обратите внимание, на параметр type, это не я придумал, это в оригинале так было. Он позволяет вместо find(‘all’,…) использовать для выборки любой другой тип запроса. Даже самостоятельно определенный, например, find(‘recent’,…), если, конечно, поддержку этого метода кто-нибудь заранее напишет ;-)

findBy<fieldName>(string $value)


Хотя на самом деле это не совсем соответствует действительности. Для поиска одной записи по значению одного поля описание должно выглядеть так:

findBy<fieldName>(string $value, $fields=null, $order=null, $recursive=null)

и

finAlldBy<fieldName>(string $value, $fields=null, $order=null, $limit=null, $page=null, $recursive=null)

Разница есть. Лично я очень обрадовался параметру $recursive — не надо отдельно, перед вызовом метода устанавливать это значение или ображаться к Containable.

Но и это еще не все!

Можно задавать несколько полей для условия, объединяя их AND и OR. Вполне работает такая конструкция:

$this->User->findByIdAndActive(123, 1)

Получится запрос типа

SELECT * FROM User WHERE id=123 AND active=1

Если в условии участвуют несколько полей, то их значения для поиска должны быть первыми параметрами для вызова метода, в том порядке, в котором перечислены названия полей модели. А уж после значений для поиска можно добавлять аргументы $fields, $order и т.д.

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

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

Вот, например, простая форма регистрации пользователя.

Форма очень человеколюбивая, и, даже, не побоюсь этого выражения, user-friendly: у нее есть 2 поля с E-mail (второе для проверки), 2 поля с паролем и еще капча. Регистрируйтесь, наздоровье. :-)

В модели User, само собой, есть только колонки ‘email’ и ‘password’, без дубликатов, а колонка ‘captcha’ отсутствует совсем.

Изначально в классе модели правила проверки полей ‘email’ и ‘password’ определены вот такие:

var $validate = array(
    /**************** Password **************/
    'password' => array(
        'minlength' => array(
            'rule' => array('minLength', '6'),
            'message' => 'Password must be at least 6 characters long.',
            'allowEmpty' => false,
            'required' => true,
            'last' => true
        ),
    ),
    /************* E-mail ************************/
    'email' => array(
        'mailrule' => array(
            'rule' => array('email', true),
            'message' => 'Please supply a valid email address.',
            'allowEmpty' => false,
            'required' => true,
            'last' => true
            ),
        /* This field mus be unique */
        'must_be_unique' => array(
            'rule' => 'isUnique',
            'message' => 'User with this e-mail address is already registered',
            'last' => true
        )
    )
);

Правил для поля captcha, не определено никаких.

В шаблоне вида, форма и поля выводятся с помощью встроенного помощника (helper) Form. Примерно вот так:

echo $form->create('User', array('action'=>'register'));
 
/* ввод username и прочего пропущены */
 
echo $form->input('User.email');
echo $form->input('User.confirm_email');
echo $form->input('User.password');
echo $form->input('User.confirm_password', array('type' => 'password'));
echo $form->input('User.captcha', array(
    'label'=>'Что там на картинке?',
    'type'=>'text',
    'value'=>''));
 
echo $form->end(__('Пыщь!!111', true));

А в методе, который отвечает за запись данных, я, перед вызовом User->save(), просто добавляю еще дополнительные правила для email, password и captcha.

1. Данные из поля формы User.email должны быть идентичны данным из поля формы User.confirm_email
2. Данные из поля формы User.password должны быть идентичны данным из поля формы User.confirm_password
3. Данные из поля формы User.captcha должны быть идентичны содержимому переменной сессии Captcha.code
4. Поле User.captcha не может быть пустым

/* Чтоб сравнивать пароли понадобится помощь
 * компонента авторизации
 */
$this->User->validate['password']['confirm'] = array(
    'rule'=>array(
        'equalTo', (
            isset($this->data['Confirm']['password']) ?
                $this->Auth->password($this->data['Confirm']['password']) :
                '')
        ),
    'message'=>'Пароли не одинаковые'
);
 
$this->User->validate['email']['confirm'] = array(
    'rule'=>array('equalTo', (
        isset($this->data['Confirm']['email']) ?
            $this->data['Confirm']['email'] : 
            '')),
    'message'=>'E-mail адреса не одинаковые'
);
 
/* Получаем код капчи из сессии, а если его нет, сравнивать
 * будем с пустой строкой
 */
$captcha_code = $this->Session->check('Captcha.code') ?
    $this->Session->read('Captcha.code') : '';
 
$this->Session->del('Captcha.code');
 
/* Дбавляем единственное правило для несуществующего поля */
$this->User->validate['captcha'] = array(
    'rule' => array('equalTo', $captcha_code),
    'required' => true,
    'allowEmpty' => false,
    'message' => "You're a spam bot?"
);
 
/* ну и здесь */
if ($this->User->save($this->data)) // и так далее

Конечно, строчек кода, если и меньше, чем просто в случае сравнения, то ненамного. Зато встроенный валидатор отлично взаимодействует со встроенным помощником (helper) Form — сообщения об ошибках записываются в переменную validationErrors, выводятся «автомагически» рядом с соответствующими полями формы и т.д.

И уж совсем необязательно все это выписывать именно в контроллере перед вызовом save(). Можно добавить методов модели типа addCaptchaRule(), addEmailConfirmationRule() или типа того. Получится стильно и благородно. ;-)

Самым нетерпеливым раскрываю суть: запретите доступ неавторизованному пользователю к действию logout. :-)

Схема работы методов компонента простая. Если пользователь неавторизован, то URL, который он запрашивает сохраняется в сессии, а сам пользователь перенаправляется на страницу авторизации. При выходе (вызов метода logout) — все наоборот: запоминается referer, данные о пользователе убираются из сессии, он становится неавторизованным и перенаправляется обратно, на тот URL, с которого пришел.

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

Надо доступ к logout все-таки всем разрешать. И, на всякий случай, в начале метода написать

if (!$this->Auth->user()) $this->cakeError('error404');

Ибо нефиг искать выход, если еще не вошел :-)

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

Вот, кстати, мне всегда было интересно, как правильно перевести на русский слово slug в этом контексте. Ярлык?

Этот behavior написал Mariano Iglesias. Это часть его проекта Cake Syrup. О другой интересной составляющей, SoftDeletableBehavior, недавно, кстати, можно прочесть здесь.

Это расширение не использует Inflector::slug() — когда оно создавалось, этого метода еще не было. Зато поддержка транслита русских букв в UTF-8 уже встроена, не без помощи Вашего покорного слуги. ;-)

Работает расширение очень просто — при сохранении записи выбранное поле, по умолчанию ‘title’, преобразуется в slug и это значение присваивается соответствующему полю БД (по умолчанию ’slug’). Т.е. заголовок записи «Моя первая запись» автомагически превращается в «moja-pervaja-zapis». После этого можно формировать ссылки вида ‘/controller/action/my-slug’ а в соответствующем методе контроллера искать запись:

$this->Model->findBySlug($this->id);

Подключатся behavior, как и все остальные, в классе модели:

var $actsAs=array('Sluggable');

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

var $actsAs=array('Sluggable' => array(
    'translation'=>'utf-8',
    'label'=>'myfield')
);

Настойки могут быть такие:

• label — строка или массив. Здесь перечисляются поля, из содержимого которых нужно генерировать slug. Например если указать поля ‘author’ и ‘book_name’, то из массива array(‘author’=>’Абрамов’, ‘book_name’=>’Опознай живого’) получится slug ‘abramov-opoznay-zhivogo’. Указанные элементы массива не обязательно должны быть столбцами таблицы базы данных. Если такого столбца в таблице нет (например нету author), то не страшно — надо лишь следующему параметру, real, установить значение false. По-умолчанию параметр label равен ‘title’
• real — логическое значение, true или false. По-умолчанию true. Как я уже написал, если этот параметр установить в false, то элемент массива, по содержимому которого (или которых) будет создаваться slug, не обязательно должен сответствовать названию столбца в таблице БД.
• slug — имя столбца БД, в который будет записан результат работы behavior. По-умолчанию — ’slug’
• separator — строка. Это разделитель для слов, на который будут заменяться пробелы. по умолчанию ‘-’ (тире).
• length — целое число, максимальная длина поля slug. По-умолчанию 100 символов.
• overwrite — логическое значение, по-умолчанию false. Этот параметр позволяет указать, что при обновлении существующей записи в БД slug надо сгенерировать заново и перезаписать.

Без доработок дело не обошлось. Дело в том, что behavior для новой записи порывается создать slug в обязательном порядке, а мне хотелось бы чтоб он срабатывал только в случае, если это поле не указано. Иногда вручную получается лучше. Например заголовок «Мой сайт» будет преобразован в «moy-sayt», а хотелось бы «my-site». Поэтому я добавил проверку на наличие элемента массива. Теперь если при создании новой записи явно указать slug вручную, ничего автоматически пересоздаваться не будет, только, на всякий случай, slug проверится на уникальность.

Скачать SluggableBehavior можно со страницы проекта CakeSyrup.

А здесь маленький патч, который я описал парой строк выше.