Înțelegeți suprascrierea în Magento Controlere

În cel de-al treilea și ultimul articol al acestei serii Magento, vom explica cum să înlocuiți fișierele controlerului de bază. În cele două articole anterioare ale acestei serii, am discutat despre principalele fișiere de bază pentru blocuri și modele prin crearea unui modul personalizat. În acest tutorial, vom examina fișierele de bază ale controlerului principal.

De ce controlorii suprascriptibile?

În Magento, controlorul este responsabil pentru manipularea cererilor de intrare și este o coloană vertebrală a implementării de rutare Magento. Pentru a gestiona, probabil, orice cerere din Magento, controlorul definește diferite acțiuni sub formă de metode de clasă controler. Metoda de acțiune a controlerului include logica aplicației asociate care interacționează cu vizualizările și modelele pentru a pregăti ieșirea acelei pagini. Uneori, trebuie să modificați fluxul de execuție a controlerului pentru a injecta codul personalizat sau pentru a modifica codul de bază.

Așa cum am spus în tutorialul precedent, nu este recomandat să schimbați direct fișierele de bază, deoarece face ca actualizarea Magento să fie foarte dificilă. Pentru a evita acest lucru, ar trebui să urmăm modul standard de a face modificările dorite în fișierele de bază: ar trebui să folosim fie observatori de eveniment, fie să ignorăm fișierele de bază cu fișierele module personalizate. Vom discuta astăzi caracterul imperativ.

În acest tutorial, vom face un modul personalizat pentru a înțelege modul în care funcționează controlerul în Magento. În acest modul personalizat, vom vedea cum să înlocuiți o clasă de controler "Produs" a modulului de bază "Catalog". Împuternicirea funcționează prin crearea unor etichete XML conform convențiilor Magento.

Presupun că sunteți familiarizat cu procesul de creare a modulului de bază în Magento. Dacă nu, vă puteți referi la acest articol despre crearea de module personalizate. 

O privire la configurare

Iată lista fișierelor necesare pentru configurarea dorită:

• app / etc / module / Envato_All.xml: Este un fișier folosit pentru a permite modulul nostru personalizat.
• app / code / local / Envato / Catalog / etc / config.xml: Este un fișier de configurare a modulului în care vom seta suprascrierea unei clase de controler folosind anumite etichete conform convențiilor Magento.
• app / code / local / Envato / Catalog / controlere / ProductController.php: Este un fișier de clasă controler personalizat pe care îl vom folosi pentru a suprascrie clasa de bază "Product".

Crearea de fișiere și foldere: Modul personalizat

În primul rând, trebuie să creăm un fișier de activator de module. Creați un fișier "app / etc / modules / Envato_All.xml" și lipiți următorul conținut în acel fișier. Am folosit-o Envato ca spațiu de nume și modulul nostru Catalog ca numele modulului nostru. Acesta va permite modulul "Catalog" în mod implicit.

    Adevărat local   

Apoi, trebuie să creați un fișier de configurare a modulului. Creați "app / code / local / Envato / Catalog / etc / config.xml" și lipiți următorul conținut în acel fișier.

    1.0        Envato_Catalog      

Mai întâi, am definit un număr de versiune a modulului utilizând  etichetă. tag este numele router-ului de control al frontalului modulului de bază "Catalog". Acesta informează sistemul de rutare că dorim să suprascrieți controlorii modulului "Catalog". 

În cele din urmă, Envato_Catalog eticheta este utilizată pentru a informa sistemul de rutare Magento că ar trebui să încarce fișierele controlerului modulului personalizat, dacă este disponibil. Desigur, va încărca fișierele de bază ale modulului "Catalog" dacă nu le poate găsi sub modulul dvs..

În cele din urmă, singurul lucru rămas este definirea unei clase de controler Envato_Catalog_ProductController. Să creăm un fișier de control "app / code / local / Envato / Catalog / controllers / ProductController.php" și să inserăm conținutul următor în fișierul respectiv.

getRequest () -> getParam ("categorie", falsă); $ productId = (int) $ this-> getRequest () -> getParam ("id"); $ specifyOptions = $ this-> getRequest () -> getParam ("opțiuni"); // Pregătiți ajutor și paramuri $ viewHelper = Mage :: helper ('catalog / product_view'); $ params = noul Varien_Object (); $ Params-> setCategoryId ($ categoryID); $ Params-> setSpecifyOptions ($ specifyOptions); // Reveniți la pagina de încercare $ viewHelper-> prepareAndRender ($ productId, $ this, $ params);  captură (Excepție $ e) if ($ e-> getCode () == $ viewHelper-> ERR_NO_PRODUCT_LOADED) dacă (isset ($ _GET ['store']) &&! $ this-> getResponse ()) $ this -> _ redirect (); elseif (! $ this-> getResponse () -> isRedirect ()) $ this -> _ forward ('noRoute' ($ e); $ this -> _ înainte ('noRoute');

Am definit un Envato_Catalog_ProductController clasa care extinde nucleul Mage_Catalog_ProductController clasa de controler a modulului Catalog. Cel mai important lucru pe care trebuie să-l reținem aici este că am inclus fișierul de bază al controlerului "Mage / Catalog / controllers / ProductController.php" înainte de definiția clasei, deoarece Magento nu o va include automat.

În exemplul de mai sus, l-am înlocuit viewAction metodă a Mage_Catalog_ProductController clasă. Aceasta înseamnă că ori de câte ori o pagină de detaliu a produsului este privită în partea frontală, va apela viewAction metoda definită în clasa personalizată a controlorului. Deci, puteți modifica codul definit în acea metodă conform cerințelor dvs..

Concluzie

Deci, astăzi, am învățat cum să înlocuiți fișierele de bază ale controlerului în Magento utilizând un modul personalizat. Sper că v-ați bucurat de această serie și ați învățat ceva util pe care îl puteți implementa în codul dvs.! Distribuiți întrebările și sugestiile utilizând feedul de mai jos!