Введение

Да, да, я знаю. Такое уже было раньше. Что я могу сказать — у меня были вопросы, а у 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(…). У такого подхода множество преимуществ по сравнению с до- и после- фильтрами, например то, что все действия остаются в одной области видимости и вам не нужно разбивать их на два метода и беспокоится о сохранении состояния. Все операции теперь атомарны и изолированы, а код более понятен.

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

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