Основным изменением в ядре является переход на использование namespaces и traits, поэтому не получится просто так перевести новые проекты на новое ядро. Вторым не менее важным изменением является использование нового VT и, как следствие, использование нового генератора mfd.

Организация файлов фреймворка теперь поддерживает git, поэтому только папка web/lib.eaze является git submodule'м. В lib.eaze находятся:

• Eaze.Core
• Eaze.Database
• Eaze.Helpers
• Eaze.Model
• Eaze.Modules
• Eaze.Site

Base.Tree и Base.VFS теперь расположены в отдельном репозитории eaze-vfs и получили идеологию пакета. Тесты рабочие и находятся в lib-tests.

Весь пользовательский код по-прежнему находится в web/lib.

Благодаря поддержке неймспейсов появилась возможность использовать composer. Для этого необходимо немного изменить eaze.*php файлы для включения автозагрузчика composer.

HtmlHelper, Eaze.Database/MySql, FirePHP

• Статический анализатор PHPStorm → Inspect Code проходит по lib.eaze без ошибок
• trait TBaseFactory – с помощью него убрано дублирование во всех *Factory, улучшен type hinting и документация
• В скомпилированном шаблоне, который находится в папке cache можно посмотреть путь исходного шаблона
• BaseFactory::GetObjectTree – 5 = максимальный уровень вложенности для получения объекта из базы данных
• FactoryWrapper – динамическое изменение $mapping в Factory
• ObjectInfo – класс для простого получения id объекта, название id поля через $mapping в Factory
• return Page::Next из Action→Execute() – возможность переходить к следующему uri в pages.xml при пересечении uri
• IComplexObject – пред/пост-обработка для объектов, которые получаются через Factory

Для сомневающихся, зачем это все нужно Велосипеды все еще актуальны.

Как это ни печально, но на скорость загрузки PHP скриптов до сих пор влияет количество include/require файлов (даже с opcacher'ами). И в ближайшем будущем, судя по roadmap php ничего не поменяется.

Что для этого есть в composer почитать? php composer.phar dumpautoload -o – этой командой composer создаст classmap, в котором будет массив файл → класс. При каждом запросе он не будет сканировать файловую систему, а будет просто делать require необходимого класса.

При разработке новой версии eaze мы попытались сравнить такой подход (небольшая модификация Package) и существующий (все классы для одного URI в одном файле). Существующий оказался на 15-25 процентов быстрее. Опять же это синтетические тесты, но они показательны. Сомневающиеся могут самостоятельно организовать данный тест.

В Yii есть похожая концепция – yiilite.php. Но судя по цитате, они решили проблему только для ядра, и то не полностью:

Стоит заметить, что использование yiilite.php без APC может отрицательно повлиять на производительность,
так как yiilite.php включает в себя классы, которые могут не требоваться при каждом запросе 
и отнимать некоторое время на парсинг.

sergeyfast:

• Я не могу доверять стороннему коду на PHP, который осуществляет обработку урлов, автозагрузку классов и работу с базой данных (включая ORM). Я могу лишь доверять только своему коду, в котором я уверен на 99%, который я могу контролировать и в котором я могу быстро найти ошибку.
• В Eaze есть минимальный набор классов, который удовлетворяет потребностям при разработке веб-проектов.
• В Eaze есть mfd, который делает CRUD гораздо умнее, чем существующие инструменты в различных фреймворках.
• Ну и субъективно, при разработке на Eaze код получается более простой и чистый.
• Да, у Eaze нет сообщества и документации, но зато есть богатый опыт в проектах, в которых можно подсмотреть варианты решения задачи. В этой wiki все же надо постараться описать стандартные задачи и их решения.