Есть ли преимущество использования префикса "user_" в Extension Keys?

Question

Я видел довольно много «специфичных для проекта расширений» от разных разработчиков и никогда не видел префикса «user_», хотя документация дает указание использовать его:

Расширения, специфичные для проекта (обычно не используемые или не используемые): Выберите любое имя, которое вам нравится, и добавьте к нему «user_» (которое является единственным разрешено использование ключа, начинающегося с «u»). Этот префикс означает, что это расширение является локальным, которое не идет от центрального TYPO3 Расширение репозитория или когда-либо предназначено для совместного использования. Наверное это это расширение «adhoc», которое вы сделали для какого-то особого случая.

Но разработчики склонны использовать "client_usecase" или просто "usecase", если мое восприятие является репрезентативным. Мне сказали, что «user_» без необходимости расширяет некоторые вещи, такие как имена таблиц баз данных, и пространство имен расширений (vendor-name / extension-name) является более важным, чем ключ расширения, и эта часть документации может более или менее быть пережиток прошлого.

Меня беспокоило, что такой ключ расширения может конфликтовать с другими расширениями, f. е. Extension Manager может попытаться загрузить переводы и предложить загрузить обновления, могут возникнуть проблемы с зависимостями или хостеры TYPO3 могут установить исправления безопасности и т. д. Я лично использую этот префикс в моих расширениях user_site (TS и шаблоны для конкретного проекта) для нескольких проекты и ожидал каких-то условий в основном, ф. е. что Менеджер Расширений пропускает все обновления перевода для этого расширения, но я ничего не смог найти. Возможно, мне следует предложить (подделать) исключить такие расширения для обновлений версий и переводов и выделить их как «специфичные для проекта» в списке Extension-Manager.

Я думал, что есть только два варианта: зарегистрировать ключ расширения или использовать префикс «user _», но это, похоже, устарело или, по крайней мере, обычно игнорируется.

Есть ли еще преимущество использования такого префикса, и стоит ли идти этим путем, или же регистрация ключа расширения может быть заменена чем-то вроде регистрации TER с именем поставщика в будущем?

Answer 1

Документация всегда была рекомендацией - и (почти?) Никто не использовал расширение с ключом, начинающимся с user_.

Это была рекомендация избегать конфликтов, подобных описанным вами. Но конфликтов удалось избежать с помощью префиксов программиста, компании или клиента (что похоже на название поставщика).
В старые времена не только таблицы имели префикс с ключом расширения, но и дополнительные поля для других таблиц. особенно если вы использовали kickstarter / extensionbuilder.

Сегодня мы используем пространства имен, чтобы избежать конфликтов с именами классов, но все же можем получить конфликты с ключами расширения, поскольку имена любого поставщика не учитываются, если расширение установлено за пределами typo3conf/ext/.
Папка, вероятно, может быть переименована, но наличие записей одинакового типа (с разными полями) в таблицах с одинаковыми именами может нарушить работу системы.

Пример: не пытайтесь ввести собственное расширение для новостей с именем news; -)

С другой стороны, вы можете получить поля с одинаковой информацией, но разными именами: latitude/longitude, lat/long, lat/lon.
А как насчет полей, которые называются одинаковыми из разных расширений, которые используют разные представления данных? time как string, unixtimestamp, time, ...

Вывод: вы не можете избежать всех конфликтов, и знание о возможных проблемах может помочь избежать этого с некоторыми умными допущениями.

Автообновление для расширений может происходить только при composer-install, но там важно указать имя поставщика. При установке без composer вы можете получить расширение от TER, в котором ключ расширения идентичен собственному расширению, но следует знать, если собственное (локальное) расширение имеет более новые версии в TER. особенно если расширение имеет префикс от автора, компании или клиента.

Имейте в виду, что расширения доступны не только в TER. С помощью composer и packagist расширения можно хранить где угодно.