Может кому пригодится
Create an ARP-Class for any Extension Table.
http://typo3.org/extensions/reposito...eatearp/0.2.2/

ЗЫ:
ветку (полветки) пора в разработку расширений?

Если я правильно понял, эта штука не умеет связывать таблицы? Если так, то, как говорится, фтопку.

//У меня в своё время была безумная идея сделать генератор Doctrine-классов на основе $TCA

А как бы она автоматически связывала таблицы? Дело в том, что это часто зависит от формата вывода данных. То есть часто это определяется не моделью, а view.

Я сейчас делаю отдельное расширение, которое на основе конфига в typoscript, где описан какой должен быть вывод, включая взаимосвязь таблиц и описание форматирования всех значений, строит запрос к базе данных, причем один-единственный запрос. Затем расширение парсит ответ из БД, форматирует его и вставляет в шаблон, который описан в том же самом typoscript файле и возвращет готовый HTML.

В результате, там где в commerce, например для вывода list view, когда много атрибутов в продуктах и артикулах, используется порядка ста запросов к БД, мое расширение делает один! запрос, но сложного вида - в одном запросе там например бывает 25 вложенных таблиц, скорость обработки такого сложного запроса в MySQL не намного меньше, чем обработка одного простого запроса, и в результате нагрузка на БД снижается очень значительно, поскольку вместо ста запросов делается один. Также большой плюс в том, что запрос строится автоматически, на основании конфига. При таком подходе, я даже не вижу смысла использовать ORM, поскольку с отдельными записями работа не идет. Разработчик строит только описание вложенных таблиц, задает самые общие условия для выборки, например для list view в commerce задает какие продукты надо вывести, а расширение само строит запрос, связывая таблицу продуктов с артикулами, далее связывает со списком атрибутов, далее подключает таблицы значений атрибутов итд ..., все это в одном SQL запросе, а на выходе из расширения получаем готовый HTML.

Я не очень понимаю, как это. Как во view можно связать таблицы? Если это действительно происходит, то это полное нарушение всякой архитектуры. Таблицы должны быть связаны в модели. Т.к. модели в TYPO3 нет, то они должны быть связаны в $TCA.

Пример можете привести? Желательно простой... Когда нужно связывать таблицы во view?

разработчики Symfony2 намеряли скорость в 60 раз быстрее Flow3
http://symfony-reloaded.org/fast :(

Сравнение - ни о чем... опять сравнивается время холодного запуска фреймворка.... ну и что?

<?php echo 'Hello World'; ?> - рвет всех в любом случае :D... так что ж тогда на чисто PHP никто не стремиться писать?

По тесту Hello World Symfony2 быстрее в 69 раз :) - но я говорил не про этот тест.

Второй тест, где Symfony2 быстрее в 60 раз, был посложнее:
основной шаблон + подшаблон (15 вставок) + 30 ссылок с роутингом + декоратор, то есть вряд ли можно сказать, что это только время холодного старта, скорее тест на время отклика, скорость шаблонизатора и роутинга

И Flow3 смог обработать всего 20 запросов в секунду, это даже модель не инициализировали (а с учетом DDD там скорости ждать не приходится) и запросов к БД не делали,
что же будет когда TYPO3v5 на ней сделают? :(

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

Интересно эти "тормоза" можно победить, или FLOW3 и интернет будут несовместимы? Что дает такой эффект?

Сложно сказать откуда тормоза берутся, я исходники Flow3 пока особо не изучал. Там много инноваций - AOP, IoC, DDD, Репозиторий итп, наверное инициализация всего этого жрет много ресурсов.

Возможно быстродействие допилят рано или поздно, но учитывая что его делают уже 2 года, то я бы особо не рассчитывал что в ближайший год появится 5 версия TYPO3 годная для продакшена.

Насчет extbase и fluid - текущая версия уже вполне юзабельная.

С производительностью проблем нет: на реальном сайте скорость генерации списка, который дергает 5 таблиц и рендерит картинки - в пределах 1-1,2 сек (согласно тому, что пишет админ панель). Т.е. ничем не хуже обычного традиционного экстеншена.

Extbase Кикстартер работает, хотя еще не доделан до уровня старого кикстартера.