Umstellung auf Namespaces - Datensammlung | Info | Diskussion

[christophboecker]

Redaxo-Addons und Namespaces

Das Thema kommt immer mal wieder hoch, gerne im Zusammenhang mit der Umstellung der Installer-Logik auf Composer. Ich versuche mal eine Zusammenfassung und ein paar weitere Gedanken an dieser Stelle zu sammeln. Dann haben wir endlich mal einen Topf, auf den man referenzieren kann.

Bitte gerne erweitern. Das ist nur ein erster Aufschlag.

Stand der Diskussion aus Slack

(Auszüge aus Treads; gesucht am 30.01.2024; Links zu den Threads schenke ich mir, funktionieren in ein paar Wochen eh nicht mehr)

Thread vom Dezember 2022

• Jan Kristinus: ich würde gerne irgendwo definieren, wie ein AddOn von FOR aufgebaut sein sollte. Auch im Zuge von REDAXO Updates (Version6 etc) ist es wichtig z.B. folgendes zu beachten ...
  Namespace: Mein Vorschlag namespace FriendsOfREDAXO/AddOnName z.B. in Falle von 2factor_auth' habe ich TwoFactorAuth` genommen.
  ... Nur falls jemand an den AddOns dran ist - dann kann man das zusätzlich noch anpassen
• Christoph Böcker: FriendsOfRedaxo?
• Jan Kristinus: passt für mich .. und auch Gregor ist damit sicherlich zufriedener .. und bevor ich 2 Leute habe die mich dann jeden Tag bedrängen :zwinkern: ..

Thread vom 25.01.2024

• Jan Kristinus: Im Moment wäre es schon gut, wenn die addons vorbereitet werden. Also keine Plugins und namespaces. Das für die wichtigsten FOR addons zu machen ist schon viel Arbeit. Wegen REdAXO Core machen wir erstmal unsere composer Sachen und reden danach
• MaxDau: Wie keine Plugins?
• MaxDau: Generell gar keine NS oder an welchem Punkt sollten keine NS sein? (bearbeitet)
• Thorben: FOR-Addons sollen einen Namespace bekommen
• Andreas Lenhardt: Nein, es müssen überall Namespaces hin kommen
• MaxDau: Wie soll die Struktur sein?

Thread vom 26.01.2024

• MaxDau: Werden NS zur Pflicht?
• Gregor Harlan: nein nur empfehlung
• Christoph Böcker: Aber mit Blick auf die Zukunft dennoch angeraten? Bei neuen Addons besser einfach mal machen? Oder erst mal warten auf Namespace-Empfehlungen/Regeln des Core-Teams?
• Gregor Harlan: Schon machen. Siehe zum beispiel securit, was Jan ja letztens zu FOR hinzugefügt hat
• Gregor Harlan: Zukünftig wollen wir wie gesagt den composer autoloader nutzen. somit kann jedes addon alles das nutzen, was der bietet
• Gregor Harlan: der bietet PSR4, aber auch classmap
• Gregor Harlan: empfehlung ist aber namespaces und psr-4
• Gregor Harlan: beim namespace sollte der erste immer der erstellername sein. Also FriendsOfRedaxo, oder MeinName oder MeinPseudonym o.ä. Redaxo\ sollte nur in paketen verwendet werden, die im haupt-redaxo-repo liegen
• Gregor Harlan: Yakamara\YForm\ wäre aktuell also der richtige namespace fürs yform addon

Thomas Blum auf GitHub

Quelle

Der Namespace sollte nach dem Schema
FriendsOfRedaxo\[PaketNameWithoutSpacesAndAsCamelCase]
sein. Das hatten wir erst kürzlich als Empfehlung notiert. Wäre hier dann FriendsOfRedaxo\Focuspoint
Das werden wir aber auch noch kommunizieren.

Thread vom 02.02.2024

