Giữ mô-đun tương thích cho các phiên bản Magento khác nhau

Hôm nay, tôi gặp phải vấn đề sau: Một mô-đun tôi đã phát triển hoạt động rất tốt trong cửa hàng phiên bản Magento 1.7. Bây giờ, tôi cần điều chỉnh nó để hoạt động với cửa hàng Magento 1.5.

Một điểm mà khả năng tương thích chạy xa nhau là trong bộ sưu tập của tôi, nơi tôi đang mở lớp Mage_Core_Model_Resource_Db_Collection_Abstract. Lớp này không tồn tại trong Magento 1.5, nhưng nó có một số chức năng hay như getMainTable (). Thay vào đó, một điều tôi có thể làm là sử dụng lớp Varien_Data_Collection_Dbđược kế thừa từ trong Mage_Core_Model_Resource_Db_Collection_Abstract. Điều này hoạt động, nhưng sau đó tôi không thể sử dụng phương thức getMainTable () nữa - thậm chí không có trong kho 1.7 nơi nó thực sự tồn tại.

Làm thế nào để bạn xử lý các quirks phiên bản cụ thể như vậy? Có vẻ vô lý khi viết một lớp tùy chỉnh thực hiện phiên bản 1.7 đã có và do đó sao chép mã trong phiên bản đó. Mặt khác, thật tệ khi không có chức năng và sử dụng các thói quen mã hóa tồi tệ hơn như mã hóa cứng thay thế. Vì vậy, có cách tiếp cận tốt nào trong việc viết các mô-đun Magento tương thích ngược không?

Bạn có thể tạo một lớp trung gian thực hiện tất cả các chức năng mà bạn yêu cầu và tùy thuộc vào phiên bản triển khai của magento gọi cha mẹ hoặc sử dụng triển khai của riêng bạn:

mô hình / 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
      }
    }
  }
?>

mô hình / Final.php

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

Đây có lẽ không phải là câu trả lời chính xác mà bạn đang tìm kiếm, nhưng tôi không thể tưởng tượng nhiều người đang phát triển các tiện ích mở rộng cho các phiên bản cũ hơn .

Chỉ cần nâng cấp, dù sao nó cũng không thể tránh khỏi

Giải pháp rõ ràng là cho khách hàng 1.5 nâng cấp lên 1.7 ( 1.5 dù sao cũng là một bản phát hành bị phá vỡ khủng khiếp ).

Nhưng nếu bạn phải

Nếu chúng ta phải giải quyết nó, đó sẽ chỉ là một trường hợp sao lưu mô-đun bằng một mô-đun nền tảng thứ cấp để sao lưu chức năng cốt lõi mà bạn yêu cầu. Sau đó, khi đến lúc nâng cấp, mô-đun phụ thuộc chỉ có thể bị xóa / xóa.

Nhược điểm là bạn có khả năng cuối cùng sẽ ghi đè các lớp trừu tượng chỉ để thêm / sửa đổi một hàm duy nhất. Thời gian đầu tư vào việc này có thể ngang bằng với việc nâng cấp cửa hàng để bắt đầu.

Về mặt làm cho các phần mở rộng tương thích ngược - có vẻ như là một thực tiễn kỳ lạ - khi bạn đang thỏa hiệp cho các bản phát hành mới hơn. Các tiện ích mở rộng có xu hướng già đi một cách tự nhiên, do đó thay vào đó là tương thích ngược; bạn phát triển dựa trên nó để làm cho nó chuyển tiếp tương thích.

Nếu bạn đã từng xem mã nguồn của các mô-đun bên thứ 3; chúng có xu hướng chứa đầy các Mage::getVersion()cuộc gọi và câu lệnh có điều kiện - tất cả đều tương thích với nhiều phiên bản. Nó lộn xộn và nên tránh. Trong thực tế - bạn nên có các phiên bản tiện ích mở rộng khác nhau, cho các phiên bản Magento khác nhau. Mặt khác, bạn sẽ phải đối mặt với việc hỗ trợ một tiện ích mở rộng có độ lệch trong phương thức lớp và số lượng câu lệnh điều kiện ngày càng tăng.

Mặc dù đây là một ví dụ tốt về lý do tại sao không

Tôi hiểu logic của bạn. Nhưng những gì xảy ra trong các trường hợp như nâng cấp 1.4.1> 1.4.2và bảng doanh số EAV đã bị loại bỏ. Bất kỳ chức năng mới nào được vận hành trên cơ sở của bảng này đều không thay đổi - vì vậy cố gắng sao lưu cổng này sẽ rắc rối hơn nhiều so với giá trị của nó. Đây có thể là một cực đoan và rõ ràng bạn sẽ thực hiện một cuộc gọi phán xét về việc đầu tư bao nhiêu thời gian.

Phiên bản mới nhất của Magento sẽ mãi mãi là mục tiêu di động và được lựa chọn giữa việc làm cho các mô-đun mới hoạt động với các cửa hàng cũ - hoặc các mô-đun cũ hơn hoạt động với các cửa hàng mới hơn. Tôi biết những gì chúng ta muốn làm. Sự phản đối của các chức năng là chậm và duyên dáng và bạn có nhiều thời gian để làm cho chúng mới hơn.

Những gì bạn đang phải đối mặt là khá dễ dàng để sửa chữa. Bắt đầu 1.6 một số lớp Mysql4 đã được chuyển sang các lớp Tài nguyên nhưng khả năng tương thích ngược vẫn được hỗ trợ vì các nhà phát triển Magento đã làm điều cần thiết.

Đối với các lớp Mage_Core_Model_Resource_Db_Collection_Abauge sử dụng Mage_Core_Model_Mysql4_Collection_Abauge thay thế

Đối với các lớp Mage_Core_Model_Resource_Db_Abauge sử dụng Mage_Core_Model_Mysql4_Abauge thay thế

Nếu bạn đi đến các lớp Mysql4 đó, bạn sẽ thấy rằng chúng trống và chỉ mở rộng các lớp Tài nguyên đúng cách

Hy vọng điều này sẽ giúp bạn ra ngoài

Ngoài câu trả lời của Domen Vrankar, bạn cũng có thể làm một cái gì đó như:

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

Không chắc ai đó thích phương pháp này, nhưng tôi đã thấy SweetTooth Awards làm điều này.