Hvordan sendes i OpenCart

Som programmerer er det viktig at du forstår strømmen av systemet du jobber med, ikke bare for å kunne endre noe når det trengs, men også fordi det vil gi deg et tillitshopp når du gjør det.

I dag velger vi OpenCart og dissekerer det for å forstå det grunnleggende i distribusjonsprosessen. Vi starter med det som sendeprosessen handler om, og når vi går videre, vil vi utforske kodesnitt fra de ulike delene av rammen.

Jeg henter den nyeste versjonen av OpenCart for denne artikkelen, men mer eller mindre strømmen er lik i tidligere versjoner.

Sende i et nøtteskall

I en hvilken som helst nettbasert applikasjon brukes forsendingsprosessen til å finne kartleggingen mellom den innkommende forespørselsadressen og den tilhørende modulen i rammen. Selvfølgelig varierer implementeringen fra rammeverk til rammeverk, men det underliggende konseptet forblir det samme. Så her er noen av senderens ansvar:

  • Ta tak i passende parametere fra Request Object.
  • Finn den tilsvarende modulen og handlingen som skal kalles.
  • Hvis den tilsvarende modulen og handlingen er funnet, avsluttes forsendelsesprosessen.
  • Hvis ingen modul er funnet for den oppgitte forespørselen, er standardhandlingen satt og sendeprosessen avsluttes.

La oss prøve å forstå dette ved hjelp av et enkelt eksempel i OpenCart. For å opprette en ny bruker fra fronten, må man registrere seg på nettstedet ved hjelp av http://www.youropencartstore.com/index.php?route=account/register. La oss oppsummere trinnene som er tatt av OpenCart for å gjøre den forespurte siden.

  • Først sjekker den tilstedeværelsen av "rute" spørringsstrengvariabelen, ellers vil den sette «common / home» som en standard «rute» på siden.
  • I vårt tilfelle er det til stede, så det vil sette opp de nødvendige variablene og utløse sendingsprosessen.
  • Ved begynnelsen av forsendelsesprosessen vil det kjøre noen av "preAction" -aksjonene som brukes til å utføre vanlige oppgaver. Vi diskuterer "preAction" ting i den senere delen av denne artikkelen.
  • Endelig vil det sjekke om det finnes en kontrollerfil tilgjengelig for den nåværende "rute" -variabelen, og hvis det er en, blir det kalt for å hente svaret.
  • Hvis det ikke finnes noen kontrollerfil tilgjengelig for den forespurte "rute" -variabelen, vil den utføre "error / not_found" -handlingen, som viser meldingen "side ikke funnet" til brukeren.

Så det er et toppnivåvisning av hvordan OpenCart går gjennom den forespurte nettadressen og returnerer svaret. I neste avsnitt vil vi gå dypere og se hvordan akkurat det gjør det.

Gå gjennom strømmen

Gå videre og åpne index.php fil i dokumentroten til OpenCart. Det skjer mye i den filen, men blir ikke overveldet, for det meste er bare oppsettet av objekter som brukes i rammen.

La oss straks trekke inn snippet av interesse fra den filen.

// Front Controller $ controller = ny Front ($ register); // Vedlikeholdsmodus $ controller-> addPreAction (ny handling ('vanlig / vedlikehold')); // SEO URLs $ controller-> addPreAction (ny handling ('common / seo_url'));

Som med de fleste andre rammer, er OpenCart også avhengig av frontkontrollermønsteret slik at det er et felles inngangspunkt for alle forespørsler i søknaden.

Først skaper vi en forekomst av frontkontrolleren og tilordner den til $ controller variabel. Umiddelbart ved siden av det ringer vi addPreAction metode for å legge til et par tiltak.

Nå bringer det et annet emne på bordet: Hva er en "preAction"? Enkelt sagt er en preAction en handling som vil bli utført før den forespurte handlingen på en hvilken som helst side. For eksempel, når brukeren klikker på en side, vil du sjekke om nettstedet er i vedlikeholdsmodus eller ikke før den faktiske svaret returneres. I så fall kan du bruke en preAction slik at brukeren blir omdirigert til vedlikeholdssiden hvis den er på.

Vi legger også til felles / seo_url som en preAction også, siden i tilfelle av et SEO-aktivert nettsted vi ønsker å hente de tilsvarende rutevariablene før den faktiske forsendelsen starter.

La oss gå videre til neste viktige utdrag.

// Router hvis (isset ($ request-> få ['route'])) $ action = new Action ($ request-> få ['route']);  else $ action = new Action ('common / home'); 

Det kontrollerer tilstedeværelsen av "rute" spørringsstrengvariabelen, og hvis den er der, oppretter vi en forekomst av Handling klasse ved å sende den nåværende "rute" verdien som et konstruktørargument. Hvis den ikke er til stede, gjør vi det samme med startsiden rute URI-felles / home.

Med vår $ handling variabel sett med riktig verdi, la oss gå videre til neste utdrag.

// Dispatch $ controller-> send ($ action, new Action ('error / not_found'));

Til slutt, vi ringer til utsendelse metode for den fremre kontrollerklassen. Gå videre og åpne Systemet / motor / front.php og finn følgende utdrag.

offentlig funksjon forsendelse ($ handling, $ feil) $ this-> error = $ error; foreach ($ this-> pre_action as $ pre_action) $ result = $ this-> utfør ($ pre_action); hvis ($ resultat) $ action = $ result; gå i stykker;  mens ($ action) $ action = $ this-> utfør ($ action); 

