3.4 Кэширование.
К счастью разработчиков CP представляет несколько механизмов управления кэшированием. На мой
взгляд они очень удобны. С их помощью мы сейчас настроем кэширование страниц с описаниями
продуктов и отзывами о них. Стандартно, предлагается несколько вариантов хранения кэшированных
данных, но мы будем использовать файловый, он стоит по умолчанию. За все нужные нам операции
отвечает хэлпер «Cache» ( http :// book . cakephp . org / view /213/ Cache ). Подключив его, настроим
кэширование только результата действия view ( http :// book . cakephp . org / view /346/ Caching - in - the -
Controller). Для этого обозначим массив «cacheAction» как свойство контроллера и поместим туда
ячейку «view/» со значением «86400».
Тем самым мы указываем CP что все результаты действия view нужно кэшировать на 86400 секунд, что
эквивалентно 24 часам. Теперь откройте конфигурацию ядра («./app/config/core.php») и
раскомментируйте установку опции «Cache.disable», заменив её значение на «false». И тоже самое
сделайте с объявлением настройки «Cache.check». Сохраните изменения и посмотрите страницу любого
товара. Затем откройте директорию «./app/tmp/cache/views», в которой хранится кэш отображений. Если
Вы всё сделали правильно то там будет находится файл с именем типа
«product_view_canon_hg20_black.php» в котором будет содержаться кэш просмотренной Вами страницы.
Осталось научиться очищать кэш конкретных страниц, ведь их контент изменяется когда мы оставляем
отзыв о товаре. Механизм кэширования CP уникален тем что кэш автоматически удаляется если через
модель, работающую с кэшированным действием, внести какие-то изменения в базу
( http :// book . cakephp . org / ar / view /348/ Clearing - the - Cache ). Мы бы могли этим воспользоваться если бы
комментарии вносились в базу через модель «Product», но как Вы помните отзывы в базу вносятся через
«Comment». Следовательно, нужно обнулять кэш вручную. Для таких действий в CP используется
глобальная функция «clearCache». Ей в качестве параметра нужно передать имя закэшированной
странице в формате «контролллер_действие_пара метр1_параметр2_параметрN». У нас это будет
«product_view_имя_продукта_в_тран слите». В контроллере «Comment», сразу после вызова метода
«save» пишем следующее:
На этом настройка кэширования завершена. Попробуйте подобавлять отзывы и проверить изменился ли
внешний вид страницы.

3.5 Логирование
И последнее что будет рассмотренно в этой статье — логирование данных о работе приложения
(http://book.cakephp.org/ar/view/157/Logging). Подобный функционал может очень пригодиться для
отслеживания ошибок в крупных приложениях, когда сходу не сообразишь где и какой произошла сбой.
Никаких компонентов или хэлперов подключать здесь не нужно. Единственная функция, нужная для
логирования, доступна всегда. Это функция «log». Ей нужно передавать 2 параметра. Первый —
сообщения. Им может быть информация об ошибке, сбое, действии пользователя и т.п. А второй — тип
логируемой информации. В качестве этого параметра может быть передана одна из двух констант —
«LOG_ERROR» и «LOG_DEBUG» - ошибочная или отладочная информация соответственно.
Рассмотрим пример с ошибкой. В методе «view» контроллера «Product» может быть ошибочно указан
товар в ссылке. В связи с этим метод «getProductIdByTName» вернёт ложное значение. Давайте добавим
после вызова этого метода строку
и пройдём по ссылке http://cakephp/product/view/11111111, вызвав тем самым несуществующий товар.
Сообщение будет записано в файл «error.log». Он находится там же где и все логи — в директории
«./app/tmp/logs». Открыв его Вы обнаружите что самая последняя надпись содержит информацию типа
этой - «2009-03-16 20:07:33 Error: Request to non-existing product». А можно вообще выделить в
отдельную группу например только лог-записи связанные с товарами. Для этого в качестве константы
можно передать строку, скажем, «products». В таком случае автоматически создастся файл «products.log»
и в него будет записана вся передаваемая информация.
Вот и всё. Код нашего магазина готов и нормально функционирует. Если у Вас что-то не получилось то
можете взять исходный код всего приложения в прикреплённом архиве «ready.zip».

4.0 Заключение.
На мой взгляд фреймворк хороший, но очень сильно запутанный. Иногда использование некоторых
функций не укладывается в голове — по логике они должны использоваться, например, в контроллере, а
используются в модели. Что-то должно быть компонентом, а является хэлпером. Не понравились и
инструменты для работы с БД. Я больше предпочитаю интерфейсы подобные паттерну ActiveRecord. Ну
и худой функционал — мало хэлперов и компонентов. И всё-таки, как говориться, на вкус и цвет...
Надеюсь, что он понравится читателям. Удачи Вам в Ваших проектах!

Файлы приложенные к статье: templates.zip , ready.zip , database.sql