Есть два плагина: PluginOne и PluginTwo. У первого две связанные модели: PluginOneModelOne belongsTo PluginOneModelTwo. У второго плагина одна модель, связанная с первой моделью первого плагина (пусть тоже будет belongsTo, неважно): PluginTwoModelOne belongsTo PluginOneModelOne. Соответственно, объявлено все это вот так:

Файл /plugins/plugin_one/models/plugin_one_model_one.php

class PluginOneModelOne extends PluginOneAppModel {
 
	var $belongsTo = array('PluginOneModelTwo');
 
}

Файл /plugins/plugin_one/models/plugin_one_model_two.php

class PluginOneModelTwo extends PluginOneAppModel {
	var $actsAs = array('Tree');
}

Файл /plugins/plugin_two/models/plugin_two_model_one.php

class PluginTwoModelOne extends PluginTwoAppModel {
 
	var $belongsTo = array(
		'PluginOneModelOne'=>array(
			'className'=>'PluginOne.PluginOneModelOne'
		));
 
}

Создадим в контроллере второго плагина тестовый метод:

Файл /plugins/plugin_two/controllers/plugin_two_model_ones_controller.php

class PluginTwoModelOnesController extends PluginTwoAppController {
 
	function typeofmodel() {
		die(get_class($this->PluginTwoModelOne->PluginOneModelOne->PluginOneModelTwo));
	}
 
}

Опачки! Третья модель типа AppModel, а не PluginOneModelTwo! Соответственно, не загружаются behaviours, перечисленные в $actsAs, не работают методы модели, не обрабатываются правила валидации. Хитрый Cake молча создает объект базового класса, чтоб связь работала для стандартной выборки, записи и все.

Достаточно в описании связи моделей первого плагина полностью указать какой класс использовать — все отлично начинает работать. Меняем код PluginOneModelOne

Файл /plugins/plugin_one/models/plugin_one_model_one.php

class PluginOneModelOne extends PluginOneAppModel {
 
	var $belongsTo = array(
			'PluginOneModelTwo'=>array(
				'className'=>'PluginOne.PluginOneModelTwo'
		));
 
}

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

Если подумать, то поведение фреймворка в общем-то логичное. Он ищет класс в текущем плагине и у самого приложения. Хотя мог бы и предупреждать, пусть бы и только в отладочном режиме, что есть проблема.

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');

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