(WIP) Refactoring - application_top.php & Co¶

WICHTIG: DAS DOKUMENT IST NICHT FINAL UND WIRD UM ANREGUNGEN UND FEEDBACK ERWEITERT, SOLLTE ABER IMMER AKTUELL SEIN

Das Gambio Shopsystem wurde auf Basis einer XT-Commerce Lösung aufgebaut. Seit dem basiert das Backend auf Dateien namens application_top*. Zwischenzeitlich wurde eine optimierte Version names application_top_main.php entwickelt, auf der die aktuellen PHP-Implentierungen basieren.

Die Datei ist im prozeduralen Stil entworfen und wird zu Beginn des Scripts eingebunden. Sie ist Zuständig, die wichtigsten Funktionalitäten, die von den gesamten restlichen System genutzt werden, zu laden und bereitzustellen.

Dazu zählen:

• xtc_price und alle weiteren xtc_- Funktionen
• Mainfactory
• Session
• GProtector
• Logging
• Cache
• Konstanten
• Konfiguration-Dateien
• Utility Funktionen (*_wrapper, wie strlen_wrapper.php)
• Error Handling
• Composer
• GM- Funktionen und Klassen
• Compatibility (compatibility.php)
• Smarty
• Template/Theme setup
• StyleEdit setup
• Session-Language setup
• Session-Währung setup
• Session-Land setup
• cPath
• page_token

Verifizierungen (Z. 428 - 467):

• verify the ssl_session_id if the feature is enabled
• verify the browser user agent if the feature is enabled
• verify the IP address if the feature is enabled

Umleitungen (Z. 469 - 496):

• redirect to main domain to avoid duplicate content if request url contains unknown domain (e.i. non-www domain -> www domain)
• redirect to https page if SSL is activated for every page

Extender Komponenten:

• ApplicationTopPrimalExtenderComponent
• ApplicationTopExtenderComponent

$_GET Überprüfungen:

• info
  
• products_id
  
• cat
  
• manu
  
• cPath

Wahrscheinlich habe ich auch noch weitere Dinge übersehen. Gerade alte System (Frontend mit ContentViews, Backend nicht admin.php Seiten) sind sehr stark von den oben genannten Komponenten abhängig. Einige davon sind unerlässlich, um die wichtigsten Funktionalitäten einer Shopsoftware auszuführen (z.B. xtc_price und der Bestellvorgang). Andere sind unerlässlich, damit das Shopsystem je nach Kundenbedarf update-sicher angepasst werden kann (z.B. Mainfactory).

Nichts desto trotz muss darauf hingearbeitet werden, die application_top* Dateien zu ersetzen. Sie ist einfach nicht mehr Zeitgemäß und bringt viele Nachteile mit sich. Die größten Nachteile sind:

• extrem unflexibel, kann nicht ohne weiteres erweitert/verändert werden
• xtc_price kann effektiv nur von einen Mitarbeiter analysiert und gewartet werden (Props gehen raus an Mo!)
• Mainfactory ist langsam und verhindert die Verwendung von Namespaces
• Im globalen Session-Array ($_SESSION) sind Objekte mit Verhalten, sowie alle weiteren Daten ohne Struktur hinterlegt
• Allgemein langsam aufgrund einer Vielzahl von "require_"-Statements, auch wenn zum Teil die eingebundenen Funktionen/Klassen nicht verwendet werden
• Nutzung von Konstanten ist eine Bad-Practise

Vorschlag¶

Damit das Backend des Shopsystems auf einen modernen Core basiert, muss die application_top.php langfristig ersetzt werden. Fairer Weise muss man sagen, dass es eine höchst komplizierte Aufgabe ist.

Außerdem ist es aktuell meiner Meinung nach gar nicht möglich, sie zu ersetzen. Vorher müssen noch andere Komponenten refactored werden.

Vorbereitung¶

