Vandaag bespreken we een van de coolste functies van OpenCart-scriptmeldingen. Hoewel ze beschikbaar zijn sinds de release van de OpenCart 2.x-versie, zijn ze verbeterd in de recente versie van OpenCart 2.2.x.x. In de loop van deze zelfstudie bespreken we het concept en demonstreren het door een werkmodule te maken.
Als ontwikkelaar moet u vaak de stroom van het hoofdraamgedrag wijzigen, of het nu gaat om het toevoegen van een nieuwe functie aan het framework of om de bestaande workflow te verbeteren. In beide gevallen moet u controle hebben over de werkstroom zodat u de functionaliteit kunt gebruiken en het gewenste gedrag kunt bereiken.
Laten we het proberen te begrijpen aan de hand van een eenvoudig voorbeeld. Als u een populaire online winkel heeft, is de kans groot dat de populairste producten van uw winkel binnenkort zijn uitverkocht. In dit geval zou het fijn zijn om hier een melding over te krijgen en dienovereenkomstig de juiste actie te ondernemen.
Dus wat je zou kunnen doen in het bovengenoemde voorbeeld is om te zoeken naar de methode die wordt genoemd wanneer de bestelling wordt geplaatst. Vervolgens kun je de volgorde van het maken van bestellingen volgen, zodat je kunt bepalen wanneer de bestelling wordt geplaatst. Hiermee kunt u een willekeurig stuk code uitvoeren in de context van de aanroepende gebeurtenis. Dat is het moment waarop gebeurtenismeldingen in beeld komen, waardoor we willekeurige code kunnen uitvoeren en de resulterende uitkomst kunnen wijzigen.
Volgens de officiële OpenCart-documentatie:
In 2.2+ hebben we een nieuw gebeurtenissensysteem toegevoegd, dit zijn hooks die voor en na gebeurtenissen kunnen worden aangeroepen, zoals een aanroep van een controlemechanismemethode, een aanroep van een modelmethode of sjablonen die worden geladen. Ze geven de mogelijkheid om de parameters van de invoermethode en de geretourneerde uitvoer te manipuleren.
Dat is echt krachtig, omdat je letterlijk een methode-call kunt gebruiken en de output die door die methode wordt geretourneerd kan veranderen. U moet echter voorzichtig zijn tijdens de implementatie van hooks, als u de verantwoordelijkheid neemt om de resulterende output van de oproep aan te passen. Dat komt omdat als uw implementatie een waarde retourneert, dit alle andere acties van de gebeurtenis stopt die zijn ingesteld om te worden aangeroepen.
Wat is er nodig om scriptmeldingen te implementeren? Hier zijn de nodige stappen:
Wanneer u uw evenement registreert met OpenCart, vertelt u OpenCart dat u wilt controleren xyz
actie, en als dat gebeurt, voer dan de foo-actie uit in het barcontrollerbestand. Terwijl u dit doet, hebt u twee opties waaruit u kunt kiezen: voor en na.
Als u de eerder-optie kiest, zal OpenCart de foo-actie uitvoeren vóór de actie die wordt bewaakt, en in het geval van de optie na voert het foo uit na de actie. In het geval van de voor-optie is het belangrijk om op te merken dat als de foo-methode iets retourneert, OpenCart de oorspronkelijke methode-code die wordt gecontroleerd helemaal niet uitvoert..
Verderop in dit artikel zullen we zien hoe een evenement kan worden geregistreerd tijdens de implementatie van de aangepaste module.
Vervolgens moet u de controller en de bijbehorende actiemethode implementeren die in de eerste stap aan een gebeurtenis is gekoppeld. Dat is de plaats waar uw aangepaste code moet worden ingeleverd. OpenCart verzendt contextspecifieke argumenten naar uw foo-methode, zodat u deze indien nodig kunt gebruiken.
Dus dat is slechts een glimp van waar scriptmeldingen toe in staat zijn.
Als je bekend bent met vQmod of OCMOD, is de kans groot dat je de handen uit de mouwen steekt tegen de gebeurtenismeldingen. Per slot van rekening zou je alles kunnen bereiken met de bovengenoemde goodies die je sowieso zou hebben bereikt met notificaties van evenementen.
Voor degenen die niet bekend zijn met VQmod of OCMOD, zijn hieronder mooie inleidende artikelen die het uitleggen.
Dus de vraag is, als je vQmod of OCMOD zou kunnen gebruiken om de kernbestanden te veranderen, waarom zou je dan scriptmeldingen gebruiken? Het is vanwege het feit dat er meerdere OCMOD-plug-ins kunnen zijn die proberen dezelfde code te wijzigen en die kunnen leiden tot conflicten. In het geval van evenementen is er geen kans op conflicten, omdat elke gebeurtenis in een specifieke volgorde wordt uitgevoerd.
Dus de conclusie is dat als het mogelijk is om evenementen te gebruiken, daarvoor moet gaan. Aan de andere kant, als u vindt dat er geen evenement beschikbaar is voor uw use-case, is het helemaal goed om met OCMOD te werken.
In deze sectie gaan we een module bouwen die laat zien hoe je gebeurtenismeldingen gebruikt in OpenCart. Ik neem aan dat je op de hoogte bent van het basismoduulontwikkelingsproces in OpenCart, omdat we de basis zullen doorspitten. Als je het niet weet, is hier een leuk artikel dat je snel kunt doornemen.
Laten we de use-case begrijpen voordat we doorgaan en het implementeren. Stel dat u een winkel heeft die de catalogusinformatie van de API-backend van derden ophaalt. U hebt een cron ingesteld die de informatie regelmatig ophaalt en invoegt in de OpenCart-database, zodat deze in de front-end kan worden weergegeven. Hoewel u een cron hebt ingesteld die de informatie regelmatig bijwerkt, moet u ervoor zorgen dat de informatie die in de front-end wordt weergegeven, in realtime moet zijn.
In de front-end roept OpenCart de getProduct
functie wanneer deze de productdetailpagina toont. Dus dat is de ideale kandidaat voor u om de database aan te haken en bij te werken als de API-informatie is gewijzigd.
Laten we dus eerst de back-endbestanden maken.
Ga je gang en maak de admin / controller / module / demoevent.php
bestand met de volgende inhoud.
load-> model ( 'uitbreiding / event'); $ this-> model_extension_event-> addEvent ('event_product_info', 'catalogus / model / catalogus / product / getProduct / before', 'custom / product / info'); openbare functie de-installatie () $ this-> load-> model ('extension / event'); $ This-> model_extension_event-> deleteEvent ( 'event_product_info');
Zoals we eerder hebben besproken, is het eerste dat u zou willen doen de registratie van het evenement. Het is de installatiehaak die we zullen gebruiken om het te doen, omdat het zal worden uitgevoerd wanneer de module is geïnstalleerd.
We hebben de Voeg evenement toe
methode van het evenementmodel onder de uitbreiding map en die methode heeft drie argumenten.
Het eerste argument, event_product_info, is de naam van het evenement. Je zou het alles kunnen noemen, maar zorg ervoor dat het uniek is.
Het tweede argument is erg belangrijk, en het wijst op de methode die u zou willen inhaken. In ons geval moeten we kiezen voor getProduct
methode van de Artikel Model onder de Catalogus directory. Dus de hiërarchie is model / catalog / product / getProduct
. Daarnaast moet het ook door een van beide worden voorafgegaan catalogus of beheerder, wat staat voor de applicatie. In ons geval is dat zo catalogus terwijl we de front-endmethode gebruiken. Ten slotte wordt het post-gefixeerd voor of na, wat OpenCart vertelt om onze code dienovereenkomstig uit te voeren.
Het derde argument wijst naar de actie van uw controller die wordt geactiveerd wanneer de gebeurtenis wordt gestart. Het is ingesteld op douane / product / info
, dus je moet een maken Artikel controller met de info
methode onder de gewoonte directory, zoals we in een ogenblik zullen doen.
Ten slotte wordt de verwijderingsmethode gebruikt om de gebeurtenis te verwijderen tijdens het verwijderen van de module.
Laten we vervolgens een taalbestand maken voor onze aangepaste module op admin / language / nl-nl / module / demoevent.php
met de volgende inhoud.
We zijn klaar met de configuratie van het back-end-bestand. Nu zou je onze module hieronder vermeld moeten kunnen zien Extensies> Modules in de back-end van OpenCart. Ga je gang en installeer het. Nu gaan we door en maken we de bestanden aan de voorkant.
Maak een modelbestand
catalogus / model / custom / product.php
met de volgende inhoud. Het is een typisch modelbestand volgens de OpenCart-structuur.db-> query ("SELECT date_modified FROM". DB_PREFIX. "product WHERE product_id = '". (int) $ product_id. "'"); return $ query-> rij; function updateProductInfo ($ product_id, $ data) include_once __DIR __. '... / ... / ... /admin/model/catalog/product.php'; $ modelCatalogProduct = nieuw ModelCatalogProduct (); $ modelCatalogProduct-> editProduct ($ product_id, $ data);Het implementeert twee belangrijke methoden. De
getProductLastModifiedInfo
methode wordt gebruikt om de laatste gewijzigde datum van het product op te halen, en deupdateProductInfo
methode wordt gebruikt om de productinformatie in de database bij te werken. We zullen in een oogwenk zien hoe deze methoden zullen worden gebruikt.Laten we tot slot een van de belangrijkste bestanden van dit artikel maken,
catalogus / controller / custom / product.php
, met de volgende inhoud. Het is een controllerbestand dat de. Implementeertinfo
actiemethode die is ingesteld om te worden aangeroepen wanneer degetProduct
methode van de product Model wordt genoemd.load> model ( 'aangepaste / product'); $ product_modified_date = $ this-> model_custom_product-> getProductLastModifiedInfo ($ product_id); if ($ product_modified_date ['date_modified']! = $ product_api_info ['date_modified']) // api info is veranderd, dus laten we eerst db // updaten: Opmerking: je wilt waarschijnlijk $ product_api_info formatteren volgens het formaat dat is vereist door editProduct-methode $ this-> model_custom_product-> updateProductInfo ($ product_id, $ product_api_info); // return laatste / real-time productinformatie retourarray ('product_id' => $ product_api_info ['product_id'], 'naam' => $ product_api_info ['naam'], 'description' => $ product_api_info ['description' ], 'meta_title' => $ product_api_info ['meta_title'], 'meta_description' => $ product_api_info ['meta_description'], 'meta_keyword' => $ product_api_info ['meta_keyword'], 'tag' => $ product_api_info [' tag '],' model '=> $ product_api_info [' model '],' sku '=> $ product_api_info [' sku '],' upc '=> $ product_api_info [' upc '],' ean '=> $ product_api_info ['ean'], 'jan' => $ product_api_info ['jan'], 'isbn' => $ product_api_info ['isbn'], 'mpn' => $ product_api_info ['mpn'], 'location' => $ product_api_info ['location'], 'quantity' => $ product_api_info ['quantity'], 'stock_status' => $ product_api_info ['stock_status'], 'image' => $ product_api_info ['image'], 'manufacturer_id' => $ product_api_info ['fabrikant_id'], 'fabrikant' => $ product_api_info ['fabrikant'], 'prijs' => ($ product_api_info ['korting']? $ product_api_in fo ['korting']: $ product_api_info ['price']), 'special' => $ product_api_info ['special'], 'reward' => $ product_api_info ['reward'], 'points' => $ product_api_info [ 'punten'], 'tax_class_id' => $ product_api_info ['tax_class_id'], 'date_available' => $ product_api_info ['date_available'], 'weight' => $ product_api_info ['weight'], 'weight_class_id' => $ product_api_info ['weight_class_id'], 'length' => $ product_api_info ['length'], 'width' => $ product_api_info ['width'], 'height' => $ product_api_info ['height'], 'length_class_id' = > $ product_api_info ['length_class_id'], 'subtract' => $ product_api_info ['aftrekken'], 'rating' => ronde ($ product_api_info ['rating']), 'reviews' => $ product_api_info ['reviews'] ? $ product_api_info ['reviews']: 0, 'minimum' => $ product_api_info ['minimum'], 'sort_order' => $ product_api_info ['sort_order'], 'status' => $ product_api_info ['status'], ' date_added '=> $ product_api_info [' date_added '],' date_modified '=> $ product_api_info [' date_modified '],' viewed '=> $ product_api_info [' viewed ']);Het belangrijkste om op te merken is dat OpenCart context-specifieke argumenten voor uw methode biedt. De eerste
$ route
argument vertelt u de route die is gekoppeld aan de gebeurtenis die is geactiveerd. In ons geval zou het moeten zijncatalogus / product / getProduct
. Het tweede argument is het product-ID, omdat het een vereist argument is van de werkelijkegetProduct
methode.De logica is ongeveer als volgt: we zullen de gewijzigde datum van het product in de OpenCart-database vergelijken met de informatie die wordt geretourneerd door de API callback.
Dus de eerste stap is het laden van de real-time productinformatie van de API. Houd er rekening mee dat de api_call_to_fetch_product_info methode is gewoon een dummy-methode die u wilt vervangen door uw huidige API-aanroep.
Vervolgens gebruiken we de
getProductLastModifiedInfo
methode, die in de vorige sectie is gemaakt, om de gewijzigde datum van het product uit de OpenCart-database op te halen.Ten slotte doen we de vergelijking, en als de datum anders is, wordt de OpenCart-database bijgewerkt met de nieuwste productinformatie met behulp van de
updateProductInfo
methode in onze Model-klasse.We hebben de productinformatie ook geretourneerd in een matrixindeling op dezelfde manier als de werkelijke
getProduct
zou zijn teruggekeerd. Het is belangrijk om op te merken dat we, omdat we de geretourneerde waarde in onze hook hebben opgegeven, geen verdere event calls zullen bellen, inclusief de call naar de originelegetProduct
methode ook.Op deze manier kunt u de uitvoeringsstroom in OpenCart beïnvloeden. Het is een heel krachtige manier om de kernfunctionaliteit te veranderen. U moet echter voorzichtig zijn bij het naderen van deze oplossing, omdat u hiermee totale controle heeft om de resulterende uitvoer van elke methode te wijzigen.
Conclusie
Vandaag hebben we een van de opwindende functies in OpenCart besproken, genaamd scriptmeldingen. We zijn begonnen met een inleiding tot het onderwerp en het was de tweede helft van het artikel die liet zien hoe deze te gebruiken door een aangepaste evenementmodule te bouwen.
Zoals altijd, als u op zoek bent naar aanvullende OpenCart-hulpmiddelen, hulpprogramma's, uitbreidingen en dergelijke die u kunt gebruiken in uw eigen projecten of voor uw eigen opleiding, vergeet dan niet te zien wat we beschikbaar hebben op de markt.
Vragen en opmerkingen zijn altijd welkom!