Dette er metoden der alt magien skjer! Først utfører den alle "preActions" som diskutert tidligere. Videre i løpet av løkken vil den prøve å utføre vår nåværende $ handling, bestått som et argument av henrette metode.

La oss følge definisjonen av henrette metode i samme fil.

Privat funksjon utføre ($ action) $ result = $ action-> utfør ($ this-> register); hvis (is_object ($ result)) $ action = $ result;  elseif ($ result === false) $ action = $ this-> feil; $ this-> error = "; else $ action = false; returner $ action;

På den aller første linjen, den henrette metode av Handling klassen heter. Ikke forveksle det med henrette metode for Front Controller-klassen. Åpne filen Systemet / motor / action.php og her er det.

Offentlig funksjon utføre ($ register) // Stopp noen magiske metoder som kalles hvis (substr ($ this-> metode, 0, 2) == '__') return false;  hvis (is_file ($ this-> file)) include_once ($ this-> file); $ class = $ this-> class; $ controller = ny $ class ($ register); hvis (is_callable (array ($ controller, $ this-> metode))) return call_user_func (array ($ controller, $ this-> metode), $ this-> args);  ellers return false;  ellers return false; 

Det viktige å merke seg her er at Handling klassen oppretter allerede de nødvendige variablene i konstruktøren selv når handlingsobjektet blir instansert i index.php. Det setter opp fil, klasse og metode egenskaper, som vil bli brukt i henrette metode. For å holde ting mindre komplisert, diskuterer vi bare henrette metode, selv om jeg vil anbefale at du går gjennom konstruktøren av Handling klasse.

Tilbake til vår henrette metode av Handling klassen, kontrollerer den tilstedeværelsen av filen ($ Dette-> file) knyttet til den nåværende ruten. Hvis alt er bra, inneholder det den filen og kaller den tilsvarende metoden ($ Dette-> metode) av den kontrolleren klassen ved hjelp av call_user_func funksjonen og returnerer svaret.

Hvis den tilknyttede filen ikke er tilgjengelig, kommer den tilbake falsk. La oss nå komme tilbake til bunten fra henrette metode for Front Controller-klassen. Vær tålmodig, vi er nesten der!

... $ result = $ action-> utfør ($ this-> register); hvis (is_object ($ result)) $ action = $ result;  elseif ($ result === false) $ action = $ this-> feil; $ this-> error = "; else $ action = false; returnere $ action; ... 

Når kjøringsmetoden til Handling klassen fullfører prosessen, den returnerer resultatet og den er tildelt til $ resultat variabel. Nå er det tre forskjellige muligheter med verdien lagret i $ resultat. La oss undersøke hver enkelt.

Hvis alt gikk bra, har vi HTML-utdata i $ resultat variabel, slik at $ handling variabel er satt til falsk og prosessen avsluttes. Det er det siste andre tilfellet.

Husk at vi returnerte falsk hvis den tilhørende kontrollerfilen ikke ble funnet i henrette metode av Handling klasse. I så fall er det $ handling variabel vil bli satt til $ Dette-> feil (feil ikke funnet Handling), og "siden ikke funnet" vises til brukeren.

Og til slutt, hvis vi finner ut at $ resultat er et objekt selv, vi setter det til $ handling variabel. Ja, det er rart: Hvorfor på jorden ville kontrollmodulen returnere en annen Handling objekt, når det skal returnere HTML-utdata for forespurt side? Men det er bare en av måtene som kontrolleren omdirigerer brukerne til en annen nettadresse.

La oss raskt åpne katalog / styreenhet / common / maintenance.php filen og se den i aksjon. I index metode, returnerer den Handling objekt hvis visse forhold er sanne.

... hvis (($ route! = 'Betaling' && $ route! = 'Api') &&! $ This-> user-> isLogged ()) returner ny handling ('felles / vedlikehold / info');  ... 

Så, som du kan se, returnerer den Handling motsette seg å omdirigere brukeren til felles / vedlikehold / info URL. Selvfølgelig er det en kode i utsendelse metode for den fremre kontrollerklassen for å håndtere denne oppførselen. Husk brikken fra den metoden - jeg lover at det er den siste brikken av denne opplæringen.

... mens ($ action) $ action = $ this-> kjøre ($ action);  ... 

Så det er en stundsløyfe, og den går til den finner den $ handling variabel satt til falsk! Nærmere bestemt, vil det avslutte sløyfen når vi har nyttig utgang for brukeren vår.

Så det er slutten på reisen. Jeg håper at det ikke var så komplisert som det så ut til å være ved første øyekast.

Konklusjon

I dag har vi gjennomgått et viktig aspekt av OpenCart-rammeverket - distribusjonsprosessen. Vi forsto det grunnleggende for sending og gikk gjennom hele strømmen for å forstå hvordan det fungerer.

Hvis du leter etter ekstra OpenCart-verktøy, verktøy, utvidelser og så videre som du kan utnytte i dine egne prosjekter eller for din egen utdanning, ikke glem å se hva vi har tilgjengelig på markedet.

For spørsmål, ikke nøl med å legge igjen dine kommentarer. Også, Twitter er et annet alternativ for å kontakte meg, og jeg svarer raskt.