Come programmatore, è importante capire il flusso del sistema con cui stai lavorando, non solo per poter alterare qualcosa quando necessario, ma anche perché ti darà una spinta di fiducia mentre lo fai.
Oggi selezioneremo OpenCart e sezioneremo per capire le basi del processo di spedizione. Inizieremo con il processo di spedizione e mentre procediamo esploreremo sezioni di codice dalle diverse sezioni del framework.
Prenderò l'ultima versione di OpenCart per questo articolo, ma più o meno il flusso è simile nelle versioni precedenti.
In qualsiasi applicazione basata sul Web, il processo di dispatch viene utilizzato per trovare il mapping tra l'URL della richiesta in entrata e il modulo corrispondente nel framework. Naturalmente, l'implementazione varia da quadro a quadro, ma il concetto di fondo rimane lo stesso. Quindi ecco alcune delle responsabilità del dispatcher:
Proviamo a capire questo utilizzando un semplice esempio in OpenCart. Per creare un nuovo utente dal front-end, è necessario registrarsi al sito utilizzando http://www.youropencartstore.com/index.php?route=account/register. Riassumiamo i passi compiuti da OpenCart per rendere la pagina richiesta.
Quindi questa è una vista di primo livello di come OpenCart passa attraverso l'URL richiesto e restituisce la risposta. Nella prossima sezione approfondiremo e vedremo come esattamente lo fa.
Vai avanti e apri il index.php
file nella root del documento di OpenCart. Ci sono molte cose che accadono in quel file, ma non ci sentiamo sopraffatti, dato che la maggior parte è solo la configurazione degli oggetti usati in tutto il framework.
Iniziamo subito a inserire il frammento di nostro interesse da quel file.
// Front Controller $ controller = new Front ($ registry); // Maintenance Mode $ controller-> addPreAction (new Action ('common / maintenance')); // SEO $ controller-> addPreAction (new Action ('common / seo_url'));
Come con la maggior parte degli altri framework, OpenCart si affida anche al pattern del front controller in modo che ci sia un punto di accesso comune per tutte le richieste nell'applicazione.
Per prima cosa, stiamo creando un'istanza del front controller e assegnandola al $ Controller
variabile. Subito dopo, stiamo chiamando il addPreAction
metodo per aggiungere un paio di azioni.
Ora, questo porta un altro argomento sul tavolo: cos'è una "preAzione"? In termini semplici, un'azione preliminare è un'azione che verrà eseguita prima dell'azione richiesta su qualsiasi pagina. Ad esempio, quando l'utente fa clic su qualsiasi pagina, si desidera verificare se il sito è in modalità di manutenzione o meno prima che venga restituita la risposta effettiva. In tal caso, è possibile utilizzare una preAzione in modo che l'utente venga reindirizzato alla pagina di manutenzione se è attivo.
Inoltre, stiamo aggiungendo comuni / seo_url
anche come preAzione, dal momento che nel caso di un sito abilitato per il SEO vogliamo recuperare le variabili di percorso corrispondenti prima che inizi l'effettivo dispacciamento.
Passiamo al prossimo snippet importante.
// Router if (isset ($ request-> get ['route'])) $ action = new Action ($ request-> get ['route']); else $ action = new Action ('common / home');
Controlla la presenza della variabile della stringa di query "route" e, se è presente, creeremo un'istanza di Azione
class passando il valore corrente "route" come argomento del costruttore. Se non è presente, faremo lo stesso con l'URI del percorso della home page-comuni / home
.
Con la nostra $ azione
variabile impostata con il valore corretto, passiamo allo snippet successivo.
// Dispatch $ controller-> dispatch ($ action, new Action ('error / not_found'));
Infine, stiamo chiamando il spedizione
metodo della classe front controller. Vai avanti e apri Sistema / motore / Front.php
e trova il seguente frammento.
invio di funzione pubblica ($ azione, $ errore) $ this-> errore = $ errore; foreach ($ this-> pre_action as $ pre_action) $ result = $ this-> execute ($ pre_action); se ($ risultato) $ azione = $ risultato; rompere; while ($ action) $ action = $ this-> execute ($ action);
Questo è il metodo in cui avviene tutta la magia! Innanzitutto, esegue tutte le "preAzioni" come discusso in precedenza. Inoltre, nel ciclo while cercherà di eseguire la nostra corrente $ azione
, passato come argomento del eseguire
metodo.
Seguiamo la definizione di eseguire
metodo nello stesso file.
funzione privata execute ($ action) $ result = $ action-> execute ($ this-> registry); if (is_object ($ result)) $ action = $ result; elseif ($ result === false) $ action = $ this-> error; $ this-> error = "; else $ action = false; return $ action;
Sulla prima riga, il eseguire
metodo del Azione
la classe è chiamata. Non confonderlo con il eseguire
metodo della classe Front controller. Apri il file Sistema / motore / action.php
ed eccolo qui.
funzione pubblica execute ($ registry) // Interrompe qualsiasi metodo magico chiamato if (substr ($ this-> method, 0, 2) == '__') return false; if (is_file ($ this-> file)) include_once ($ this-> file); $ class = $ this-> class; $ controller = new $ class ($ registry); if (is_callable (array ($ controller, $ this-> method))) return call_user_func (array ($ controller, $ this-> method), $ this-> args); else return false; else return false;
La cosa importante da notare qui è che il Azione
la classe imposta già le variabili richieste nel costruttore stesso quando l'oggetto azione viene istanziato index.php
. Imposta il file
, classe
e metodo
proprietà, che saranno utilizzate nel eseguire
metodo. Per mantenere le cose meno complicate, discuteremo solo del eseguire
metodo, anche se raccomanderei di passare attraverso il costruttore di Azione
classe.
Di nuovo al nostro eseguire
metodo del Azione
classe, controlla la presenza del file ($ This-> file
) associato al percorso corrente. Se tutto va bene, include quel file e chiama il metodo corrispondente ($ This-> metodo
) di quella classe controller usando il call_user_func
funzione e restituisce la risposta.
Se il file associato non è disponibile, verrà restituito falso
. Ora torniamo allo snippet dal eseguire
metodo della classe Front controller. Sii paziente, siamo quasi arrivati!
... $ result = $ action-> execute ($ this-> registry); if (is_object ($ result)) $ action = $ result; elseif ($ result === false) $ action = $ this-> error; $ this-> error = "; else $ action = false; return $ action; ...
Una volta eseguito il metodo di esecuzione di Azione
la classe completa il processo, restituisce il risultato ed è assegnato al $ result
variabile. Ora, ci sono tre diverse possibilità con il valore memorizzato in $ result
. Esaminiamo ognuno di essi.
Se tutto è andato bene, avremo l'output HTML nel $ result
variabile, quindi il $ azione
la variabile è impostata su falso
e il processo finisce. È l'ultimo caso.
Ricordiamo che siamo tornati falso
se il file del controller corrispondente non è stato trovato nel eseguire
metodo del Azione
classe. In tal caso, il $ azione
la variabile sarà impostata su $ This-> errore
(errore non trovato Azione
) e la "pagina non trovata" verrà mostrata all'utente.
E infine, se troviamo che il $ result
è un oggetto stesso, lo imposteremo su $ azione
variabile. Sì, è strano: perché mai il metodo del controller restituirà un altro Azione
oggetto, quando deve restituire l'output HTML per la pagina richiesta? Ma questo è solo uno dei modi in cui il controller reindirizza gli utenti a qualche altro URL.
Apriamo rapidamente il Catalogo / regolatore / common / maintenance.php
file e vederlo in azione. Nel indice
metodo, restituisce il Azione
oggetto se determinate condizioni sono vere.
... if (($ route! = 'Payment' && $ route! = 'Api') &&! $ This-> user-> isLogged ()) return new Action ('common / maintenance / info'); ...
Quindi, come puoi vedere, restituisce il Azione
oggetto di reindirizzare l'utente al comune / manutenzione / info
URL. Certo, c'è un codice nel spedizione
metodo della classe front controller per gestire questo comportamento. Ricorda lo snippet di quel metodo: ti prometto che è l'ultimo frammento di questo tutorial.
... while ($ action) $ action = $ this-> execute ($ action); ...
Quindi è un ciclo while, e funziona fino a quando non trova il $ azione
variabile impostata su falso
! Più specificamente, finirà il ciclo quando avremo un output utile per il nostro utente.
Quindi questa è la fine del viaggio. Spero che non sia così complicato come sembrava a prima vista.
Oggi abbiamo affrontato un aspetto importante del framework OpenCart: il processo di dispacciamento. Abbiamo capito le basi del dispacciamento e abbiamo attraversato il flusso completo per capire come funziona.
Se stai cercando altri strumenti, utility, estensioni e così via che puoi sfruttare nei tuoi progetti o per la tua istruzione, non dimenticare di vedere ciò che abbiamo a disposizione sul mercato.
Per qualsiasi domanda, non esitate a lasciare i vostri commenti. Inoltre, Twitter è un'altra opzione per contattarmi e io rispondo rapidamente.