Garder le module compatible pour différentes versions Magento

Question

Aujourd'hui, je suis en cours d'exécution dans le problème suivant: A I développé module fonctionne très bien dans un magasin de version Magento 1.7. Maintenant, je dois adapter aussi travailler avec un magasin Magento 1.5.

Un point auquel la compatibilité fonctionne en dehors est dans ma collection où je suis exending la Mage_Core_Model_Resource_Db_Collection_Abstract de classe. Cette classe n'existe pas dans Magento 1.5, mais il a une fonctionnalité agréable comme getMainTable (). Une chose que je pourrais faire est d'utiliser plutôt le Varien_Data_Collection_Db de classe qui est héritée de Mage_Core_Model_Resource_Db_Collection_Abstract en. Cela fonctionne, mais je ne peux plus utiliser la méthode getMainTable () -. Même pas dans le 1.7 magasin où il existe réellement

Comment gérez-vous ces bizarreries spécifiques version? Il semble absurde d'écrire une classe personnalisée qui implémente la version 1.7 a déjà des choses et le code de ce fait en double dans cette version. D'autre part, il est mauvais de ne pas avoir la fonction et l'utilisation des habitudes de codage comme pire coder en dur à la place. Alors, est-il une bonne approche par écrit des modules Magento qui sont rétrocompatible?

Answer 1

Vous pouvez créer une classe intermédiaire qui implémente toutes les fonctions dont vous avez besoin et en fonction de la version de la mise en œuvre des parents d'appel magento ou utilisez votre propre implémentation:

modèle / 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
      }
    }
  }
?>

modèle / Final.php

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

Answer 2

Ceci est peut-être pas la réponse exacte que vous cherchez, mais je ne peux pas imaginer beaucoup de gens développent des extensions pour anciennes versions .

Il suffit de mettre à niveau, son inévitable de toute façon

La solution évidente est le 1.5 client de passer à 1,7 ( 1.5 est une version horriblement brisée de toute façon ).

Mais si vous devez

Si nous devions attaquer, ce serait juste un cas de sauvegarde du module avec un module de base secondaire à rétroporter la fonctionnalité de base dont vous avez besoin. Puis, quand vient le temps de mise à niveau, pourrait simplement être supprimé / retiré le module de dépendance.

Les inconvénients étant que vous pourriez potentiellement en remplaçant simplement les classes abstraites pour ajouter / modifier une seule fonction. Le temps investi dans ce pourrait bien être sur le pair avec la mise à niveau juste le magasin pour commencer.

En termes de faire des extensions rétrocompatible - il semble une pratique bizarre - comme-vous faire des compromis pour les nouvelles versions. Les extensions ont tendance à vieillir naturellement, de sorte que d'être plutôt en arrière-salles compatibles; vous développez sur lui pour le rendre compatible avant.

Si vous avez déjà regardé le code source des modules 3ème partie; ils ont tendance à être rempli d'appels Mage::getVersion() et déclarations conditionnelles - tous d'être multi-version compatible. Son désordre et doit être évité. Dans toute la réalité - vous devriez avoir différentes versions des extensions, pour les différentes versions de Magento. Sinon, vous serez confronté à soutenir une extension qui a des écarts dans les méthodes de classe et un nombre croissant de déclarations conditionnelles.

Bien que voici un bon exemple pourquoi ne pas

Je comprends votre logique. Mais ce qui se passe dans des cas tels que la 1.4.1> mise à niveau 1.4.2 et les tables de vente EAV ont été abandonnées. Toutes les fonctions plus récentes exploitées sur la base de cette table maintenant être plat - donc essayer de rétroporter c'est beaucoup plus compliqué que sa valeur. Cela peut être un extrême et vous faire clairement un jugement sur la façon dont le temps d'investir.

La dernière version de Magento va toujours être une cible en mouvement et étant donné le choix entre faire de nouveaux modules de travail avec les anciens magasins - ou les anciens modules de travail avec des magasins plus récents. Je sais ce que nous préférerions faire. Obsolescence des fonctions est lent et gracieux et vous avez beaucoup de temps pour les rendre plus récente.

Answer 3

Ce que vous faites face est assez facile à corriger. A partir de 1,6 certaines classes mysql4 ont été transférés à des classes de ressources, mais la compatibilité descendante est toujours pris en charge en tant que développeurs de Magento ont fait le nécessaire.

Pour les classes Mage_Core_Model_Resource_Db_Collection_Abstract utilisent Mage_Core_Model_Mysql4_Collection_Abstract à la place

Pour les classes Mage_Core_Model_Resource_Db_Abstract utilisent Mage_Core_Model_Mysql4_Abstract à la place

Si vous allez à ces classes mysql4 vous trouverez qu'ils sont vides et sont juste les classes de ressources étendent correctement

L'espoir que cela vous aide

Answer 4

En plus de la réponse de Domen Vrankar, vous pouvez aussi faire quelque chose comme:

<?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 );

Pas sûr que quelqu'un préférerait cette méthode, mais je l'ai vu Rewards Sweettooth le font.