1. сам MongoDB

2. php-драйвер монго

3. источник данных для CakePHP MongoDB Datasource
скачиваем плагин и кладем его в my/app/plugins/mongodb или забираем гитом

cd my/app/plugins
git clone git://github.com/ichikaway/cakephp-mongodb.git mongodb


дальше в database.php описываем новое подключение

<?php 
public $mongo = array( 
    'driver' => 'mongodb.mongodbSource', 
    'database' => 'sessions', 
    'host' => 'localhost',
    'port' => 27017,
);
?>

создаем модель Session, в ней описываем схему данных (хотя монго и schemaless, но кэйк сохраняет только те поля, которые описаны в схеме)

<?php
class Session extends AppModel {
    public $mongoSchema = array(
        'id' => array('type' => 'string'),
        'data' => array('type' => 'string'),
        'expires' => array('type' => 'integer'),
    );
}
?>

в core.php задаем новые параметры хранения сессий

<?php
Configure::write('Session.save', 'database');
Configure::write('Session.model', 'Session');
Configure::write('Session.database', 'mongo');
?>

все получилось:

1. Добавляем в проект файл autocomplete.php c таким вот содержимым

<?php

/**
* @property HtmlHelper $Html
* @property FormHelper $Form
* @property JsHelper $Js
* @property NumberHelper $Number
* @property PaginatorHelper $Paginator
* @property RssHelper $Rss
* @property SessionHelper $Session
* @property TextHelper $Text
* @property TimeHelper $Time
*/
class AutocompleteView extends View {
}

2. В каждой вьюхе пишем в самом начале (да, не очень изящно, но зато работает):

<?php/* @var $this AutocompleteView */?>

3. Готово

результат трудов

UPD. для массовой вставки строчки в начало шаблонов можно воспользоваться следующей командой (linux/cygwin)

find -name "*.ctp" -print0 | xargs -0 sed -i "1i <?php /** @var \$this AutocompleteView */ ?>"


в модели (например, User) добавляем behavior и передаем ему настройки

<?php

...

var $actsAs = array(

    'Scope.Scope' => array(

        'field' => 'site_id',

        'value' => SITE_ID,

    )

);

...

?>

теперь при вызове функций модели find или save условие будет добавляться автоматически, то есть

<?php

...

$this->User->find('all');

...

?>

будет эквивалентно

<?php

...

