Просмотр полной версии : FLOW3 и фремворки в TYPO3
А вот новый фреймворк от разработчиков тайпы: http://flow3.typo3.org/
Я пока приостановил изучение тайпы до выхода 5-й версии и всего остального, хотя ждать - придётся.
Что наработано в сайтах - то и клонирую пока :)
Пятая версия может выйти через год. А может через полтора. Долго ждать придется...
Хотя по слухам обещают flow3 в качестве расширения к 4.x
Какой смысл ждать Flow3? Это совершенно новая ветка TYPO3. Пока она дойдет до рабочего состояния может пройти несколько лет. В любом случае 4 версия и 5 версия будут развиваться параллельно. 5я версия это некорректное название, там от современной TYPO3 наверное только typoscript останется :D .
Смысл ждать в том, чтобы на нём работать. Может, и помочь им чем. Пока же можно делать сайты на той базе, что изучена и опробована, не копая нутро тайпы4 дальше вглубь - сейчас, на мой взгляд, это потеря времени. Такое вот личное мнение.
Просто никто не знает какое будущее ждет TYPO3 ver 5. Каспер в нем участия не принимает, когда сделают не известно, захотят ли основные разработчики расширений перейти с ver 4 на ver 5, тоже не известно. Дмитрий Дулепов, например, который сейчас поддерживает много расширений, в том числе темплавойлу, относится критически к ver. 5.
Вот что он пишет например
I see no point writing anything for v5 now. I do not think it is anywhere near to be used on any real site, so I do not want to spend time on anything theoretical. MVC is not as common as traditional approach, so if I ever start writing new news extension, I will do do it in traditional TYPO3 way. I have absolutely practical approaches, not scientific.
Когда сделают, уже известно - собираются представить v5 на T3CON09. Если основные разработчики расширений и не захотят переписывать свои расширения под v5, за них это сделают более прогрессивные люди. (Хотя конечно они будут заниматься этим только если программирование под фреймворк будет в достаточной степени "fun"). Robert Lemke на мой взгляд совершенно не дурак, и Core Team v5 думает не только о фичах, но и о рекламе будущего продукта, привлечении больших масс PHP-разработчиков.
Ну хоть это и прогресивно, но ни Каспер, ни Дулепов под MVC вроде писать не собираются. Дулепов пишет, что будет писать в традиционном стиле, как и сейчас. А насчет того, что скоро представят, это еще не значит, что можно начинать делать сайты на v5. Обычно до полностью рабочей версии проходит довольно много времени.
When will FLOW3, TYPO3 5.0 and the CR be available?
A first fun-to-play-with snapshot of FLOW3 will be released this spring and we expect a first 1.0.0alpha before the end of 2008. TYPO3 5.0 should be available at some point in 2009. We don't have estimates yet for the Content Repository.
Как я вижу, Typo5 (Flow3) это уже фреймворк. Фреймворк в полном его понимании. MVC тому только лишнее подтверждение. И хоть это "больше традиционный" подход, ничего лучше пока не придумали. По этому принципу, как я вижу, работают все фреймворки (Django, Zope, Ruby-on-Rails ...).
Чем тогда TYPO3 v5 будет отличаться от других MVC фреймворков? И чем он будет лучше них? Почему бы не использовать уже сейчас тот же RoR, а не ждать рабочей TYPO3 v5?
Лично мне пока больше нравится подход Каспера, когда он скомбинировал два типа CMS в одной - те которые работают на основе дерева страниц и те, которые работают как web application framework. Будет ли v5 иметь какие-то отличия от других MVC систем и станет ли v5 популярной это еще вопрос.
Вроде все отличия на сайте прописаны:
Флоу
1. ПХП (поэтому сравниваем с Кейк и Симфони, не с РоР и Джанго)
2. АОП
Тайпо
3. контент репозитори
ИМХО хотят совсем крупного зверя сделать и вернуть (ИМХО-ИМХО-ИМХО) статус "самой крутой свободной системы" - заточить под корпоративный документооборот и сложные схемы данных. Лично я правда не владею материалом - с кем они так хотят конкурировать - с системами на Яве, наверное?
Посмотрим что выйдет,
лично я скептически отношусь к созданию новой ветки TYPO3 несовместимой со старой. ИМХО лучше бы эти силы тратились на доработку существующей ветки и последовательное ее улучшение с хорошей обратной совместимостью.
И еще, лучше бы это назвали не TYPO3 v5, а как-то по-другому, а то те новые разработчики, кто мог бы участвовать в v4, теперь будут считать, что это уже устаревшая ветка и надо ждать v5.
Чем тогда TYPO3 v5 будет отличаться от других MVC фреймворков? И чем он будет лучше них? Почему бы не использовать уже сейчас тот же RoR, а не ждать рабочей TYPO3 v5?
Лично мне пока больше нравится подход Каспера, когда он скомбинировал два типа CMS в одной - те которые работают на основе дерева страниц и те, которые работают как web application framework. Будет ли v5 иметь какие-то отличия от других MVC систем и станет ли v5 популярной это еще вопрос.
Собственно, это вполне себе выход - использовать нормальные фреймворки на нормальных языках программирования. Как-то до сих пор все экстеншены к v4 не очень MVC. Да и прочих преимуществ фреймворков нет - отсутствие внятного ORM (TCA и t3lib_db не стоит рассматривать в качестве ORM), отсутствие хороших библиотек для построения форм и т.п. - всё это приводит к огромному количеству откровенного мусора в TER и сводит на нет преимущества "второго типа систем".
Дорабатывать в v4 есть много чего и это дорабатывается, что радует. С другой стороны, в ядре очень много запутанного и неясно как работающего кода, который смог бы отрефакторить наверное только Каспер, и то вряд ли... И дело тут скорее в том, что без того же АОП очень сложно реализовать версионинг, воркспейсы и локализацию так, чтобы это понял читающий код человек с первого раза.
Грубо говоря, мне, как программисту, PHP4 и "традиционный подход" в TYPO3 4 в настоящий момент абсолютно не интересен. Из-за этого же я игнорю Drupal и много остального. А вот Typolight думаю посмотреть в ожидании TYPO3 5, он, конечно, намного проще, но может быть нишу свою у меня найдёт :) Ну и ZF ещё интересен, пробую, хотя это фреймворк, и ждать нормальной CMS на нём, по-моему, придётся ещё дольше, чем TYPO3 5... а, может, и наоборот ;)
Uruguaygrep
28.03.2008, 13:02
Чем тогда TYPO3 v5 будет отличаться от других MVC фреймворков? И чем он будет лучше них? Почему бы не использовать уже сейчас тот же RoR, а не ждать рабочей TYPO3 v5?
Лично мне пока больше нравится подход Каспера, когда он скомбинировал два типа CMS в одной - те которые работают на основе дерева страниц и те, которые работают как web application framework. Будет ли v5 иметь какие-то отличия от других MVC систем и станет ли v5 популярной это еще вопрос.
Можно и сейчас использовать тот же ROR или другой фреймворк. Почему бы и нет. Если есть задачи (а они есть) которые обычной ЦМС не решаются.
Кстати, еще раз прочитал внимательно о 5 версии. Всетаки Flow3 -- это новый разрабатываемый фреймворк. Typo3 v5 -- это ЦМС, которая будет разрабатыватся на фреймворке Flow3.
Признаюсь честно, первый раз когда писал сообщение не до конца вник.
Можно и сейчас использовать тот же ROR или другой фреймворк. Почему бы и нет. Если есть задачи (а они есть) которые обычной ЦМС не решаются.
Кстати, еще раз прочитал внимательно о 5 версии. Всетаки Flow3 -- это новый разрабатываемый фреймворк. Typo3 v5 -- это ЦМС, которая будет разрабатыватся на фреймворке Flow3.
Признаюсь честно, первый раз когда писал сообщение не до конца вник.
Так и есть, то есть надо ждать пока оба продукта выйдут на рабочий уровень и избавятся от детских болезней. То есть планируется в этом году получить только альфу версию Flow 3. Альфа TYPO3 v5 значит будет в следующем году. Сколько лет пройдет до того момента когда можно будет сделать на них реальный сайт, который сейчас можно сделать на v4 это сложно сказать.
Собственно, это вполне себе выход - использовать нормальные фреймворки на нормальных языках программирования. Как-то до сих пор все экстеншены к v4 не очень MVC. Да и прочих преимуществ фреймворков нет - отсутствие внятного ORM (TCA и t3lib_db не стоит рассматривать в качестве ORM), отсутствие хороших библиотек для построения форм и т.п. - всё это приводит к огромному количеству откровенного мусора в TER и сводит на нет преимущества "второго типа систем".
Дорабатывать в v4 есть много чего и это дорабатывается, что радует. С другой стороны, в ядре очень много запутанного и неясно как работающего кода, который смог бы отрефакторить наверное только Каспер, и то вряд ли... И дело тут скорее в том, что без того же АОП очень сложно реализовать версионинг, воркспейсы и локализацию так, чтобы это понял читающий код человек с первого раза.
Вот ИМХО и надо внедрять это в v4 – ORM, формы, MVC, AOP итп. Не обязательно же сразу выкидывать t3lib_DB. Можно сделать альтернативную билиотеку t3lib_db_orm, например, и через несколько версий, когда она будет уже полностью рабочей, можно старую t3lib_db объявить depricated и еще через несколько версий удалить. То же сделать с MVC - сделать альтернативную библиотеку вместо tslib_pibase, tslib_pibase_MVC итп..
Понятно что разбираться с чужим ядром мало кому нравится, а разработать что-то новое интереснее, вот все и кинулись на v5 :). Но ИМХО больше пользы будет не от револиции, а от эволюции v4 ветки, с последовательной заменой частей ядра, чтобы была приемлимая совместимость и можно было бы сайтам мигрировать постепенно.
Вообще можно было бы сделать такой же подход, как например в разработке FreeBSD, там поддерживается несколько различных веток: STABLE - стабильная ветка, сейчас это версии 7.x в которую больше не добавляют новые фичи, а вылизывают старые и фиксят баги и CURRENT - ветка версий 8.x, в которой все текущие разработки и новые фичи. Когда 8 ветка подрастет, она станет STABLE, а новые фичи пойдут уже в 9 ветку - CURRENT.
И тогда можно выбирать чем пользовать или самым новым или самым стабильным. А то сейчас мы имеем две несовместимые ветки TYPO3. Старая ветка многими считается устаревшей, а значит кол-во разработок под нее снизится. Новая ветка неизвестно когда будет и на ней придется сайты делать с нуля. Все это может привести TYPO3 в не очень хорошую ситуацию.
Uruguaygrep
28.03.2008, 21:12
Вот ИМХО и надо внедрять это в v4 – ORM, формы, MVC, AOP итп. Не обязательно же сразу выкидывать t3lib_DB. Можно сделать альтернативную билиотеку t3lib_db_orm, например, и через несколько версий, когда она будет уже полностью рабочей, можно старую t3lib_db объявить depricated и еще через несколько версий удалить. То же сделать с MVC - сделать альтернативную библиотеку вместо tslib_pibase, tslib_pibase_MVC итп..
Уже внедряют. Библиотека lib/div (http://wiki.typo3.org/index.php/MVC_Framework) как раз и есть то о чем вы говорите. Более того, под эту библиотеку уже и Kickstarter подтянули. Теперь он умеет создавать скелеты MVC.
Вообще можно было бы сделать такой же подход, как например в разработке FreeBSD, там поддерживается несколько различных веток: STABLE - стабильная ветка, сейчас это версии 7.x в которую больше не добавляют новые фичи, а вылизывают старые и фиксят баги и CURRENT - ветка версий 8.x, в которой все текущие разработки и новые фичи. Когда 8 ветка подрастет, она станет STABLE, а новые фичи пойдут уже в 9 ветку - CURRENT.
Так и есть. Разрабатывается 4.2 и поддерживатеся ветка 4.1.
И тогда можно выбирать чем пользовать или самым новым или самым стабильным. А то сейчас мы имеем две несовместимые ветки TYPO3. Старая ветка многими считается устаревшей, а значит кол-во разработок под нее снизится. Новая ветка неизвестно когда будет и на ней придется сайты делать с нуля. Все это может привести TYPO3 в не очень хорошую ситуацию.
Почему несовместимые? 4.1 и 4.2 совместимы.
Я, честно говоря не совсем понял. Какая ветка считается устаревшей?
Если вы все же сравниваете 5 ветку, то для такого глубокого анализа ИМХО еще рано. Думаю в 5 ветке еще не написано ни строчки кода, так как под нее еще не готов фреймворк.
Уже внедряют. Библиотека lib/div (http://wiki.typo3.org/index.php/MVC_Framework) как раз и есть то о чем вы говорите. Более того, под эту библиотеку уже и Kickstarter подтянули. Теперь он умеет создавать скелеты MVC.
Я в курсе про lib/div, есть и другие MVC расширения, вот и надо в этом направлении идти.
Почему несовместимые? 4.1 и 4.2 совместимы.
Я, честно говоря не совсем понял. Какая ветка считается устаревшей?
Если вы все же сравниваете 5 ветку, то для такого глубокого анализа ИМХО еще рано. Думаю в 5 ветке еще не написано ни строчки кода, так как под нее еще не готов фреймворк.
Я говорил про 4.x и 5.x. Про то, что они будут не совместимы уже известно, это написано в FAQ.
Вот пост Лемке в мейлинг-лист ECT, который занимается в том числе и lib/div. Извиняюсь за многабукаф. Кстати, разработка lib/div сейчас практически приостановлена, если я правильно понимаю.
http://lists.netfielders.de/pipermail/typo3-team-extension-coordination/2007-August/002514.html
--
Писать с нуля на PHP под t3v4 инструменты, аналогичные RoR или Django - нэма дурных. Скорее всего, flow3 будет выпущена в качестве v4 расширения и новые расширения будут писаться уже под неё. Это, мне кажется, позволит сделать плавный переход между ветками...
Pavel Antonov
29.03.2008, 14:49
На тему фреймворков.
http://forum.typo3.biz/showthread.php?p=18110#post18110
Ну и по поводу планов насчёт FLOW3 / TYPO3 5:
News from the General Assembly of the T3A:
http://news.typo3.org/news/article/news-from-the-general-assembly-of-the-t3a/
Фреймворк обещают в конце 2008, пятёрку - в 2009. Плюс доп. финансы и народ вливают, спешат.
Может кому пригодится
Create an ARP-Class for any Extension Table.
http://typo3.org/extensions/repository/view/createarp/0.2.2/
ЗЫ:
ветку (полветки) пора в разработку расширений?
Если я правильно понял, эта штука не умеет связывать таблицы? Если так, то, как говорится, фтопку.
//У меня в своё время была безумная идея сделать генератор Doctrine-классов на основе $TCA
Если я правильно понял, эта штука не умеет связывать таблицы? Если так, то, как говорится, фтопку.
//У меня в своё время была безумная идея сделать генератор 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 :(
Pavel Antonov
26.04.2010, 19:58
разработчики 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 годная для продакшена.
Valery Romanchev
31.05.2010, 00:18
Насчет extbase и fluid - текущая версия уже вполне юзабельная.
С производительностью проблем нет: на реальном сайте скорость генерации списка, который дергает 5 таблиц и рендерит картинки - в пределах 1-1,2 сек (согласно тому, что пишет админ панель). Т.е. ничем не хуже обычного традиционного экстеншена.
Extbase Кикстартер работает, хотя еще не доделан до уровня старого кикстартера.
Насчет extbase и fluid - текущая версия уже вполне юзабельная.
С производительностью проблем нет: на реальном сайте скорость генерации списка, который дергает 5 таблиц и рендерит картинки - в пределах 1-1,2 сек (согласно тому, что пишет админ панель). Т.е. ничем не хуже обычного традиционного экстеншена.
Extbase Кикстартер работает, хотя еще не доделан до уровня старого кикстартера.
А под нагрузкой как себя ведет? Если потестить через ab, то сколько запросов в сек обслуживает?
Valery Romanchev
11.09.2010, 13:49
А под нагрузкой как себя ведет? Если потестить через ab, то сколько запросов в сек обслуживает?
стоит на shared сервере, так что ab мало что скажет
Что касается реальных проектов среднего масштаба на extbase:
про каталог с 10 тыс. товаров
http://t3con10-frankfurt.typo3.org/sessions/speaker/paper-detail-view/?tx_ptconfmgm_controller_detail_paper[uid]=161&tx_ptconfmgm_controller_detail_paper[pid]=200
Могу подтвердить, что extbase по производительности вышел на вполне приемлемый уровень.
Например сейчас доделываю плагин читального зала у нас на сайте, работает вполне адекватно:
http://194.85.139.73/index.php?id=48 (PS: естественно work in progress)
Добиваем сейчас этот сайт, там еще будет пару разделов на extbase.
Интересно, много ли кто сейчас у нас использует extbase на практике?
С уважением,
Дмитрий.
может кто подскажет
установил typo3 (4.3.5, 4.4.2)
на локальный сервак Server2go
Apache/1.3.35 (Win32) PHP/5.3.2
Версия MySQL-клиента: 5.1.41
PHP расширение: mysql
у меня несколько вопросов. Было заявлено, что typo3 стала быстрее на 90%
но 4.3.5 работает шустрее, чем 4.4.2, с чем это может быть связано ?
возможно компутер слабенький .. и подтормаживает javascript?
и правильно я понимаю, что "старый метод" разработки экстеншнов будет работать в новых версиях наряду с "продвинутым"?
и правильно я понимаю, что "старый метод" разработки экстеншнов будет работать в новых версиях наряду с "продвинутым"?
Он будет работать в v4.x, но не в v5. v5 - это новая эра, и там все по другому.
Дмитрий.
Valery Romanchev
28.09.2010, 18:16
у меня несколько вопросов. Было заявлено, что typo3 стала быстрее на 90%
где это писали? мне такой цифры не попадалось
но 4.3.5 работает шустрее, чем 4.4.2, с чем это может быть связано ?
возможно компутер слабенький .. и подтормаживает javascript?
да, может быть из-за этого
были посты, что админка на очень страрых компах стала работать медленнее
спасибо за ответы
я, видимо, выдал желаемое за действительное
... This results in a reduction of server requests by as much as 90 percent!
http://typo3.org/download/release-notes/typo3-44/
Valery Romanchev
06.10.2010, 13:56
Что касается реальных проектов среднего масштаба на extbase:
еще один пример http://t3con10-frankfurt.typo3.org/fileadmin/fe_user/clemens.kalb_netlogix.de/BiZbZ5.pdf
http://www.slideshare.net/netlogix/building-a-large-ecommerce-application-with-extbase-fluid-and-apache-solr
Посмотрим что выйдет,
лично я скептически отношусь к созданию новой ветки TYPO3 несовместимой со старой. ИМХО лучше бы эти силы тратились на доработку существующей ветки и последовательное ее улучшение с хорошей обратной совместимостью.
Собственно, это вполне себе выход - использовать нормальные фреймворки на нормальных языках программирования. Как-то до сих пор все экстеншены к v4 не очень MVC. Да и прочих преимуществ фреймворков нет - отсутствие внятного ORM (TCA и t3lib_db не стоит рассматривать в качестве ORM), отсутствие хороших библиотек для построения форм и т.п. - всё это приводит к огромному количеству откровенного мусора в TER и сводит на нет преимущества "второго типа систем".
Вот ИМХО и надо внедрять это в v4 – ORM, формы, MVC, AOP итп. Не обязательно же сразу выкидывать t3lib_DB. Можно сделать альтернативную билиотеку t3lib_db_orm, например, и через несколько версий, когда она будет уже полностью рабочей, можно старую t3lib_db объявить depricated и еще через несколько версий удалить. То же сделать с MVC - сделать альтернативную библиотеку вместо tslib_pibase, tslib_pibase_MVC итп..
Понятно что разбираться с чужим ядром мало кому нравится, а разработать что-то новое интереснее, вот все и кинулись на v5 :). Но ИМХО больше пользы будет не от револиции, а от эволюции v4 ветки, с последовательной заменой частей ядра, чтобы была приемлимая совместимость и можно было бы сайтам мигрировать постепенно.
согласен
Работает на vBulletin® версия 3.8.1. Copyright ©2000-2025, Jelsoft Enterprises Ltd. Перевод: zCarot