Yii 2.0 RC

>> Почему не поддерживает github репозитории? Поддерживает он.

Я ему скармливал ровно тот же самый bower.json, который на bower отрабатывает без проблем, и он отваливался с ошибкой not found на тех пакетах, которых нет на bower.io/search, из чего был сделан вывод, что гитхаб он не умеет.

>>… собирать на локальной машине а потом уже деплоить.

Сейчас мы так и делаем, храним пакеты под vcs. bowerphp ставился как раз для того, чтобы при деплое подтягивать зависимости, не устанавливая nodejs на прод машину. Но работал он ну очень нестабильно, то и дело отваливаясь на всяких «jquery not found», хотя рядом composer вообще не вякает даже (вообще мне композер очень нравится стабильностью работы, даже рубиевский бандлер не такой). А еще странно, что капистрано не отваливался с ошибкой, когда bowerphp отваливался. Т.е. приложение по факту успешно проходило деплой, но без пакетов.

Велосипеды это конечно хорошо, но давайте прикинем. Propel хоть в каком-то виде появился за год до Prado. Doctrine начали пилить в 2006-ом, через год после первого релиза Symfony. Yii 1.0 вышел где-то в 2008-ом… на дворе 2014-ый год… хм… велосипеды… их все писали. Проблема Yii в том что (по крайнемере в первых версиях) продолжают писаться велосипеды. Я больше не о компонентах фреймворка, их можно воспринимать как полноценные решения, а больше о том духе который царит в Yii сообществе. Велосипеды. Просто забавная статистика на основе тех проектов которые я видел.

Пробовал я как-то интегрировать Symfony/Forms и Doctrine в Yii1,1. Жить можно. Только тяжко это и делалось только в рамках рефакторинга одного легаси проекта. Затем был PHP-DI, HttpKernel и полная смена фреймворка.

Считаете, что создание модели для pivot table с доп. полями — это правильное решение? Вопрос без сарказма.

согласен, выглядят они прикольно, по js'ному

НО возьмем пример, в виджете, фукнция run:

$articlesCount = Article::find()
                ->published()
                ->count();

$videosCount = Video::find()
                ->published()
                ->count();

$pollsCount = Poll::find()
                ->published()
                ->count();

return $this->render('widget-view', [
      'articlesCount' => $articlesCount, 
      'videosCount' => $videosCount,
      'pollsCount' => $pollsCount,
]);

задача — как это все закешировать:
вариант 1:

$articlesCount = Article::getDb()->cache(function(){
   return Article::find()
                ->published()
                ->count();
}, 3600);

$videosCount = Video::getDb()->cache(function(){
    return Video::find()
                ->published()
                ->count();
}, 1800);

$pollsCount = Poll::getDb()->cache(function(){
   return Poll::find()
                ->published()
                ->count();
}, 43200);

return $this->render('widget-view', [
      'articlesCount' => $articlesCount, 
      'videosCount' => $videosCount,
      'pollsCount' => $pollsCount,
]);

чет дофига анонимок, давайте по другому
вариант 2:

\Yii::$app->db->cache(function() use(&$articlesCount, &$videosCount, &$pollsCount) {
$articlesCount = Article::find()
                ->published()
                ->count();

$videosCount = Video::find()
                ->published()
                ->count();

$pollsCount = Poll::find()
                ->published()
                ->count();
}, 3600);

return $this->render('widget-view', [
      'articlesCount' => $articlesCount, 
      'videosCount' => $videosCount,
      'pollsCount' => $pollsCount,
]);

сразу встает проблема — одинаковое время кеширования, и переменные в use, и это мы туда еще параметров запросов никаких не передавали.
другая проблема — у нас модели (или просто Query) могут обращаться к разным базам, одним махом уже не покешируешь.

резюмируя: на мой взгляд:
1. текущая реализация подходит для примеров из документации, в реальном проекте обычно код сложнее.
2. появляется реально лапша коллбеков, за что я всегда любил yii — что код получается логичным, читабельным и минимум обвеса. Сейчас же в угоду паттернам клиенский код не удобный. Осталось добавить еще вызов пары фабрик, сервис локаторов и получим симфони или зенд.
3. отладка — иногда удобно пройтись по построению запроса дебаггером и посмотреть потом в самом конце в queryInternal что туда пришло и что оно вернуло, с анонимками — сразу не попадешь в фукнцию, надо идти до call_user_func — эт такое, придираюсь
4. возможно добавление метода cache в Query и не отвечает канонам, паттернам и всего всего такого умного, но по факту оно удобнее и фукнциональнее

разумеется, ИМХО

Ой, ой. Извините, я затупил. Тестировал у себя на разрабатываемом проекте (структура как на app-advanced) и случайно открыл не ту «часть» приложения, которая и вызвала ошибку (как раз после обновления на RCv поэтому и связал с этим). А когда на basic ошибку проверял, то просто убрал user не посмотрев в контроллеры