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.
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:
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.
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å 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.
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.