namespaces - 在扩展 key 中使用 "user_"前缀是否有好处？

Question

我见过很多来自不同开发人员的“项目特定扩展”，但从未见过“user_”前缀，即使
documenatation指示使用它:

Project specific extensions (not generally usable or shareable): Select any name you like and prepend it “user_” (which is the only allowed use of a key starting with “u”). This prefix denotes that this extension is a local one which does not come from the central TYPO3 Extension Repository or is ever intended to be shared. Probably this is an “adhoc” extension you have made for some special occasion.

但是开发人员倾向于使用“client_usecase”或只是“usecase”，如果我的看法具有代表性的话。有人告诉我，“user_”不必要地放大了数据库表名等一些东西，并且扩展的命名空间(供应商名称/扩展名)比扩展键更重要，这部分文档可能或多或少是一个过去的残余。

我担心的是，这样的扩展 key 可能与其他扩展冲突，f。 e.扩展管理器可能会尝试下载翻译并建议下载更新，可能会出现依赖问题，或者 TYPO3 主机可能会安装安全补丁等。我个人在我的 user_site 扩展(项目特定的 TS 和模板)中使用了这个前缀项目，并期待核心的一些条件，f。 e.扩展管理器会跳过此扩展的任何翻译更新，但我找不到任何内容。也许我应该建议(伪造)排除版本和翻译更新的此类扩展，并在扩展管理器列表中将其突出显示为“特定于项目”。

我认为只有两种选择:注册扩展 key 或使用“user_”-前缀，但这似乎已经过时，或者至少通常被忽略。

使用这样的前缀是否仍然有好处，这是要走的路，还是将来扩展 key 注册可能会被供应商名称TER注册之类的东西所取代？

Answer 1

该文档始终是一个建议 - 并且(几乎？)没有人使用以 user_ 开头的 key 的扩展名。 .

这是避免像您描述的冲突的建议。但是使用程序员、公司或客户的前缀(就像供应商名称)避免了冲突。
在过去，不仅表以 extensionkey 为前缀，还有其他表的附加字段。特别是如果您使用了 kickstarter/extensionbuilder .

今天我们使用命名空间来避免与类名冲突，但仍然会与扩展键发生冲突，因为如果扩展安装超过 typo3conf/ext/，任何供应商名称都不计算在内。 .
该文件夹可能可以重命名，但是在具有相同名称的表中具有相同类型的记录(具有不同的字段)可能会破坏系统。

示例:不要尝试为名为 news 的新闻引入自己的扩展名;-)

另一方面，您可能会得到具有相同信息但名称不同的字段:latitude/longitude , lat/long , lat/lon .
来自使用不同数据表示的不同扩展名相同的字段呢？ time如 string , unixtimestamp , time , ...

结论:您无法避免所有冲突，了解可能的问题可能有助于通过一些明智的假设来避免它。

扩展的自动更新只能通过 composer-install 进行，但供应商名称很重要。
在没有 Composer 的安装中，您可能会从 TER 获得一个扩展，其中扩展 key 与自己的扩展相同，但应该知道自己的(本地)扩展是否在 TER 中有更新的版本。特别是如果扩展名有来自作者、公司或客户的前缀。

请注意，扩展不仅在 TER 中可用。使用 composer 和 packagist 扩展可以存储在任何地方。