• Jan Kristinus: Auf Anfrage von “Leuten” :zwinkern: .. Wegen redaxo6 und Vorbereitungen. Grundsätzlich sind wir dran, aber es ist noch nicht klar wie die AddOns, nachher composer packages, aussehen werden. Dennoch kann jeder seine AddOns entsprechend vorbereiten. Es wird keine PlugIns mehr geben, also als erstes die Plugins “irgendwie” in das AddOn integrieren, entweder ist es immer sofort auch installiert oder man macht einen “Schalter” zum aktivieren von einer Funktion (hängt ja vom AddOn ab). und 2. Die namespaces mit PSR4 vorbereiten, damit es später leichter und sinnvoll in die composer packages kommen kann. Wer will, beschäftigt sich mit composer und dem package manager. Grundsätzlich sind das alles, unabhängig von REDAXO, sinnvolle Dinge.
• Tobias Krais: OK. Mein Git Account ist TobiasKrais. Dann sollte ich wohl auf TobiasKrais/d2u_helper umstellen. Spielt hier Groß und Kleinschreibung eine Rolle? Hier müsste ich mich vermutlich am Reponamen orientieren, oder?
• Christoph Böcker: Siehe die erwähnte Discussion. Laut Thomas Blum wäre der Name (CamelCase, kein _) TobiasKrais/D2uHelper oder hier wohl eher TobiasKrais/D2UHelper
• Tobias Krais: Ganz durchgezogen wird das aber nicht: FriendsOfREDAXO/2factor_auth hat den Namespace FriendsOfRedaxo\2factor_auth wogegen FriendsOfREDAXO/yform_export den Namespace YFormExport hat.
• Gregor Harlan: FriendsOfRedaxo\2FactorAuth wäre korrekt. Unterstriche sollten im Namespace nicht vorkommen aus meiner Sicht
• Gregor Harlan: Streitpunkt sind bei Namespaces/Klassen öfters auch Abkürzungen. Also ob HTMLHelper oder HtmlHelper. Wobei ich ganz klar für HtmlHelper bin. Deswegen auch FriendsOfRedaxo, obwohl REDAXO sich eigentlich groß schreibt
• Gregor Harlan: Fraglich ist der Umgang mit globalen Klassen, wenn man selbst im Namespace ist
• Gregor Harlan: also ob use rex_finder;' oder \rex_finder::…`
• Gregor Harlan: aktuell erfordert unser code-style für globale klassen, dass sie dann mit backslash verwendet werden. also kein use.
  aber da bin ich selbst nicht sicher, was ich besser finde
• Christoph Böcker: (1) finde ich die USE-Variante besser, weil es reicht, das USE an den Anfang zu stellen und fertig. Außerdem gibt das eine schnelle Übersicht über die benutzen Elemente aus anderen Namespaces inkl. Root. (2) Bei mit mach der Styler (noch?) aus \rex ein use rex; + rex
• Gregor Harlan: Oh, du hast Recht, ist doch so rum konfiguriert: https://github.com/redaxo/php-cs-fixer-config/blob/main/src/Config.php#L53
• Gregor Harlan: wie gesagt, habe bei den globalen klassen keine klare eigene meinung. aber würde es dann so lassen, wie es ist. also doch auch use
• Daniel Weitenauer: Der erste Buchstabe im Klassennamen sollte groß geschrieben werden.
• Gregor Harlan: buildArray -> Klassennamen auch mit Großbuchstabe
• Gregor Harlan: BuildArray

Das bedeutet ....

• Namespaces sind noch nicht Pflicht, aber dringend(!) angeraten. Namespaces an sich sind in PHP "ein alter Hut"

• Referenz ist PSR4

• Namensschema: «publischer»\«addon»; für FOR-Addons also FriendsOfRedaxo\«addonname» oder für andere
  IgorSeinRepo\«addonname»

• Der Addon-Name und eventuelle Sub-Namespaces im Addon werden in der Form "PaketNameWithoutSpacesAndAsCamelCase" geschrieben, also z.B. FriendsOfRedaxo\YFormAdminer oder FriendsOfRedaxo\Geolocation\Calc und immer mit einem Großbuchstaben beginnend.

