PR: Oxid6 and new commands

[smxsm]

As proposed, a PR to merge the latest changes for OXID 6 with some additional commands into develop.

[marcharding]

Hey, i'm sorry but somehow i missed that the fork is OXID 6 only.

I just skipped over your changes and like most a lot, so i still would like to merge you request but i don't like the prospect of not supporting 4.X at all.

Maybe there is some path in between? For example i really like the install:shop command (even though its a bit hacky). One could easily disable this for versions >= 6 but keep it for backwards compatibility?

[smxsm]

The problem with backwards compatibility is you have to do a lot of case switches to support both flavors of OXID, i.e. for activating modules, switching subshops in EE etc. ... and we couldn't really use the new OXID features like namespaces etc., we'd have to rely on the compatibility layer with class mappings etc. and just don't use the new features, stick with old, deprecated class names etc. ... and once the compat layer is removed we'd have to update the code anyways.
Maybe it would even be easier to have separate branches for OXID 4.x and 6.x?

[tmloberon]

Würde gerne auf Deutsch weiter schreiben ;-).
Mit Namespace sehe ich kein Problem, weil das funktioniert in beide Welten.
Mit der global variable $application->getOxidVersion(); Kann man gut herausfinden in welcher Version man ist.

Gegenvorschlag zur Trennung mit zwei Branch.
Einen switch zu bauen mit Klassen Namen und Interface. Klingt jetzt erstmal schlimmer, als es ist.

...

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        //--- Dieses Auslagern in eine Factory Klasse 
        //
        // OxidExecutable::Version('ActivateModule');
        // und einer Exception wenn es für die Installierte Version keinen Klasse gibt
        
        $actualVersion = $this->getApplication()->getOxidVersion();

        if (version_compare($actualVersion, '6.0.0') >= 0) {
            $activateModule = new ActivateModule_600();
        } elseif (version_compare($actualVersion, '4.9.0') >= 0) {
            $activateModule = new ActivateModule_490();
        } elseif (version_compare($actualVersion, '4.8.0') >= 0) {
            $activateModule = new ActivateModule_480();
        } elseif (version_compare($actualVersion, '4.7.0') >= 0) {
            $activateModule = new ActivateModule_470();
        }
        //---

        $activateModule->execute($input, $output);
    }
...

oder

new v600/ActivateModule();
new v490/ActivateModule();
new v480/ActivateModule();
new v470/ActivateModule();

Wir werden sowieso an einem Punkt kommen wo v6.0.0 und v6.2.0 nicht mehr gleich funktionieren.
Und wenn oxrun sich an die passenden Oxid Versionen anpasst, ist das schon fast KI ;-) und extrem Geil!

[marcharding]

Ich finde es nicht schlecht, auch wenn es mehr arbeit bedeutet. Wobei man ja neue Features auch einfach nur für die neuen Versionen implementieren könnte.

Wie wahrscheinlich ist es denn überhaupt, dass der Legacy-Layer bald entfällt? Es gibt doch sicher auch ne Menge an Modulen von Drittanbietern die dann sofort auseinander fliegen würden?

Allgemein würde ich davon ausgehen das der aktuelle Status-Quo mehrere Jahre so bleiben wird (OXID hat sich doch eigentlich nie sonderlich schnell entwickelt).

Ich würde mich aber auch über weiteres Feedback freuen, gerne auch von anderen Anwendern.

[smxsm]

Der Kompatibilitätslayer hilft nur bei ca. 80%, bei Sachen wie "\OxidEsales\Eshop\Core\Registry::getConfig()" kann man weiterhin "oxRegistry::getConfig()" verwenden z.B. Aber es gibt auch Stellen, die man auf jeden Fall unterscheiden muss im Code, z.B. muss "oxDb::getDb()" in der 6er "\OxidEsales\Eshop\Core\DatabaseProvider::getDb()" sein, und generell muss man das Datenbank-Handling etwas anpassen.
Ich denke auch, dass der voraussichtlich noch mind. 1 Jahr erhalten bleibt ...
Wie können wir weitermachen? Sollen wir die neuen Features aus meinem Branch für OXID 4.x zurück portieren in den aktuellen "develop" bzw. master? Oder machen wir eine Hybrid-Version, die sowohl 4.x als auch 6 unterstützt, wie @tmloberon vorgeschlagen hat?

[tmloberon]

Also ich würde diese OxidExecutable Factory bauen.

[marcharding]

@smxsm oxDb::getDb() klappt bei mir in einem 6er?

Allgemein würde ich gerne den Hydrid-Weg gehen, falls es nicht zu "frickelig" wird.

[tmloberon]

ja das funktioniert noch weil das package oxid-esales/oxideshop-unified-namespace-generator installiert wurde. oxDb wurde als Class Alias deklariert in vendor/oxid-esales/oxideshop-unified-namespace-generator/generated/OxidEsales/Eshop/Core/DatabaseProvider.php.

Zudem muss eine anfangs \ hinzugefügt werden, damit \oxDb gefunden wird. Sobald man in einem Namesapce ist.

Was sich etwas verändert ist das abrufen der Daten. Wenn es code gibt mit einer while schleife. Heißt es nicht mehr $rs->recordCount() sondern $rs->count(). Siehe Abschnitt: Stick to database interfaces

Das betrifft ja nur unseren Code, wir können ja funktionen nutzen wie getAll(), dann funktioniert es in beide Welten.

[smxsm]

Hi @marcharding und @tmloberon , da vermutlich auch in nächster Zeit keiner von uns dazukommt, einen "Hybriden" zu bauen, würde ich pragmatisch vorschlagen, dass wir es doch bei 2 Branches belassen, ich würde aber gerne den aktuellen OXID6 Fork von mir zum "master" machen, weil OXID 6 doch so langsam zum "default" wird, und den jetzigen original "master" als "pre_oxid6" oder "oxid5" o.ä. taufen. Was meint ihr?
Generell würd ich gerne mit Marco Steinhäusers Hilfe das ganze Projekt im "OxidProjects" Github-Repo unterbringen, sprich dorthin "umziehen", damit es zentraler erreichbar ist und besser gefunden wird. Spricht aus eurer Sicht etwas dagegen? Aktuell ist es etwas unklar, welches Repo man wofür benutzen sollte und ein "privater" Fork ist generell nichts, was man gerne im Produktivbetrieb nutzt vermutlich :)
Übrigens, ich habe diese Woche noch eingebaut, dass man eigene Commands in ein spezielles Verzeichnis im Shop ablegen kann, die dann automatisch mit geladen werden, so kann jeder eigenen Commands nutzen, ohne extra forken zu müssen :) https://github.com/smxsm/oxrun/#roll-your-own Evtl. ergänze ich noch wie bei der Oxid Console, dass auch in Modulverzeichnissen nach "Commands" gesucht wird.

[marcharding]

Hey, sorry für die verspätete Antwort. Ich denke inzwischen auch, dass man einfach zwei Versionen weiterführen sollte.