typo3 и соц сеть
 

Доброго времени суток всем!
Я присматриваюсь к Typo3 как альтернативе битриксу (впрочем не только, но сейчас вопрос с этой стороны). Один из критериев сравнения элементы соц.сети. Скажите есть на Typo3 соц.сети?

Соц. сетей с более-менее серьезным функционалом (сравнимым хотя бы с соц. сетью в форумном движке vBulletin - блоги, фото, группы) в TYPO3 нет.

Т.е. в смысле соц. сетей TYPO3 не является альтернативой Битриксу. Если не нравится Битрикс, смотрите в сторону vBulletin, специализированных коммерческих движков или бесплатных типа http://livestreet.ru/ http://livestreet.ru/ http://buddypress.org/ http://pinaxproject.com/

http://drupal.org/node/131855 - размещена статья про сравнение Typo3 и Drupal
практически по всем параметрам сравнение не в пользу Drupal
надо отдать должное админам сайта, что они выставили такое объективное исследование на обсуждение

Это конечно здорово и спасибо за сссылку, но к теме совсем относится.

TYPO3 - для больших корпоративных сайтов и соц. составляющая очен слабая. Не стоит использовать TYPO3 для построения соц.сетей - не предназначена она для этого! И в данном вопросе Drupal может быть больше подойдет из-за своей коммьюнити ориентированности.

Не совсем согласен. Все нужные базовые фичи в TYPO3 есть – группы, права, BE интерфейс, где можно реализовать очень многое (особенно удобны IRRE элементы для визуализации и работы со сложными связями между разными сущностями модели, что на каждом шагу встречается в соцсети), раздельный рендеринг и кеширование для разных групп, локализация итп... Вообщем в ядре есть все базовые фичи нужные соцсети, особо допиливать там ничего не нужно для этого.

Чего нету, так это готового API для построения соцсети. Но польза от него и не так уж очевидна, поскольку универсальное решение для любой сети тут вряд ли возможно и разумнее делать свой слой бизнес логики под конкретные нужды.

Другими словами, программисту-разработчику ничто не мешает сделать соцсеть на TYPO3. Пользователю, кто больше привык к готовым экстеншенам, и правда особо радоваться нечему, но тут можно упомянуть, что ведется активная работа над экстеншенами типа cwt_community итд. Не знаю насколько они готовы к использованию.

Посмотрел доки cwt_community http://typo3.org/documentation/docum....0.4/view/1/1/
Там есть и профили пользователей и альбомы и личные сообщения и списки друзей.
У расширения 10766 загрузок и дата последнего обновления 16.06.2009. Судя по этим косвенным признакам это что-то вполне рабочее :)

Никто не говорил что нельзя или нет попыток. Я сам делал портал для университета (собственно потому могу говорить что не подходит). Не подходит архитектурно, потому что много проблем:

• Проблемы с кэшированием - от него приходится отказываться так как статических данных на сайте нет.
• Без кэширования начинаются серьезные проблемы с нагрузкой. А код/архитектура TYPO3 на это не очень расчитаны. Что стоит хотя бы меню - каждая страница будет долбить базу шквалом запросов.
• Проблемы с созданием контента внешним пользователем. Да решения есть, но кусочные, недоделанные (так как мало кто занимается комьюнити на TYPO3).
• Все комьюнити разработки - очень слабые. Юзерлист, Бадилист, Галлерея, Профайл - это все и без расширения сделать можно... стандарьными средствами, TS.

Я еще раз говорю - сделать можно... но зачем? Возьмите нормальную комьюнити систему которая замечательно справиться с этой задачей быстро и без заморочек.

И я не говорил что TYPO3 плохая... TYPO3 - отличная система, но не надо ее применять для "управления полетами и организации авиадиспечерских", как написано в лицензии на Java. 8=)

Я сейчас тоже делаю ял-ля соцсеть на TYPO3 :) пока проблем не испытываю.

Проблемы с кэшированием решаются не отключением кэширования страницы, а 1) USER_INT плагинами (которые на лету переключатся в USER, когда это можно), тогда вся страница кэшируется, кроме отдельных частей и проблем с меню итп не возникает 2) USER плагинами + коротким временем жизни кеша - например список пользователей можно делать через USER с экспайром кеша в 1 мин, тогда изменение профиля и состояние "online" будет обновлятся раз в минуту.

Далее можно поднять фронтенд кэш через nginx + memcached, на этом форуме есть топик про evo_nginx_boost - там кэшируются даже страницы с USER_INT плагинами и, как я понял, тот плагин делали как раз для соц сети.

В соцсети создание контента fe-пользователем как правило ограничивается редактированием профиля, комментариями и личными посланиями. Для таких вещей я сделал расширение которое занимается генерированием fe-форм и решает все эти задачи, в том числе редактирование личного фотоальбома. В планах стоит еще добавить ведение блога.

Насчет нормальной комьюнити системы - для более-менее сложной соц сети нет готовых решений, например функционал mamba.ru или вконтакте нельзя реализовать на drupal.

Если проект делается под большую нагрузку, то конечно надо сразу писать все с нуля без фреймворков и CMS. А если планируется одновременная работа всего до 200-300 юзеров на сайте, то на TYPO3 вполне можно сделать все что нужно ;) В плюсе будет готовая админка (BE), готовая система FE кеширования, генерация меню, права доступа к контенту, локализация итп, то есть все те базовые фичи, про которые я писал выше и разработчику можно будет сосредоточится целиком на бизнес логике.