• Auch Klassennamen mit Großbuchstaben beginnen und camelCase verwenden (z.B. FriendsOfRedaxo\Geolocation\Mapset::get(..)

• Bei den Namen nicht zu viele Großbuchstaben hintereinander (statt HTMLHelper besser HtmlHelper)

• Wichtig sind die Namespaces für den Autoloader, betreffen also die Dateien mit Klassen im LIB-Verzeichnis und deren Suche durch den Autoloader

  • FriendsOfRedaxo\«addonname» wird automatisch mit redaxo/src/addons/addons/«addonname»/lib assoziiert.
  • eine Datei soll nur eine Klasse enthalten.

• Der Dateiname entspricht dem Klassennamen (Datei: Box,php und darin die class Box { ... }

  • Bsp.: FriendsOfRedaxo\Geolocation\Calc\Box::factory() entspricht redaxo/src/addons/addons/«addonname»/lib/geolocation/Calc/Box.php
  • Der Namespace-Subpfad muss der Verzeichnisstruktur entsprechen (siehe Beispiel). Wie er konkret aussieht ist irgendwie
    Geschmacksache. Erklärt am Geolocation-Beispiel. Aus Sicht des Addon-Entwicklers klingt es gut, alle YForm-bezogenen Klassen
    unter lib/YForm/..abzulegn (Bsp: lib/YForm/Dataset/Mapset.php). Aus Sicht des Addon-Nutzers wäre vieleicht, da Mapset oft benötigt wird, lib/Mapset.php angenehmer. Man muss sich halt entscheiden ...

Das zeigt die Richtung und damit kann man sich als Addon-Entwickler die Umstellung machen.

Was fehlt?

• Es braucht eine klare Aussage, ob Namespaces erforderlich sind oder (dringend) empfohlen. Alte Prophezeiung der noramerikanischen Indigenen südlich der arktischen Gebiete: Wenn es kein Muss ist und die Redaxo-Instanzen dennoch funktionieren, fällt für viele Addons die Umstellung aus! Der Aufwand wird in dem Fall verständlicher Weise als unnötig angesehen und die meisten von uns haben auch so genug zu tun.
• Das Namensschema muss noch etwas verfeinert werden, denn innerhalb des Addons sind möglicherweise weitere Unterteilungen sinnvoll. (Theoretisches) Beispiel: FriendsOfREDAXO\addonname\yform\value\xyz.
• Laut PSR4 muss (soll) die Verzeichnisstruktur zum Namespace passen. Daher wäre auch hier eine verfeinerte Anleitung sinnvoll. (Theoretisches) Beispiel: FriendsOfREDAXO\addonname\yform\value\xyz und die Datei dazu addonname/lib/yform/value/xyz.php.
• Es braucht eine klare Zeitschiene. Sonst wird das nichts oder auf den letzten Drücker hingehuddelt.
• Technische Unterstützung wäre evtl. hilfreich. Wie wäre es mit eine GitHub-Action, die zumindest bei FOR-Addons ähnlich der Code-QS im Redaxo-Repo Überprüfungen am Code vornimmt. "Kein Namespace" gibt Mecker
• Es braucht einen technischen Migrationspfad. Beispiel: Addon auf Namespace umrüsten, aber zugleich die alten Klassennamen ohne Namespace für einen Zeitraum X weiter mitführen. Damit das nicht ewig so bleibt: siehe klare Zeitschiene!
• Einige Addons (z.B. yform_adminer) haben einen Namespace-Namen (FriendsOfRedaxo\YFormAdminer), der zwar im Prinzip richtig ist, vom Repo-Namen leicht abweicht. Auch da müsste vor dem Hintergrund composer und PSR4 noch mal geklärt werden, wie Namen zu wählen sind. Vieleicht wird man auch Repos umbenennen müssen?

Die meisten Punkte haben sich aus meiner Sicht (@christophboecker ) weitgehend geklärt.

Wo stehen wir heute?

Eine kurze Suche am 30.01.2024 im FOR-Repo zeigt ein kunterbuntes Gemisch, wobei die meisten Addons ohne Namespace laufen.

Übersicht zu FOR-Addons (02.02.2024)

Addon	Namespace
FriendsOfREDAXO/tinymce	FriendsOfRedaxo\TinyMce
FriendsOfREDAXO/focuspoint	FriendsOfRedaxo\Focuspoint
FriendsOfREDAXO/diff_detect	FriendsOfRedaxo\DiffDetect
FriendsOfREDAXO/rex_gitapi	FriendsOfRedaxo\RexGitApi
FriendsOfREDAXO/yform_adminer	FriendsOfRedaxo\YFormAdminer
FriendsOfREDAXO/geolocation	FriendsOfRedaxo\Geolocation
FriendsOfREDAXO\Security	FriendsOfRedaxo\Security
FriendsOfREDAXO/2factor_auth	FriendsOfRedaxo\2factor_auth
FriendsOfREDAXO/thumbhash	FriendsOfRedaxo\thumbhash
FriendsOfREDAXO/navigation_array	FriendsOfRedaxo
FriendsOfREDAXO/properties	FriendsOfRedaxo\ForProperties
FriendsOfREDAXO/mediapool_exif	FriendsOfRedaxo\addon\MediapoolExif
FriendsOfREDAXO/yform_usability	yform\usability
FriendsOfREDAXO/poll	poll
FriendsOfREDAXO/mform	MForm
FriendsOfREDAXO/mblock	MBlock
FriendsOfREDAXO/rexstan	rexstan
FriendsOfREDAXO/rexfactor	rexfactor
FriendsOfREDAXO/collaborate	collaborate
FriendsOfREDAXO/be_password	BePassword
FriendsOfREDAXO/forcal	forcal
FriendsOfREDAXO/uppy	Uppy
FriendsOfREDAXO/yform_export	YFormExport
FriendsOfREDAXO/mfragment	MFragment
FriendsOfREDAXO/activity_log	RexActivity
FriendsOfREDAXO/textile_migration	TextileMigration
FriendsOfREDAXO/yform_geo_osm	yform\geoosm
FriendsOfREDAXO/graphql	graphql

In den Non-FOR-Addons habe ich nur mal stichprobenartig reingesehen. Auch da ein sehr gemischtes Bild: ohne Namespace überwiegt, ein paar laufen im Namespace, der Name ist aber öfters mal nicht konform wie bei vielen FOR-Adons auch.

Tips zur Umstellung eines Adons

Ich gehe davon aus, dass alle hier hinreichend kundig sind. Das wird keine Schulung. Nur in aller Kürze ein paar kleine Hinweise auch als Mutmacher für diejenigen, die sich noch nicht ´rangetraut haben. Wenn ich das kann, dann kann es jeder ....

Referenzen

• PHP-Dokumentation zu Namespaces
• PSR4-Doku
• Eigenen Code auf umgestellte Addons anpassen: Oh! Das Addon hat "Namespace"! Und nun?

Wie schreibt man das?

Als Beispiel können die oben genannten Addons helfen. Hier mal ein Beispiel-Code (vor Namespace) aus der boot.php des Addons yform_adminer:

rex_perm::register('yform_adminer[]');

if( rex::isBackend()) {
    $user = rex::getUser();
    if (null !== $user && $user->hasPerm('yform_adminer[]') && rex_addon::get('yform')->isAvailable() && rex_addon::get('adminer')->isAvailable()) {
        YFormAdminer::init();
    }
}

Jede geeignete Datei wird mit einem namespace-Statement am Anfang in den Namensraum aufgenommen.

namespace FriendsOfRedaxo\YFormAdminer;

Danach zeigt die Entwicklungsumgebung Fehler an, da die Klassen rex_perm, rex, rex_addon und YFormAdminer
im Namensraum FriendsOfRedaxo\YFormAdminer gesucht und nicht gefunden werden. Für YFormAdminer muss noch die zugehörige Datei in den Namespace aufgenommen werden. Die anderen drei benötigen den Hinweis auf ihren tatsächlichen Namespace. Dazu gibt es zwei Möglichkeiten:

• Qualifizierter Name, hier z.B. \rex_perm
• Use-Statement, z.B. use rex_perm;, nach dem Namespace-Statement;

namespace FriendsOfRedaxo\YFormAdminer;

use rex;
use rex_addon;
use rex_perm;

rex_perm::register('yform_adminer[]');

if( rex::isBackend()) {
    $user = rex::getUser();
    if (null !== $user && $user->hasPerm('yform_adminer[]') && rex_addon::get('yform')->isAvailable() && rex_addon::get('adminer')->isAvailable()) {
        YFormAdminer::init();
    }
}

Der Umstellungsaufwand hält sich also in Genzen, da lediglich die nicht im eigenen Namespace vorkommenden Klassen mit use aufgelistet werden müssen.

Unterstützung durch die IDE

Zumindest für meine VSCode-Installation kann ich festhalten:

• Nicht im Namespace gefundene Referenzen werden direkt als Fehler markiert.
• Beim ersten Nutzen einer Fremdklasse kann man den Namespace voranstellen (qualifizierter Name, Bsp: \rex). Ein anschließender Lauf mit dem CS-Fixer wird die neue Referenz meist erkennen und (1) oben im Code ein use rex; einfügen und (2) an der Fundstelle auf den Klassennamen reduzieren (rex).

Welche Dateien kann man anpassen?

Die meisten PHP-Dateien können mit Namespace versehen werden. Das betrifft neben den Dateien im Lib-Verzeichnis und anderen Verzeichnissen wie functions oder extensions (hier und da gibt es sie noch) auch Dateien und Verzeichnisse mit speziellen Aufgaben:

• boot.php
• install.php
• update.php
• uninstall.php
• Fragmente im Verzeichnis «addon»/fragments
• YForm-Fragmente z.B. im Verzeichnis «addon»/yfragments

In Modulen und Templates können möglicherweise Namespaces eingesetzt werden. Aber macht das irgendeinen Sinn? Ich habe es nie ausprobiert. Aber sinnvoll und funktionierend ist das USE-Statement (siehe Geolocation-Doku für Entwickler).

Callbacks z.B. in YForm-Formularen

Die per Callback aufgerufenen Methoden und Funktionen dürfen ruhig in einem Namespace liegen. Aber sie müssen dann auch mit dem vollen Namen hinterlegt werden.

Als allgemeiner Hinweis und Vorschlag: man könnte die Gelegenheit nutzen und veraltete Schreibweisen für Callbacks etc. anpassen, wo es eben geht. Das senkt die Fehleranfälligkeit und verbessert die statische Code-Analyse (IDE, RexStan).

Beispiele

• aus 'klasse' wird klasse::class
  • alt: is_a($media,'FocuspointMedia')
  • neu: is_a($media,FocuspointMedia::class)
• aus 'klasse::methode', array('klasse','methode') oder ['klasse','methode'] wird klasse::methode(...)
  • alt: rex_extension::register('EP_NAME', 'klasse::methode');
  • alt: rex_extension::register('EP_NAME', array ('klasse', 'methode'));
  • alt: rex_extension::register('EP_NAME', ['klasse', 'methode']);
  • neu: rex_extension::register('EP_NAME', klasse::methode(...));

Wo liegen aktuell die Grenzen?

Namespaces sind derzeit nicht möglich mit Klassen, die über ihr Namensschema aufgefunden werden. Das sind aktuell z.B.

• rex_api_xxx
• rex_effect_xxx
• rex_yform_value_xxx
• rex_yform_action_xxx
• rex_yform_validate_xxx
• rex_var_xxx

Möglicherweise gibt s noch mehr von der Sorte in diesem oder jenem Addon. Diese Klassendateien müssen Stand heute ohne Namespace auskommen.

Anders ist es bei eigenen Cronjob-Klassen oder YForm-Dataset-Klassen (Model-Klassen). Sie müssen ausrücklich registriert werden müssen, dabei wird der Namespace berücksichtigt.

Für API-Klassen gibt es ab REDAXO 5.17 die Möglichkeit, Klassen (auch mit Namespace) zu registrieren. Beispiel:

class  Namespace\MyApiClass extends \rex_api_function { ... }

In der boot.php registrieren mit:

\rex_api_package::register ('xxx', Namespace\MyApiClass::class);

Breaking Change und gleitender Übergang

Ja, die Umstellung auf Namespace ist ersteinmal ein Braking Change. Damit würde das Addon, selbst wenn es keine neuen Features oder Bugfixes gibt, eine neue Hauptversionsnummer erhalten.

Es gibt aber eine Übergangslösung. Die eigentliche PHP-Datei wird auf Namespace umgestellt. Zusätzlich gibt es eine zweite, neue PHP-Datei, die nichts anderes macht als auf die Hauptdatei im Namespace umzuleiten.

Beispiel vorher:

Es gibt eine Datei lib/xyz.php mit einer Klasse xyz

class xyz {
    public static function ....
}

Beispiel nachher:

Die Datei lib/xyz.php ist auf Namespace umgestellt und die Klasse heißt nun vollständig FriendsOfRedaxo\MyAddon\Xyz.

namespace FriendsOfRedaxo\MyAddon;
class Xyz 
{
    public static function ....
}

Eine weitere Datei lib/no_namespace/xyz.php enthält die Referenz mit einem Deprecated-Hinweis (gerne "deutlich" formulieren )

/**
 * @deprecated 4.0.0 Aufrufe auf "FriendsOfRedaxo\MyAddon\Xyz" (Namespace) umstellen
 * @see https://github.com/orgs/FriendsOfREDAXO/discussions/40
 */
class xyz_alt extends FriendsOfRedaxo\MyAddon\Xyz
{
}

[RegExMax]

Ich finde das Thema auch sehr Interessant. Für Slack hatte ich ein kleine Einführung zum Thema Namespaces in Redaxo geschrieben, in der (für Einsteiger) erklärt wird, wie was funktioniert und warum. Hab dann gemerkt, dass es zu viel Text ist und jetzt liegt es herum. Falls also Interesse besteht, kann ich das gerne teilen.

Wenn man NS einführt, sollte man gleich einen verpflichtenden Standard einführen um zukünftig nicht wieder vor einer Situation zu stehen, wo einem das "jeder kann es machen wie er möchte" auf die Füsse fallen kann.
Den Ansatz von vendor\addon_name finde ich sehr gut.
Wobei ich addon_name und package_name aus der package.yml in Bezug zueinander halten würde.

Würde aber an dem Punkt die Frage in den Raum stellen, ob es Addons für Addons gibt und ob das 1 von 200 ist oder ob das auch häufiger vorkommen kann.
Sollte es der Fall sein, dass es Addons für Addons gibt oder Addons, welches zusätzliche "Pakete" hat, würde ich folgende Struktur für einen guten Ansatz halten:
vendor\addon\package

Den Package Namen würde ich dann auf addon_package ändern.
Wobei jedes "Main" Addon als core Package angegeben werden könnte.

Beispiel:
FriendsOfRedaxo\YForm\Core für YForm
UserX\YForm\table für Tabellen-Addon/Paket, welches YForm erweitert.

Ich habe aktuell den Fall eines Addons, welches in dem Core-Package nur die Logik enthält. Um das Addon nutzen zu können, muss man (aktuell) eines von 3 Plugins installieren. Plugins sollen aber zukünftig entfallen, weshalb ich das als eigenständige Addons Programmierer, welche das Core Addon als Voraussetzung haben.
In diesem Fall wäre dann auch die beste Struktur

vendor\Addon\core
vendor\Addon\package_X
vendor\Addon\package_Y
vendor\Addon\package_Z

Zudem hätte die Struktur auch den Vorteil, dass man schon am Namespace erkennt, worum es sich handelt.

vendor\YFormComponents sagt mir jetzt nicht, ob es eine Erweiterung zu dem Addon YForm ist oder ob es sich dabei um Komponenten handelt, die einfach nur in der Installation YForm voraussetzt / darauf aufbaut.
vendor\YForm\Components hingegen sagt mir sofort:

• Wer ist der Autor
• Das Addon ist kein Main-Addon
• Benötigt YForm
• Erweitert YForm

vendor\YFormComponents hingegen sagt mir:

• Wer ist der Autor
• nichts

Der package_name in der .yml wäre dann z.B:
vendor\YForm\Core => yform_core
vendor\YForm\Components => yform_components

In der Liste des Installer könnten Main-Addons und Erweiterungen basierend auf dem Namespace angezeigt werden.

• Addon
  -- Extension A
  -- Extension B

[cukabeka]

Hi @RegExMax mich interessiert die "Einführung zum Thema Namespaces für Einsteiger, wie was funktioniert und warum" - magst Du die hier noch irgendwo teilen?

[christophboecker]

Ich hab oben im Text noch den Link auf den FOR-Trick ergänzt:

• Eigenen Code auf umgestellte Addons anpassen: Oh! Das Addon hat "Namespace"! Und nun?

[christophboecker]

Wenn man NS einführt, sollte man gleich einen verpflichtenden Standard einführen um zukünftig nicht wieder vor einer Situation zu stehen, wo einem das "jeder kann es machen wie er möchte" auf die Füsse fallen kann.
Den Ansatz von vendor\addon_name finde ich sehr gut.

Als Antwort: Der Standard hat sich aus den bisherigen Diskussionen m.E. und wie oben dokumemntiert herausgestellt und wid ja auch schon so benutzt bei der Umstellung.

Wobei ich addon_name und package_name aus der package.yml in Bezug zueinander halten würde.

Der Bezug ist gegeben. Einseseits der Name des GitHub-Repo (z.B. yform_adminer) der auch der Package-Name. Im Namespace schreibt er sich dann YformAdminer. Ob sich die Package-Namen und Repo-Namen mal ändern oder ob das überhaupt nötig ist, scheint absehbar egal zu sein.

[christophboecker]

Würde aber an dem Punkt die Frage in den Raum stellen, ob es Addons für Addons gibt und ob das 1 von 200 ist oder ob das auch häufiger vorkommen kann.
Sollte es der Fall sein, dass es Addons für Addons gibt oder Addons, welches zusätzliche "Pakete" hat, würde ich folgende Struktur für einen guten Ansatz halten:
vendor\addon\package

Was meinst Du damit? Ein Addon wie yform_adminer oder yform_fields, die Zusatz-Features für YForm bieten. Ja, ei zusätzliches YForm-Value oder Validate in denYForm-NS zu hängen klingt erstmal charmant, kollidiert aber mit der von Gregor kommunizierten Mapping-Strategie für Klassen-Dateien: vendor\addon\... entspicht dem Verzeichnis ...addon/lib/...

[christophboecker]

vendor\YFormComponents sagt mir jetzt nicht, ob es eine Erweiterung zu dem Addon YForm ist oder ob es sich dabei um Komponenten handelt, die einfach nur in der Installation YForm voraussetzt / darauf aufbaut.
vendor\YForm\Components hingegen sagt mir sofort:

Hm, der eine so der andere anders. Imho ist vendor\YFormComponents eine klare Aussage. Wenn ich in Geolocation YForm-Ergänzungen bzw. auf YForm-bezogene Komponenten habe, stehen die in Geolocation\yform. Da sollte man - just my 2 cents - auch keine zu harten Vorgaben machen. Die Widerstände werden auch so groß genug. Und zu sinnvollen Namensschemata unterhalb des Einstiegs vendor\addon gibt es genug allgemeine Diskussion im Internet über den richtigen Weg, würde ich mal vermuten. Eher etwas weniger Detail am Ende senkt hoffentlich die Hemmschwelle beim Einstieg; am Ende halten sich erfahrungsgemäß eh zu wenige an die eigene Regeln (auch im Kernteam ist man schon mal "pragmatisch" unterwegs). Wobei "good practise" immer hilfreich ist. Zum Glück werden die umgestellten Addons immer mehr, so dass es genug zur Ansicht gibt.

[madiko]

Ich ergänze die Beispiele für bereits umgestellte AddOns, die wir in den letzten Tagen sammelten:

REDAXO AddOn Security (boot)
https://github.com/FriendsOfREDAXO/Security/blob/main/boot.php

REDAXO AddOn MarkItUp! (boot und update)
https://github.com/FriendsOfREDAXO/Security/blob/main/boot.php
https://github.com/FriendsOfREDAXO/markitup/blob/master/update.php

REDAXO AddOn d2u_helper (BackendHelper.php)
https://github.com/TobiasKrais/d2u_helper/blob/master/lib/BackendHelper.php

REDAXO AddOn Quick Navigation (boot, weitere siehe Repository)
--> Besonderheit: Hier werden zum Standard ferner untergeordnete Namespaces definiert (z. B. für Buttons)
https://github.com/FriendsOfREDAXO/quick_navigation/blob/main/boot.php
https://github.com/FriendsOfREDAXO/quick_navigation/blob/f0d1c306674133f3c983fc1ca628caaf4ec753ff/lib/buttons/quick_navigation_button_article_history.php