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

Представьте, потом кому-то будете деллигировать свой проект на саппорт. Такие моменты вот будут очень трудно уловимы.
Вообще, старайтесь поменьше так делать. Лучше изучите апи, напишите свой хендлер. Это есть друпал вей.
...Вообще убивает, когда потом еще пхп или хтмл обработку суют в такие поля, или что еще хуже - джава скрипт. Ну не кошерно это, не кошерно.
Удобство только в том, что мышкой клац клац. А потом когда надо поправить и не помнишь.. ууу ) Скоро было интересных моментов в такие поиски, матерных слов и выпитого кофе..
В адекватной компании за такое пальцы засовывают в дверной проем )))

Да да, я плохо знаю друпал. Письками меряться смысла не вижу.

Эх.. Велосипеды велосипеды.
Молодой человек, вы просто не работали с европейскими компаниями.
Стандарты? Нет, не слышали.

Я скажу вам по секрету, что большинство контриб решений придумано для "кликанья мышкой". Но действительно нагруженные проекты почему-то отказываются от них, и даже для калькуляции тайтлов в результате вьюсов делают свои хендлеры для полей. Значете почему? Потому что читаемость кода и стандарты позволяют дальше жить проекту и развиваться в команде и не зависимо от разработчика.
На таком велосипеде вы уедете не дальше первго угла, когда нужно будет находить гибкие решения для вывода и последующей оптимизации.
Хотя, если вам по душе пихать это во все, что доступно, то что ж.. Переубеждать не буду.

Просто попробуйте это доказать на д.орге )

Просто ознакомьтесь с стандартами.
Может для "сайта на коленках" решение и ок. Но на моей практике за такое вставляют пальцы в дверной проем.
Это как использовать контексты для акцессов к дисплеям в ctools.

Мощно, норм сервак.

Но суть не в этом. Просто при наличии мощностей не стоит доводить свой код и методологию программирования до уровня.. эм.. ну такое.

Скажу так, клал серваки и по серьезнее. Достаточно попробовать через батч обновить таблицу на 15-17 лямов записей, в которой первичный индекс строится по 5-6 полям. Минимум. Бывало, уходили в даун.

А вообще соглашусь с одним - решений есть масса. Просто я больше сторонник стандартов, так сложилось и работа требует.

Я согласен с вами.

На счет проектов. Ничего не буду доказывать. Их было ооочень много за 8 лет. И ооочень разные )

Я работал в теме по авиаперевозчикам. Практически вся выдаваемая информация не актуальна на момент выборки, хотя бы потому, что это статика.
То что выбор через аякс - это гуд. То, что по факту подбор туров не происходит по актуальности, а по факту идет по статике - это бед.

Могу написать почему.
п.с. сейчас работаю с проектом по отельному бизнесу.

Я согласен лишь отчасти.
Но в проектах, где нет разницы, 10 уе/час рейт, или 30 уе - на такие моменты не обращают внимания, но борются за чистоту кода.
Для меня тоже в свое время было странным, что действие, которое займет 5 минут занимало иногда час времени.

Просто почему так.
Вы вносите изменения через ui в корректировку вывода. Это гуд, это то, что нужно заказчику.
Но проект живет еще на гите и еще в нескольких бранчах. И очередной пулл данных с гита без использования миграции или фичей не перенесет то, что вы настроили у себя в базе. И использовать фичи для сеттингов фидбека - никто не пойдет на такое.
Потому и пишут подобные изменения максимально в коде.
Токены вообще отдельная история, потому как они в бОльшей степени для одиночных проектов и призваны просто облегчить жизнь и работу человеку, который не хочет знать или не знает апи. Даже построение алиасов - лучше через код. Особенно, если вы используете свою систему доступов, попимо пермишнов и стандартного user_access. И есть еще масса примеров, когда такой подход не желателен. Да, дял проекта одного человека - да хоть снипетты в аяксом в блоки. Но на проектах, где более одного человека - это приносит большие не удобства.

П.с. документацию пишу на кастом.
Комменты практически всегда.

>А по быстродействию выйдет приблизительно одно и то же, т.к. поля из базы тянутся одни и те же.
Зависит от объемов и вида обработки данных, а так же их источника. Не всегда данные беруться из базы друпала, есть еще внешние апи, с которыми приходится работать и данные по которым не всегда удается хранить в бд статически, так как они унифицированы по внешним входящим параметрам (например, актуальность наличия номерного фонда в отеле или сети отелей, где доступ на прямую коннет к внешней бд вам никто не даст впринципе, а делать надо).

>А потом ему нужно будет лезть в код и искать ваши велосипеды и вникать в принципы их работы
Стандарты, соблдайте стандарты. Друпал этим и хорош своими предопределенными хуками (и не только). Знющий человек разберется в коде быстро. Не знающих даже базы будет долго искать. Проходили уже, еще когда шестерка была в деве.

ИМХО, все зависит от самого проекта. Я тоже бы не заморачивался особо на прокте "одного человека". Сейчас же сталкиваюсь все чаще, что лучше потратить больше времени на качество и "по правилам", чем приносить гемморой в работу всей команды. Но это уже методологии программирования и реализации бизнес моделей в разрезе чистоты кода, чем наша тема.

>Тем не менее, я понимаю, о чём вы говорите - неоднократно разгребал наследие педерастов, создающих типы материалов, состоящие исключительно из пхп полей, или делающих в node.tpl.php свич на 10 кейсов для обработки каждого типа материала и всё это приправлено прямыми запросами в БД.
Вот я о том же.
Но все начиается "о, токены" )))) Хотя штука очень удобная, согласен. В работе с ct ctools и контексте - вообще не заменима. Но там это как раз нормально. С вьюсами же стоит быть аккуратнее. Любое подобное действие - это сразу +2-3 запроса, при том не через джоны, а отдельные. На 100 записях не скажется, а на более глубоких выборках уже будет ощутимо..

Да, экспортировать можно. Но тут лучше фьючерс использовать. Они с более удобной системой миграции в целом. При желании можно все что угодно портировать.

Но дело в том, что клиент не хочет заморачиваться с этим. Как и другие участники команды могут просто погрязнуть с вечным мерджем и их конфликтами.
Я все же за работу через гит в разных ветках, и желательно с меньшим коэфициентом использования ui для подобног. Нет, ui это хорошо, и честно говоря, по началу спасало не раз. Но на проектах не крупных.

Еще другая сторона есть. Это клиенты (или кастомер), которые хотят все из коробки и ничего не настраивать. А переносить апдейты на живой проект.. только через апдейты либо через миграцию. За мою практику - не особо любят давать доступ в админку на живых проектах.

На счет быстродействия.
Метод миграции никак не влияет. В одном случае настройки модели вьюса хранятся изначально в базе, в другом (перенос через фичи или через экспорт/импорт) - аналогично, но с фичами - есть еще и сама фича, которую можно ревертнуть (вернуться к изначальному состоянию или виду). По факту в итоге - все настройки в базе. Методов переноса много, вплоть до инициализации объекта вьюсов в коде.
Испльзование токенов хорошо сказывается на производительности на больших объемах данных. Не всегда хватает базы от друпала, часто пишется что-то свое. Отсюда и все шишки. Для простых задач - очень даже норм. Для большого объема - наклдно. В свое время на нескольких проектах отказывался и от вьюсов, и от батча, и от много чего из-за нагрузок.