Нда, если ещё учитывать то, как пишется сейчас бизнес-логика (а именно практически голые SQL-запросы, отсутствие ORM и вменяемого шаблонизатора)... Или вы уже перешли на Extbase и Fluid?

Да, был вариант делать под FLOW3 через DDD подход, но это все пока медленно очень работает, для соцети никак не подходит.

Сделал свое промежуточное решение, где SQL запросы собираются автоматически на основе описания модели, у меня это позволило выбирать из базы очень сложные связанные данные и сразу с локализацией (lang overlay) за один запрос. Некоторые такие запросы состоят из соединенных 20 таблиц.

Опупеть. Если 20 таблиц, то я бы сделал это на джанго, и, думается, раз в N быстрее. Потери на интеграции были бы меньше, чем такое

Я кстати правильно понимаю, что вы написали свой ORM?

20 таблиц это не так страшно, многие из них в запросе повторяются (там же локализация, а в TYPO3 локализованные записи и оригинальные находятся в одной таблице, поэтому когда выводится не основной язык, то таблицы в запрос включаются дважды).

Я сделал не ORM, а некоторое свое решение, я затрудняюсь его классифицировать.
В общем есть 1) описание модели, я его делаю своим синтаксисом в typoscript (я добавляю свой TLO DBVIEW) там описано какие таблицы как соединяются, какие условия объедения итп. это описание находится в статичном TS шаблоне, который я подключаю на странице вставки плагина. 2) Далее поверх этого статичного шаблона накладывается TS шаблон страницы плагина, в котором описаны уже какие сущности модели надо вывести на странице, идет список нужных полей (чтобы не таскать из базы лишнее), описывается форматирование полей, тут уже именно шаблон для вывода html, там много работы со stdWrap, склейка списков через ->split итп, вообщем тут обычные TS объекты работают на полную, так как данные в шаблон передаются через загрузку cObj->data и их можно обрабатывать средствами TS как вздумается.
Имея эти шаблоны моя библиотека парсит шаблон модели, составляет один большой SQL запрос, получив ответ она уже парсит шаблон вывода и на выходе получается html.
То есть ORM'ом тут и не пахнет :) зато работает быстро и модель и шаблонизация более-менее разделены.

На ORM'е у меня не получилось сделать быстрый вывод, дело в том, что у меня в анкетах юзеров много вложенных сущностей - анкеты состоят из блоков, каждый блок может быть отключен юзером / запрещен модератором, в каждом блоке набор атрибутов, значения которых выбираются из готового списка, эти списки могут быть выбраны с одним значением, также есть списки где можно выбрать несколько значений (причем список значений отличаются в зависимости от пола юзера), далее в анкете есть и текстовые поля - просто строка и RTE, итд... В целом это почти точное воспроизведение анкет, как они строятся на mamba.ru, все элементы, которые есть у них, у меня тоже присутствуют, только у меня таких анкет несколько типов (в зависимости от профессии юзера) и у некоторых юзеров сразу несколько типов анкет.

Если перед выводом строить всю объектную модель анкеты в деталях, со всеми этими вложенными сущностями, потом загружать в нее данные из БД, а потом только пускать в шаблонизатор, как это должно делаться в DDD, то все это займет кучу времени, мне это не подошло. У меня шаблонизатор работает напрямую с БД, и я один раз описав модель, больше не думаю о ней, а только указываю, что именно сейчас мне надо вывести.
Плюс этого подхода, что рендеринг работает быстро, минус, что модель размазана - в одном месте модель описана для рендеринга, в другом месте модель для бизнес логики - отправка посланий, редактирование анкет итп.

Месье знает толк в извращениях, однозначно =)

Каждый через это проходит. 8=)

И вообще говоря может быть целью является и не результат, а сам путь.

Собственно, Вы уверены в свое правоте, и это главное.
Удачи.

На самом деле важен именно результат, на создание беты проекта на TYPO3 я потратил примерно в 3 раза меньше времени, чем уходит на аналогичный на фреймворке типа Симфони (на питоне не пишу, поэтому за Джангу не скажу), экономия времени разработки за счет готовой админки и готовых базовых фич, о которых я писал выше. ;)
В основном экономия за счет админки конечно же - чтобы сделать с нуля такой интерфейс, как я построил на IRRE элементах, может уйти и полгода. Автоматическая генерация админок во фреймворках способна делать только простые вещи, таблицы со множеством связей редактировать так не получится.
Ну и рендеринг с моей библиотекой работает в 2 раза быстрее, чем с ORM. (с выключенным кешем). И памяти расходуется меньше. В моем случае важна именно скорость, поэтому забил на удобство ORM'a, но никто не мешает под TYPO3 использовать его.

Спасибо :)

Если этот проект разрастется конечно нужно будет уходить от TYPO3 и делать с нуля, даже без фреймворка. Я это заранее предусмотрел и библиотеки, написанные мной, могут работать и без TYPO3, например вместо TS шаблонов у меня могут использоваться и YAML файлы. Но это еще не скоро понадобится, если понадобится, а для быстрого старта проекта TYPO3 – самое то, только надо хорошо знать ее внутренности.