В наличии имеется AJAX сайт за nginx на CentOS 6, хочется обойтись минимальными телодвижениями для обеспечения его индексации. Основная идея - исполнять приложение в каком-нибудь headless браузере и отдавать результат поисковику.

Подготовка к сканированию

В секцию head главной страницы вставляем <meta name=”fragment” content=”!” />. Увидев такое, поисковики понимают, что на этой странице есть содержимое, которое генерируется яваскриптом, но при этом доступное по запросу, сформированному специальным образом. Подробности и полная спецификация есть у гугла и яндекса.

Вкратце, происходит вот что:

• Поисковик заходит на главную страницу сайта и видит мета-тэг 'fragment'
• Теперь все сссылки на этой странице, которые начинаются c #! будут заменениы на ?_escaped_fragment=. То есть, было #!/movies/1 становится ?_escaped_fragment=/movies/1. по спецификации еще положено, что значение параметра будет подвергнуто urlencode, но на практике роботы не всегда так делают
• Поисковик запрашивает у сервера данные по ссылкам в новом формате и сервер должен отдавать такой же html, какой видит пользователь в браузере

Рендеринг HTML

Для получения хтмл будем использовать PhantomJS. Проще всего его установить через npm, у меня он уже был установлен, если у вас нет, то yum install npm или что-то этом роде, а потом

npm install phantomjs

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

var server = require('webserver').create();
var port = 19003;

var getPage = function(url, callback) {
    var page = require('webpage').create();

    // запрашиваем страницу, ждём 200 мс, чтобы ангуляр успел завершить работу
    // можно попросить сайт отмечать готовность самостоятельно, но это потребует изменения приложения
    // а у нас все-таки простое решение
    page.open(url, function() {
        setTimeout(function() {
            page.evaluate(function() {
                // удаляем мета-тэг фрагмента, иначе контент не будет проиндексирован
                // заодно удалим скрипты, потому что отдаём готовый html
                $('meta[name=fragment], script').remove()
            });

            callback(page.content);
            page.close();
        }, 200);
    });
};

// запускаем встроенный в phantomjs веб-сервер
server.listen(port, function(request, response) {
    response.headers = {
        'Content-Type': 'text/html'
    };

    var regexp = /_escaped_fragment_=(.*)$/;
    var fragment = request.url.match(regexp);

    var url = 'http://localhost:19002/#!' + decodeURIComponent(fragment[1]);

    // получаем хтмл и отдаём роботу
    getPage(url, function(content) {
        response.statusCode = 200;
        response.write(content);
        response.close();
    })
});

Запускаем скрипт

phantomjs renderbot.js

Проверяем результат работы

wget http://localhost:19003/?_escaped_fragment_=/movies/1

Можно и из браузера. Должен вернуться html полноценной страницы.

Отправлем решение на живой сервер

В nginx внесем небольшие изменения

if ($args ~* _escaped_fragment_) {
    proxy_pass http://localhost:19003; #phantomjs
}

proxy_pass http://127.0.0.1:19002; #оригинальный сайт

В общем, алогритм такой:

• Nginx обрабатывает все запросы как обычно и передаёт их бэкэнду на порт 19002
• До тех пор, пока не встречает в урл _escaped_fragment_. очевидно, что это запрос от робота поисковика (ну или от кого-то очень любопытного), такой запрос nginx передаёт серверу phantomjs на порт 19003
• Наш скрипт для phantomjs вычленяет все содержимое урл от _escaped_fragment_ до конца строки, раскодирует его и делает запрос уже с хэштэгом к бэкэнду, даёт неторое время на выполенения яваскрипта на странице и возвращает полученный хтмл обратно поисковому роботу

Что дальше?

В посте представлено решение в общих чертах, его уже можно применять в продакшене. Но вожможно, потребуется добавить кэширование отрисованных страниц и обработку ошибок (таймауты и тому подобное) в скрипте phantomjs. Можно сделать это самому, а можно воспользоваться различными сервисами, которые все сделают сами за некоторое вознаграждение, например, prerender.io сотоварищи. It's up to you.

Для управления IIS 7+ существует библиотека Microsoft.Web.Administration. Добавляем её в проект через NuGet

Install-Package Microsoft.Web.Administration

HTTP-привязка

• создаём инстанс ServerManager
• находим сайт
• добавляем домен
• не забываем сохранить изменения.

Формат записи домена - IP:Port:Hostname

Упрощенно выглядит так

using (var iisManager = new ServerManager())
{
    var site = iisManager.Sites["SiteName"];

    site.Bindings.Add(string.Format("*:{0}:{1}", 80, "user1.localtest.me"), "http");

    iisManager.CommitChanges();
}

C HTTPS слегка сложнее, потому что нужен сертификат. Теоретически, можно генерировать CSR, отдавать его пользователю и получать от него CRT. Но на мой взгляд это слишком эпично, поэтому от пользователя будем требовать PKCS12 (PFX)

• открываем сертификат
• добавляем в хранилище
• добавляем домен, так же как и для HTTP, но еще передаём хэш сертификата и имя хранилища
• говорим IIS, чтобы он требовал указания имени хоста для HTTPS запросов, иначе невозможно использовать несколько сертификатов для одного IP

using (var iisManager = new ServerManager())
{
    //...
    var certificate = new X509Certificate2("path/to/certificate.pfx", "certificate_password", 
        X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.MachineKeySet);

    var store = new X509Store(StoreName.My, StoreLocation.LocalMachine);
    store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadWrite);
    store.Add(certificate);
    store.Close();

    var hash = certificate.GetCertHash();
    var storeName = store.Name;
    var bindingData = string.Format("*:{0}:{1}", 443, "user1.localtest.me");

    var binding = site.Bindings.Add(bindingData, hash, storeName);
    binding.Protocol = "https";
    binding.SetAttributeValue("sslFlags", 1);
    //...
}

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

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 описываем новое подключение

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

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

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

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

Configure::write('Session.save', 'database');
Configure::write('Session.model', 'Session');
Configure::write('Session.database', 'mongo');

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

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

/**
* @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 и передаем ему настройки

var $actsAs = array(
    'Scope.Scope' => array(
        'field' => 'site_id',
        'value' => SITE_ID,
    )
);

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

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

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

$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 помещаем класс для нашей хэш функции

class MyHash {
    public function hashPasswords($data) {
        if (is_array($data) && isset($data[‘User’])) {
            if (isset($data[‘User’][‘username’]) && isset($data[‘User’][‘password’])) {
                $data[‘User’][‘password’] = sha1( md5 (‘SeCrEt’ . $data[‘User’][‘password’] . ‘KeY’) );
            }
        }
        return $data;
    }
}

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

$this->Auth->authenticate = new MyHash();

Готово!

В /etc/netbeans.conf или в ярлык для запуска IDE нужно добавить следующие опции

-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. Cкачать последний релиз отсюда
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