$this->User->find('all', array(

    'conditions' => array(

        'User.site_id' => SITE_ID,

    )

);

...

?>

Пользоваться, конечно, следует с осторожностью, так как некоторые операции, например updateAll и deleteAll c $cascade=false работают напрямую с источником данных и behavior остается не у дел (deleteAll c $cascade=true будет работать как и ожидается, с подстановкой параметров).

Исходный код лежит на гитхабе – http://github.com/evilbloodydemon/cakephp-scope

Замечания и предложения приветствуются.

sha1(md5(‘SeCrEt’ . $password . ‘KeY’)).

Как с этим жить?

CakePHP хранит пароли следующим образом:
поле пароля в БД = самый стойкий из доступных хэшей(открытый пароль + секретная соль)

Но на наш случай у компонента Auth припасено свойство authenticate (см. http://api.cakephp.org/class/auth-component) – ссылка на объект, который реализует функцию hashPassword.

И, собственно говоря, пример:

в файле app_controller.php помещаем класс для нашей хэш функции

а в функции AppController::beforeFilter пишем строчку

Готово!

-J-client -J-Xms32m -J-Xmx384m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Xverify:none -J-XX:CompileThreshold=100 -XX:+CompressedOOPS -XX:+AggressiveOpts -XX:+TieredCompilation -XX:+DoEscapeAnalysis -XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled

Таким образом мы разрешаем использовать до 384 мб памяти, компилировать в машинный код большинство функций и оптимизировать их.

Результат вас приятно удивит.

Дистрибутив и репозиторий лежат на гитхабе

Установка очень проста:

1. скачать последний релиз отсюда
2. Запустить нетбинс
3. Импортировать сниппеты (Tools -> Options -> Import)
4. Перезапустить нетбинс
5. Делать сайты в десять раз быстрее

Да, да, я знаю. Такое уже было раньше. Что я могу сказать – у меня были вопросы, а у Nate были ответы. Это первая часть, в ней рассматриваются общие вопросы о CakePHP и Cake3.

Общие вопросы

Похоже что у CakePHP будут сразу три версии, это несомненно может запутать новых разработчиков. Я не видел официальных заявлений на этот счет, так что поправьте меня, если я не прав:
- ветка 1.3 – для всех, кто пишет под PHP4
- ветка 2.0 – для тех, кто разрабатывает новые проекты под PHP5-5.2 или для тех, кто использует PHP 5.3 и хочет проапгрейдить приложения, написанные под CakePHP 1.2
- ветка 3.0 – для приложений на PHP 5.3

Почти верно. Как только ветка 1.3 станет стабильной, разработка версии 1.x прекратится, будут только исправляться ошибки и проблемы безопасности. Мы еще не определились с возможностью обратного портирования фич из 2.x, но это будет зависить от спроса на такую деятельность, чего не предвидится. и да, 2.0 позволит просто переносить приложения с 1.3 (его API практически не отличается от 1.2). 3.0, в свою очередь, находится в ранних стадиях разработки и не рекомендуется ни для чего, кроме экспериментов.

Сколько людей участвует в разработке трех новых версий Cake? Как они распределены по веткам в процентном соотношении?

В общем у нас 16 активных разработчиков, которые работают и над кодом и над другими вещами. Над 1.3 работают 6 человек, основную работу ведут Mark Story и Joël Perras. Для работ над 2.0 Larry Masters (глава проекта и корпорации cakedc.com) «одолжил» нам несколько разработчиков из своей корпорации, в частности Graham Weldon (a.k.a. Predominant), который работает над полной совместимостью кода с PHP5.

И, наконец, я – ведущий разработчик 3.0, а Joël, Garrett, David Persson, and Tim & Felix (из Debuggable) присылают мне патчи.

Вопросы про Cake3

Сейчас 1.3 и 2.0 имеют лицензию MIT. А у Cake3 будет лицензия BSD. Каковы причины этого и как это повлияет на разработчиков?

Честно говоря, это никак не повлияет на разработчиков. В плане того, что вы можете делать с программным обеспечением лицензия BSD разрешает столько же, если не больше, как и MIT. Смена лицензии произошла из-за моих предпочтений: BSD более старая лицензия с более определенной историей. gwoo поддержал это решение, так как BSD включает специальный раздел, который защищает брэнд CakePHP и Cake Software Foundation от коммерческого использования, против чего мы очень возражаем. Мы рады, что люди строят бизнес на нашем коде, но использование ими наших брендов для собственного продвижения не соответствует духу того, чем мы занимаемся.

Cake3 будет возвращать результаты запросов в виде объектов, а не в виде массивов. Я конечно могу ошибаться, но кажется ты предпочитал подход с использованием массивов? С чем связана смена позиции по этому вопросу, пришлось смириться или ты так и планировал?

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

Было ли что-нибудь взято из «топика ненависти», что ты не планировал реализовывать или хотел реализовать по другому, но пошел на поводу у сообщества?

Возможно одна из самых значимых смен точки зрения (не только из за «топика ненависти») – это поддержка составных ключей. Простые ключи хороши тем, что их легко использовать и на низком и на высоком уровне (REST API и тд) и это здорово. Но что я осознал, это то, что часто (опять же в контексте) существуют хорошие аргументы в пользу составных ключей. И хотя мы не поддерживаем их на высоком уровне абстракции, это та вещь, которую должен поддерживать любой хорошо спроектированных слой абстракции данных.

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

Ну, это зависит от приложения. В большинстве случаев вы просто должны были бы сделать это, потому что сейчас множество базовых вещей вроде паджинации и сессий просто не реализованы. Хотя это не имеет особого значения из-за новой структуры Cake3. Вы можете загружать классы и библиотеки довольно легко, можно даже подключить Doctrine вместо дефолтного ORM. Также большая часть API будет вам знакома, если вы уже разрабатывали на CakePHP.

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

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

Что происходит с юнит-тестированием в Cake3? Похоже что SimpleTest выкинули и заменили самописным инструментом тестирования

Опять же, это одно из тех решений, которые были сделаны за нас раньше, так как SimleTest был единственным доступным решением для PHP4. Теперь мы решили написать инструмент тестирования самостоятельно, причин тому несколько, но основные это
(а) мы хотели бы, чтобы люди могли запускать тесты сразу после установки
(б) нам нужна инфраструктура для тестов, которая заточена под наши нужды и позволяла бы нам тестировать так, как нам нужно. Причем тестировать не только ядро, но и приложения с плагинами.

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

Система фильтов выглядит очень мило и уже обсуждалась. Какая фича Cake3 кажется вам классной, но не получила внимания?

Самая значимая вещь, о которой я рассказывал не так много – это класс Media. Он интересен тем, что он берет на себя большую часть работы по обработке различных типов контента. Он размещается между контроллером и вью и позволяет присоединять различные обработчики для различных типов контента, причем как для ввода, так и для вывода. Это означает, что вместо того, чтобы создавать вью каждый раз, когда нужно чтобы метод контроллера отправил JSON, вы можете единожды присоединить обработчик, который будет формировать JSON из переменных, определенных в методе контроллера. А для HTML, по умолчанию определен фильтр, который отрисовывает шаблоны из каталога views/. Но даже в этом существует невероятная гибкость и теперь всё можно настраивать в одном месте.

Я тут кое-чего с фильтрами не могу понять. Ты привязываешь фильтр к методу, но не указываешь до или после метода его нужно применять, так?
Если до, то ты просто исполняешь код до того, как вызвать return $chain->next(…). А если нужно после? Вот так вот?

$ret = $chain->next($self, $params, $chain);
//my code
return $ret;

Да, именно так. Вы можете представлять себе написание фильтра как переопределение метода в подклассе, но вместо вызова родительского метода, вы вызываете $chain->next(…). У такого подхода множество преимуществ по сравнению с до- и после- фильтрами, например то, что все действия остаются в одной области видимости и вам не нужно разбивать их на два метода и беспокоится о сохранении состояния. Все операции теперь атомарны и изолированы, а код более понятен.

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

Эта статья – перевод. Оригинал – тут.

Привет, Nate, CakeFest завершился и слух об анонсе CakePHP 2.0 и Cake 3 постепенно распространяется. Можешь рассказать в общих чертах, что будет в новых версиях?

CakePHP 2.0 – это обновление текущей версии 1.x с переходом на строгую совместимость с PHP5, что означает, помимо выгоды от избавления от излишнего кода для поддержки PHP4, повышение производительности примерно на 25%.

Cake 3, с другой стороны, значительно отличается от текущей версии по ряду параметров. В основном тем, что с нуля переписан на PHP 5.3.

CakePHP 2.0 будет совместим с 1.x? Мы уже пережили значительный апгрейд с 1.1 на 1.2, апгрейд на 2.0 видимо будет еще более тяжелым?

Вообще-то, нет. CakePHP 2.0 будет практически 100% совместим на уровне API с грядущим CakePHP 1.3, который, в свою очередь, будет совместим с 1.2, за исключением некоторых устаревших (но еще работающих) методов.

Также, на случай миграции с 1.2 на 1.3/2.0, у нас есть инструкция, в которой будет сказано, какие небольшие изменения нужно будет внести в код существующих приложений.

Круто, то есть будет халявный прирост производительности для всех существующих 1.2 приложений?

Именно что.

Хорошо, вернемся к 3.0. Расскажи-ка немного о фундаментальных изменениях в PHP как языке и о том, как они повлияли на новое ядро CakePHP.

Ну, для CakePHP, переход от совместимости с PHP4 прямо на php5.3 – это очень большой шаг, не только из-за новых фич 5.3, но также и из-за фич PHP5, которыми мы наконец-то сможем воспользоваться.

Одна из важных фич PHP5.3, которая повлияла на новую архитектуру – пространства имён. Новое ядро организовано в виде пакетов, каждый из которых состоит, в свою очередь, из других пакетов.

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

Другая фича – замыкания. Замыкания – это анонимные функции (то есть функции, присвоенные свойству класса или переменной), которые могут наследовать контекст области видимости, в которой они объявлены. Это позволяет нам внедрять необходимую функциональность прямо в классы и методы, и в Cake3 мы используем их в системе фильтров.

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

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

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

Можно пример?

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

В Cake3 я могу сделать так:

applyFilter(‘_execute’, function($self, $params, $chain) {
$out = fopen(‘php://stderr’);
fwrite($out, $params['sql']);
fclose($out);
return $chain->next($self, $params, $chain);
});
?>

Здесь я получаю объект БД из класса Connections (это эквивалент вызова ConnectionManager::getDataSource() в 1.2) и присоединяю фильтр, который перехватывает метод _execute().
После этого, я мог бы отправить вывод в класс логгинга, но сейчас я просто хочу вывести запросы в лог ошибок, чтобы быстренько посмотреть что да как.
Фильтр будет применен каждый раз, когда запрос отправится в БД, таким образом все запросы будут записаны, как я и хотел.

Получается, что фильтры можно применить только к объекту, а не к классу?

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

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

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

Да, в чем-то модели поменяются, а в чем-то – нет. Например, записи по-прежнему будут получаться чем-то наподобие $posts = Post::find(«all»);
Это и все связанное с моделями должно быть сразу же понятно любому, кто сейчас работает с кэйком.

Но внутри, модели будут полностью новыми. Теперь они будут взаимодействовать с источниками данных через ограниченный набор методов с помощью объектов Query. Эти объекты очень полезны, так как они позволяют нам инкапсулировать большую часть работы по генерации запросов, которая раньше была разбросана по нескольким разным классам. Кроме того, так как query-объекты работают с уровнем данных и так как объекты ядра могут быть заменены пользовательскими, то пользователи могут легко модифицировать и расширять синтаксис SQL, поддерживаемый кэйком.

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

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

Если записи теперь объекты, получается что CakePHP получит полноценную реализацию ActiveRecord?

Ну да. С новой фичей PHP5.3 – Late Static Binding мы можем обращаться к статическим классам, как показано выше.

Хорошо. Моя личная цель – прекратить испльзовать реляционные БД для неструктурированных данных в 2009 году. В Cake3 будет поддержка чего-нибудь такого?

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

Невероятно! И когда же мы получим все эти крутанские штуки? Есть какой-нибудь план по выпуску Cake3?

Хотя код доступен непосредственно на code.cakephp.org, трудно сказать когда будет официальный релиз. Но ожидайте значительного объема работы в ближайшие месяцы.

У Cake3 появились новые фичи и новые требования к серверной части. Что если сравнить его с такими фремворками, как Ruby on Rails, Django и тд?

Ну, миграция с PHP 5.2 на 5.3 быстрая и безболезненная, так как в области существующих фич мало что изменилось. Как всегда PHP – это самая простая в использовании и самая простая в развертывании платформа в вебе. Разместить сайт – это всего лишь скопировать файлы в корень сайта.

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

Это перевод, оригинал – здесь

Ссылки:
CakePHP 2.0 – http://code.cakephp.org/cakephp2
Cake3 – http://code.cakephp.org/cake3

Для чего он нужен?

В DebugKit добавляется новая панель – интерактивная консоль CakePHP. В ней можно:

выполнять простой пхп-код
10 % 4 //вернет 2
is_array(49) //вернет false

выполнять SQL
SELECT id FROM users WHERE email = 'test@test.com' //вернет id пользователя
UPDATE posts SET published = false; //вернет "No results found.", но обновление выполнит

использовать функции
__('Test Message', true) //возвратит перевод текста в соответствии с установленной локалью
Configure::write('Config.language', 'es');
__('Test Message', true); //возвратит перевод текста по-испански

использовать библиотеки
Security::hash('my_pAssw0rd', null, true) //возвратит хэш пароля
Set::extract('/id', array(array('id' => 3), array('name' => 'test', 'id' => 4))) //array(3, 4)

использовать хелперы
$html->link('Posts', array('controller' => 'posts')) //возвратит html-код для ссылки и саму ссылку
$form->input('Post.title'); //возвратит код поля ввода и само поле

использовать код вашего приложения
Post::find('first') //The first record from your posts table
User::findById(3) //The user record for id 3

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

Configure::write('debug', 2);
User::findByIdd(3) //покажет ошибку

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

$i = 10;
$i ++;
echo $i;

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

Post::find('first');
$Post->find('first');
Post->find('first');
$this->Post->find('first');

Установка.
1. Скачать плагин с гитхаба
2. Поставить DebugKit из транка
3a. В AppController подключить панель
$components = array('DebugKit.Toolbar' => array('panels' => array('Interactive.interactive')));
3б. Использовать через консоль
cake interactive

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

Вот действия add и edit, созданные через консоль:

Как вы видите, весь метод add продублирован в методе edit. Мы можем избавиться от метода add и заставить метод edit обрабатывать создание новых записей. Есть несколько способов сделать это.

Можно удалить метод add() полностью, добавив маршрут, который перенаправляет /add на метод edit

Или же можно все ссылки, указывающие на /add, заменить на /edit

Также потребуются некоторые изменения в методе edit.
Удалите первый блок if:

Измените последний блок if c:

на:

Метод edit теперь должен выглядеть так:

Отображение

Можно удалить файл add.ctp, потому что он больше никем не вызывается. Add.ctp и edit.ctp по умолчанию очень похожи, так что таким образом удастся избежать избыточности кода.
Отображение edit будет работать для создания новых записей без каких-либо изменений.
Если есть необходимость, то можно изменять подписи в зависимости от текущего действия.

Выведет «Добавить запись» или «Изменить запись» в зависимости от ситуации (и при наличии локализации, конечно же).

Это – перевод отрывка из книги Super Awesome Advanced CakePHP Tips