Aufgrund der Größe des Vorhabens ist es nicht realistisch, das Refactoring-Projekt innerhalb eines Release-Zyklus zu bauen. Ohnehin müssen zuerst andere Funktionen implementiert werden, damit ein ordentliches Refactoring möglich ist.

Das finale Produkt bringt große Veränderungen am gesamten System mit sich. Ich sehe aktuell keinen Weg, es ohne neuer Major-Versionsreihe zu realisieren. Einige Konzepte müssen auch so früh wie möglich von Kunden/externen Entwicklern genutzt und getestet werden, um die Praxistauglichkeit sicherzustellen.

Zudem muss Sichergestellt werden, dass Lösungen für wichtige Shop-Features, wie Overloads, zur Verfügung stehen.

Nachdem die wichtigsten Basis Komponenten erneuert- und bessere Wege zur Erweiterung des System bereitgestellt worden sind, kann final die application_top Datei ersetzt werden.

xtc_price¶

Problem¶

Die xtcPrice_ORIGIN Klasse enthält eine Vielzahl von Funktionen zur Preisberechnung. Der Bestellvorgang basiert zum Beispiel auf dieser Klasse. Sie ist die komplizierteste, jedoch auch wichtigste Klasse im gesamten Shop und kann aktiv nur von einen Mitarbeiter analysiert und gepflegt werden. Für den gesamten Bereich fehlen Unit und Integration-Tests.

Lösungsansatz¶

Optimalerweise wird sie mit einem Checkout-Service ersetzt. Wenn ein solches System im Shop implementiert ist, dann sind wir auch einen Schritt weiter uns von der application_top zu trennen.

Mainfactory¶

Nahezu alle Klassen werden aktuell über die Mainfactory geladen. Dadurch sind externe Entwickler in der Lage, mittels sogenannten "Overloads" die Funktionen des Shops update-sicher bei nahezu allen Klassen des Shops zu erweitern.

Vorteile¶

• Einfacher weg, Shop Funktionen anzupassen
• Update-sicher
• Anpassung von fast allen Stellen im Shop

Nachteile¶

• Verwendung von Namespaces nicht möglich (PSR-4 Autoloading kann größtenteils nicht verwendet werden)
• sehr geringe Wartbarkeit der Mainfactory Klasse
• verhältnismäßig Langsam
• zwang von mindestens "protected"-Sichtbarkeitslevel in fast allen Shop Klassen

Lösungsansatz¶

Konkret kann ich noch keinen Vorschlag geben. Möglicherweise ist ein mächtiges DI Container System ein praktikabler Lösungsansatz.

Alternative Ansätze, wie zum Beispiel ein Hook-System, sollten auch mit zur Diskussion stehen. Meiner Meinung nach sollten wir uns auch überlegen, in wie weit es Sinn macht, alle möglichen Klassen anpassbar zu lassen oder an der Stelle etwas restriktiver zu werden. Ich weiß, dass verschiedene Mitarbeiter diesbezüglich verschiedene Meinungen vertreten, die zu erst ausdiskutiert werden müssen.

Session¶

Problem¶

Eigentlich existiert noch kein "richtiges" Session System im Shop. Innerhalb der Session werden unstrukturiert Daten oder auch ganze Objekte (alles mit coo_-Prefix) gespeichert. Im Anschluss sind alle Werte über das globale $_SESSION-Array verfügbar. Neue Systeme im Shop extrahieren die Session Werte mittels eines "Settings"-Objekt zur weiteren Verwendung in der Domain, weshalb sie vergleichbar einfach zu refactoren wären. Alle anderen Legacy-Systeme sind komplizierter im Bezug auf die Verwendung der Session.

Lösungsansatz¶

Ein System zum Handling der Session, zum Beispiel eine Komponente namens "SessionService). Langfristig sollte die Komponente per Middleware registriert werden können. Das bedeutet, dass die Implementierung im alten System optimale weise über einen Adapter stattfindet. Alle bisherigen Verwendungen der Session müssen zukünftig am neuen System geknüpft sein.