Modul für verschiedene Magento-Versionen kompatibel halten

Heute stoße ich auf folgendes Problem: Ein von mir entwickeltes Modul funktioniert sehr gut in einem Magento 1.7-Versionsspeicher. Jetzt muss ich es anpassen, um auch mit einem Magento 1.5 Store zu arbeiten.

Ein Punkt, an dem die Kompatibilität auseinanderfällt, ist in meiner Sammlung, wo ich die Klasse erweitere Mage_Core_Model_Resource_Db_Collection_Abstract. Diese Klasse existiert in Magento 1.5 nicht, hat aber einige nette Funktionen wie getMainTable (). Eine Sache, die ich tun könnte, ist, stattdessen die Klasse zu verwenden, Varien_Data_Collection_Dbdie von in geerbt wird Mage_Core_Model_Resource_Db_Collection_Abstract. Dies funktioniert, aber dann kann ich die Methode getMainTable () nicht mehr verwenden - auch nicht in dem 1.7-Speicher, in dem sie tatsächlich vorhanden ist.

Wie gehen Sie mit solchen versionenspezifischen Macken um? Es erscheint absurd, eine benutzerdefinierte Klasse zu schreiben, die das Zeug implementiert, das Version 1.7 bereits hat, und dadurch Code in dieser Version zu duplizieren. Andererseits ist es schlecht, die Funktion nicht zu haben und stattdessen schlechtere Codierungsgewohnheiten wie Hardcodierung zu verwenden. Gibt es also einen guten Ansatz beim Schreiben von Magento-Modulen, die abwärtskompatibel sind?

Sie können eine Zwischenklasse erstellen, die alle von Ihnen benötigten Funktionen implementiert, abhängig von der Version der Implementierung des übergeordneten Magento-Aufrufs, oder Ihre eigene Implementierung verwenden:

Modell / Int.php

<?php
  if (!version_compare(Mage::getVersion(), '1.7', '>=')) {
    class N_M_Model_Int extends Mage_Core_Model_Resource_Db_Collection_Abstract
    {
    }
  } else {
    class N_M_Model_Int extends Varien_Data_Collection_Db
    {
      public function getMainTable()
      {
        // my implementation
      }
    }
  }
?>

model / Final.php

<?php
  class N_M_Model_Final extends N_M_Model_Int
  {
    // common code between all the versions
  }
?>

Dies ist vielleicht nicht die genaue Antwort, nach der Sie suchen, aber ich kann mir nicht vorstellen, dass viele Leute Erweiterungen für ältere Versionen entwickeln.

Einfach upgraden, es ist sowieso unvermeidlich

Die offensichtliche Lösung besteht darin, dass der 1.5-Kunde auf 1.7 aktualisiert ( 1.5 ist ohnehin eine schrecklich kaputte Version ).

Aber wenn du musst

Wenn wir uns darum kümmern müssten, müsste lediglich das Modul mit einem sekundären Basismodul gesichert werden, um die von Ihnen benötigten Kernfunktionen zurück zu portieren. Wenn dann die Zeit für ein Upgrade gekommen ist, kann das Abhängigkeitsmodul lediglich gelöscht / entfernt werden.

Die Nachteile sind, dass Sie möglicherweise abstrakte Klassen überschreiben können, nur um eine einzelne Funktion hinzuzufügen / zu ändern. Die dafür investierte Zeit könnte durchaus mit der anfänglichen Aufrüstung des Geschäfts vergleichbar sein.

In Bezug auf die Abwärtskompatibilität von Erweiterungen scheint dies eine seltsame Praxis zu sein, da Sie Kompromisse für neuere Versionen eingehen. Extensions altern in der Regel auf natürliche Weise, sodass sie eher rückwärtskompatibel sind. Sie entwickeln darauf, um es vorwärtskompatibel zu machen.

Wenn Sie sich jemals den Quellcode von Modulen von Drittanbietern angesehen haben; Sie sind in der Regel mit Mage::getVersion()Aufrufen und bedingten Anweisungen gefüllt - alle sind mit mehreren Versionen kompatibel. Es ist chaotisch und sollte vermieden werden. In Wirklichkeit sollten Sie verschiedene Versionen von Erweiterungen für verschiedene Versionen von Magento haben. Andernfalls werden Sie eine Erweiterung unterstützen, die Abweichungen in den Klassenmethoden und eine zunehmende Anzahl von bedingten Anweisungen aufweist.

Obwohl hier ein gutes Beispiel dafür ist, warum nicht

Ich verstehe deine Logik. Aber was in Fällen wie dem 1.4.1> 1.4.2Upgrade und den EAV-Verkaufstabellen passiert, wurde gelöscht. Alle neueren Funktionen, die auf der Grundlage dieser Tabelle ausgeführt werden, sind jetzt flach. Der Versuch, dies zurück zu portieren, ist also weitaus mühsamer als es sich lohnt. Dies kann extrem sein und Sie werden eindeutig beurteilen, wie viel Zeit Sie investieren müssen.

Die neueste Version von Magento wird für immer ein bewegliches Ziel sein und die Wahl haben, ob neue Module mit älteren Geschäften funktionieren sollen oder ältere Module mit neueren Geschäften. Ich weiß, was wir lieber machen würden. Die Ablehnung von Funktionen ist langsam und elegant, und Sie haben genügend Zeit, um sie neuer zu machen.

Was Sie sehen, ist ziemlich einfach zu beheben. Ab 1.6 wurden einige Mysql4-Klassen in Ressourcenklassen verschoben, aber die Abwärtskompatibilität wird weiterhin unterstützt, da Magento-Entwickler die erforderlichen Maßnahmen ergriffen haben.

Verwenden Sie für Mage_Core_Model_Resource_Db_Collection_Abstract-Klassen stattdessen Mage_Core_Model_Mysql4_Collection_Abstract

Verwenden Sie für Mage_Core_Model_Resource_Db_Abstract-Klassen stattdessen Mage_Core_Model_Mysql4_Abstract

Wenn Sie zu diesen Mysql4-Klassen gehen, werden Sie feststellen, dass sie leer sind und nur die Ressourcenklassen ordnungsgemäß erweitern

Hoffe das hilft dir weiter

Zusätzlich zu Domen Vrankars Antwort können Sie auch Folgendes tun:

<?php

if (!version_compare(Mage::getVersion(), '1.7', '>=')) {
    $code = "\nclass N_M_Model_Int extends Mage_Core_Model_Resource_Db_Collection_Abstract\n";
} else {
    $code = "\nclass N_M_Model_Int extends Varien_Data_Collection_Db\n";
}

$code .= <<<FEED
{
    //class implementation

} // END OF CLASS
FEED;

eval ( $code );

Ich bin mir nicht sicher, ob jemand diese Methode bevorzugen würde, aber ich habe gesehen, wie SweetTooth Rewards dies tat.