Нет, zed_more_columns использует древний подход split language labels, а еще он добавляет только одну колонку.

Написал расширение. Называется More Columns (am_more_columns). Создает сколько угодно колонок в Web Page Module. Плюс создает возможность задания названий для как новых, так и существующих по умолчанию колонок на разных языках BE из TSconfig. Особенно мне нравится сочетание am_more_columns с me_pagelayout.

Молодца!

Я использовал TV из-за возможностей FCE. Но насколько удобно создавать элементы с помощью Special Elements? Что то там замороченное, помоему...

По идее стандартная выбока контента должна работать быстрее, чем TV-mapping с XML.

По идее да. Посмотри подкаст про Special Elements. Там настройка конечно сложнее чем сетап FCE, но зато редактирование и создание SE вообще прозрачное.

Я смотрел, и сразу могу сказать что мне не нравится по сравнению с FCE:

1. Использование таблицы tt_content c подменой уже определенных стандартных типов полей. Это не совсем прозрачно, может коряво работать при смене типа элемента на стандартные.
2. Если не подмена, то добавление своих полей - распухание таблицы tt_content. Например, допустим пример из подкаста создается с добавлением всех полей в базу. Это значит что все элементы контента будут тащить за собой кучу пустых полей.... а если таких специальных элементов много? как то... не впечатляет.
3. Формирования вложенных блоков в FCE все же и выглядит прозрачнее и редактировать удобнее... Например как сделать многоколоночный контейнер? Через IRRE? но отображаться то для редактора это нормально не будет! в TV я вижу все... вот колонки, вот контент в колонках...

Большой плюс конечно - возможность работать с данными с помощью SQL-выборок... но для контента это не так часто нужно, а для специализированных данных можно и свой модуль написать.

КСТАТИ! Кто сказал что нельзя и FCE разобрать с помощью SQL?!. MySQL поддерживает XPath! Если очень хочется, то можно и по данным TemplaVoila успешно ползать: http://dev.mysql.com/tech-resources/...l-5.1-xml.html

TV более гибкая. С её помощью можно даже такое делать:
http://ru-tech.com/index.php?id=46 (Вкладочки)

Согласен со всем кроме:
1. распухания tt_content. Там используется поле pi_flexform. Никаких новых полей в БД они не добавляют.
2. подмены полей. Естественно данные будут подставляться. То же будет происходить например при использовании стандартных майлформы, таблицы и обычного Текст.

Насчет многоколоночного контейнера ты прав. Помнится было такое расширение KB Content Table которое позволяло делать сколько-угодно-колоночные и строчные контейнеры. Поскольку написан он для PHP4, в BE выдает ошибки XML parser, но все вроде работает.

Чот примера использования в WHERE нет. Судя по всему прикольная фича.

Это в случае FCE оно используется, а в случае th_specialelements, ты ограничен функционалом TypoScript, и выбор только два: использовать уже существующие поля или нарезать новые.

Согласен... это-то сразу и ограничивает все дело...
Если мне надо 3,4,5 RTE полей? куда их пихать то? Ну для второго они в примерах используют "altText" ...а дальше все.... конец.

не продакшен плагин - смотрел, серьезно для применения не рассматривал.

Честно не пробовал. Но думаю нет проблем и в WHERE использовать "extractValue", иначе глупо как-то... Вопрос конечно в скорости работы.

Блин, в натуре новые поля создавать предлагают. Вот ацтой.

Но мне понравилась идея с расширениями к расширению. На досуге я подумаю на эту тему. Использовать TV только ради FCE вааще не рационально.

Мда.. Не понятен мне мотив автора. Почему не сделать данные в pi_flexform, а вывод через какой-нибудь универсализированный шлюз "шаблон + php + TS + данные".

Найдите мне спонсора :)

А зачем? ... что бы получить в итоге TemplaVoila??? Как еще ты собираешься в одном поле все хранить?

Отлично собираюсь хранить, тока это будет не monsterous TemplaVoila, а отдельный такой суперконфигурируемый FCE c удобным интерфейсом. По идее в процессе проблем не должно возникнуть.