Share
I framework sono argomenti caldi nel settore del web e lo sono già da tempo. In questo vasto mare di sapori è Symfony - un ampio framework PHP che segue il paradigma MVC sempre più popolare. La sua curva di apprendimento è probabilmente un po 'più ripida rispetto ai suoi concorrenti concorrenti, come CodeIgniter. Non ti preoccupare, una volta cresciuto su di te, ti sentirai più potente che mai e sarai in grado di sviluppare fantastiche applicazioni.
In questo articolo dovrai usare un programma di console. Personalmente mi piace Git Bash, ma nessuno lo farà. Dovrai inoltre installare Curl per installare Composer.
Se sei un utente di Windows, puoi ottenere tutto quanto incluso in bundle installando Git per Windows, che è disponibile qui: Git download.
Durante questo articolo imparerai di più su:
Prima di sporcarci le mani e grugnire, voglio usare un momento per spiegare il flusso del ciclo di vita di Symfony.
Come tutto il resto del web, tutto inizia con una richiesta. Questo viene raccolto da Symfony che lo abbinerà ai nostri percorsi definiti (non preoccuparti, questo verrà spiegato in seguito), che viene poi abbinato ai controller. Quindi diciamo a Symfony quali URL vogliamo abbinare a determinati controller e alle loro funzioni.
Qui è dove avviene la magia. Symfony analizzerà l'URL e lo abbinerà a uno dei nostri percorsi. Quindi caricherà il controller che abbiamo assegnato al percorso.
Il controller è caricato e una determinata azione viene eseguita in base al percorso.
Proprio come con una normale richiesta HTTP, una richiesta Symfony deve restituire un oggetto risposta.
L'oggetto risposta può essere formato in vari modi, ad esempio con intestazioni.
Un'azione deve restituire un oggetto risposta valido, altrimenti verrà generata un'eccezione.
Così ora hai avuto una breve introduzione ai meccanismi di Symfony: ora è il momento di tuffarsi.
Una delle cose belle dello sviluppo web oggi è gli strumenti disponibili per facilitare il processo. Uno di questi è Composer - un gestore di pacchetti per PHP. Questo articolo non includerà i dettagli dell'utilizzo di Composer, ma se sei interessato, questa è un'ottima introduzione: Easy Package Management con Composer
Prima di tutto, se non hai installato Compositore globalmente, puoi scaricare un'installazione locale eseguendo il seguente comando:
curl -s http://getcomposer.org/installer | php
Verifica che l'installazione abbia funzionato digitando:
php composer.phar
Se tutto è andato liscio, dovresti vedere un menu di comandi disponibili. In caso contrario, controlla di aver impostato PHP nelle variabili di ambiente.
Ora passeremo all'installazione di Symfony. Sostituire la tua cartella con qualsiasi nome di cartella desideri per il tuo progetto. Puoi anche sostituire la versione alla fine con uno qualsiasi di tua scelta. Consiglio di controllare Packagist: Symfony Framework Standard Edition per l'ultima versione stabile.
php composer.phar create-project symphony / framework-standard-edition your-folder / 2.1.4
Ora dovresti vedere Composer scaricare le dipendenze nella cartella. Se la tua installazione è andata bene, vai a your-project.local / web / config.php - qui Symfony ti parlerà dei requisiti del server che mancano o delle estensioni facoltative che potrebbero migliorare le prestazioni o facilitare lo sviluppo.
Quando hai abilitato le estensioni obbligatorie e facoltative, vai a /web/app_dev.php dove dovresti vedere una schermata di benvenuto con collegamenti per varie esperienze di apprendimento. Questo significa che Symfony è stato installato con successo - congratulazioni!
A prima vista, la cartella radice potrebbe sembrare un po 'confusa. Non preoccuparti, c'è una spiegazione logica dietro la struttura. La tua radice dovrebbe consistere in queste quattro cartelle e alcuni file. Puoi ignorare i file, dal momento che non sono importanti al momento.
app / src / vendor / web /
Qui è dove va la configurazione di alto livello del tuo progetto. Ad esempio, questa è la casa di AppKernel classe che carica tutto il codice e le librerie di terze parti nel framework per il tuo uso.
Il App la directory contiene anche tutti i principali file di configurazione, che contengono informazioni sull'accesso al database, i modelli di sicurezza, il routing e molto altro.
Il tuo layout HTML di base risiede anche qui.
Il src la directory è domestica per tutto il tuo codice, che è raggruppato in bundle.
Tutto il codice Symfony è raggruppato logicamente in ciò che è noto come bundle. Ad esempio, supponiamo che il tuo progetto abbia un sistema utente, quindi tutti i tuoi controller orientati all'utente, CSS, JavaScript, entità di database e così via saranno contenuti in un UserBundle. La cosa fantastica di questo sistema è che puoi prendere un pacchetto (ad esempio un pacchetto di gestione utenti) e collegarlo a qualsiasi progetto Symfony.
È anche possibile scaricare pacchetti pronte da siti Web come i pacchetti KNP. Tra le scelte più comuni ci sono bundle di sistemi utente e bundle di generatori di CRUD di amministrazione. Al momento della stesura di questo articolo, il sito ha 1779 bundle e 4068 sviluppatori.
Qui memorizzeremo tutte le librerie di terze parti. Questo è già pieno di librerie, ad esempio Symfony, Doctrine, Assetic e altre.
Questa dovrebbe essere la directory principale del tuo dominio perché questa è l'unica directory accessibile al pubblico del tuo progetto. Questa è la casa dei tuoi front controller app.php e app_dev.php file, che sono i due punti di accesso pubblici alla tua applicazione. Un utente inserirà il tuo sito tramite un URL come /app.php/products/jeans.
Accentsconagua
app_dev.php è il punto di ingresso principale durante lo sviluppo della tua app. Quando si utilizza questo come punto di ingresso, Symfony salterà la memorizzazione nella cache e fornirà una fantastica barra degli strumenti di sviluppo. app.php è il punto di ingresso per la modalità di produzione. Questo è in realtà reso opzionale attraverso mod_rewrite, quindi gli URL /app.php/products/jeans e / prodotti / jeans in realtà entrambi puntano alla stessa posizione. La console ha dimostrato di essere uno strumento geniale nel mio processo di sviluppo e quindi ti dico: non temerai la tua console, perché tu sei il creatore di tutte le cose.
Per me, una delle (meravigliose) stranezze sul passaggio a Symfony era il pesante uso della console.
Facciamoci un tuffo. Apri la tua console e individua la root del progetto. Inserisci questo comando:
app php / console
Questi sono i comandi a tua disposizione. Principalmente userete i generatori, la cache e la gestione delle risorse. Lo utilizzerai anche per generare pacchetti, generare schemi di database, eseguire il debug di percorsi, cancellare la cache e altro ancora.
Con alcune conoscenze di base sulla struttura e la console, sei pronto per immergerti in Symfony!
Vai a app_dev.php. La schermata di benvenuto che vedi qui è in realtà un pacchetto, come quello che creeremo in un minuto. Vai a src / ed elimina la directory Acme. Se aggiorni la pagina, vedrai un errore. Questo perché il AppKernel la classe sta provando a caricare il pacchetto che abbiamo appena cancellato. Ogni volta che aggiungi o rimuovi un pacchetto, dovrai modificare il file AppKernel classe.
Così aperto app / AppKernel.php. Vedrai un array in qualche modo come questo:
$ bundles = array (nuovo Symfony \ Bundle \ FrameworkBundle \ FrameworkBundle (), // ... Altri pacchetti qui);
Qui è dove inizializzerete i nuovi pacchetti. Se crei un pacchetto tramite la console, verrà aggiunto automaticamente.
Più in basso dovresti vedere un if-block come questo:
if (in_array ($ this-> getEnvironment (), array ('dev', 'test'))) $ bundles [] = new Acme \ DemoBundle \ AcmeDemoBundle (); // ... altri pacchetti qui Si tratta di pacchetti di sviluppo, ovvero bundle caricati solo quando ci si trova nell'ambiente di sviluppo (app_dev.php). Vedrai che è qui che il nostro bundle eliminato è inizializzato. Rimuovi il AcmeDemoBundle linea e salvare il file.
Se aggiorni, ora vedrai la pagina delle eccezioni di Symfony. È qui che tutte le eccezioni catturate ti reindirizzano e visualizzano più informazioni. Vedrai un'eccezione che va in questo modo:
Impossibile importare la risorsa "@ AcmeDemoBundle / Controller / SecuredController.php" ...
Questo perché Symfony cerca rotte definite nel file del controller SecuredController.php (che era in AcmeDemoBundle cancellato).
Ora è probabilmente un buon momento per spiegare un po 'di più sulle rotte. Fondamentalmente un percorso è un modello di URL. Immagina di avere un blog, con post, per categorie diverse. Quindi vorrai che l'utente inserisca un URL come questo:
www.myblog.com/categories/Category1 www.myblog.com/categories/Category2 e così via ...
In Symfony puoi definire i modelli di URL che abbini a un controller. Immagina il precedente esempio. Avresti bisogno di una funzione, a cui è stato dato il nome della categoria e ho cercato i post del blog che lo utilizzavano. In un'applicazione MVC, e quindi in Symfony, questa funzione è racchiusa in un controller. Quindi sarebbe fondamentalmente simile a questo:
class ControllerExample public function showCategory ($ category_name) // Estrarre i post del blog in base al nome della categoria e visualizzarli
Nota: questo non è un codice Symfony valido, ma solo un esempio di un semplice controller di blog.
Ora dovrai solo collegare l'azione del controller e l'URL. Questo è fatto da rotte. Il percorso in questo caso sarebbe simile a questo:
/ Categorie / nome
Quando una stringa è scritta in parentesi graffe, viene interpretata come una variabile, che viene quindi passata all'azione specificata. In Symfony puoi definire percorsi in XML, YML o annotazioni. Per semplificare, useremo solo annotazioni in questo tutorial.
Puoi vedere tutti i percorsi definiti usando il seguente comando nella console:
app php / router di console: debug
Ma ricorda, abbiamo avuto un errore. Questo perché Symfony sta ancora cercando i percorsi definiti nel nostro AcmeDemoBundle controller (che non esiste). Quindi apriti app / config / routing_dev.yml e per ora, tutto ciò che devi sapere è che tutti i percorsi sono definiti o importati routing.yml e routing_dev.yml. Elimina il _demo, _benvenuto e _demo_secured chiavi. Se aggiorni, ora vedrai Nessuna route trovata per "GET /". Questo perché non ci sono percorsi che corrispondono all'URL corrente, quindi facciamolo uno.
Quando si scrivono percorsi come annotazioni, li si scrive proprio sopra l'azione che si desidera eseguire quando un utente inserisce la rotta specificata. Pertanto, ciò di cui abbiamo bisogno ora è un pacchetto, che manterrà il nostro controller e azione.
Apri la tua console e inserisci il seguente comando:
l'app php / console genera: bundle
Innanzitutto, devi inserire lo spazio dei nomi del tuo pacchetto. Il modello generale per questo è:
Venditore / bundleName
Il venditore è l'autore del pacchetto. Qui puoi inserire il nome della tua azienda o quello che ti piace. Mi piace usare le mie iniziali EP. Usa quello che vuoi, ma mantienilo breve.
Il nome del pacchetto deve terminare con Bundle. Quindi inserirò quanto segue:
EP / BlogBundle
Successivamente, è possibile scegliere il nome che si desidera utilizzare quando si identifica il pacchetto nel codice.
Di solito ometto il nome del venditore, ma per il bene di questo tutorial, premi invio.
Ci sono più passaggi nel generatore, ma vorrai i valori predefiniti per questo tutorial, quindi premi invio fino a quando non sei passato.
Ora aperto src / YourVendorName / BlogBundle / nel tuo editor. Vedrai che è stata creata una struttura bundle di base per te. In questo momento salteremo i dettagli e andiamo dritti alla directory del controller. Aperto DefaultController.php in controller /.
Questo assomiglia molto all'esempio di base che ho scritto prima, tranne che il controller è un derivato di Controller - una classe dal bundle di framework Symfony, che contiene le funzionalità di base per un controller.
Se guardi l'azione, noterai alcune annotazioni che assomigliano a questo:
/ ** * @Route ("/ hello / nome") * @Template () * / Il @Itinerario l'annotazione dice a Symfony che vogliamo abbinare la rotta / Ciao / nome con l'azione \ EP \ BlogBundle \ Controller \ DefaultController :: indexAction () e che c'è una variabile chiamata nome nell'URL. Quindi, se qualcuno inserisce URL simili a questi:
www.myblog.com/hello/Esben www.myblog.com/hello/Santa www.myblog.com/hello/Jesus
... andranno tutti nello stesso posto, perché saranno tutti abbinati al / Ciao / nome itinerario.
Il @Modello l'annotazione dice a Symfony quale vista usare. Se lasciato vuoto, Symfony indovina quale vista utilizzare per la visualizzazione in base al nome del controller e al nome dell'azione.
L'osservante Padawan avrà notato ormai che non c'è un oggetto risposta restituito in questa azione, che ho sostenuto era un requisito in precedenza nell'articolo.
Una risposta è un oggetto che contiene il codice che si desidera visualizzare, i codici di servizio, le intestazioni, ecc. Ad esempio, se si desidera visualizzare una pagina "Hello World", si farà qualcosa del genere:
restituire una nuova risposta ("Hello World!", 200); Se volessi creare una pagina per una chiamata AJAX, potrebbe essere fatta in questo modo:
return new Response (json_encode (array ('some_variable' => 'some value')), 200, array ('content-type' => 'application / json')); Se vuoi reindirizzare l'utente, puoi farlo con a RedirectResponse oggetto.
Nota: È sempre possibile modificare la risposta in base alle proprie esigenze: codici di stato, intestazioni e altro. Niente è off limits.
Normalmente, se si desidera rendere una vista all'utente, si restituirà un nuovo oggetto risposta come questo:
return $ this-> container-> get ('templating') -> renderResponse ('EPBlogBundle: Default: index.html.twig', array ('name' => $ name)); Questa è una scorciatoia lunga che restituisce un oggetto risposta con un modello renderizzato come suo contenuto. Fortunatamente la classe del controller di base, da cui il nostro controller si estende, ha molte funzioni di scorciatoia. Possiamo usare il suo render () metodo per salvarci un po 'di tempo:
return $ this-> render ('EPBlogBundle: Default: index.html.twig', array ('name' => $ name)); Questa è solo una scorciatoia per il primo metodo che ho mostrato sopra. Il primo parametro è la vista da renderizzare. Tutti i nostri punti di vista sono all'interno del nostro pacchetto in Resources / views /. Le viste sono separate in directory basate sul controller responsabile della vista. Da qui la convenzione di denominazione Bundle: Controller: View.
La tua vista di layout di base (il modello principale della tua applicazione) è in app / Resources / views /. Poiché non si trova in alcuna directory di bundle o controller, viene semplicemente indicato come :: base.html.twig. Una vista nel tuo pacchetto, che è posizionata nella directory delle viste del pacchetto radice, viene indicata come Bundle :: View.
app / Resources / views / base.html.twig // :: base.html.twig src / BlogBundle / Resources / views / someView.html.twig // EPBlogBundle :: someView.html.twig src / BlogBundle / Resources / views /Default/index.html.twig // EPBlogBundle: impostazione predefinita: index.html.twig
E infine, il secondo parametro del nostro render () la funzione sono le variabili che vogliamo siano accessibili nella nostra vista.
Twig è un motore di template creato da Sensiolabs - i creatori di Symfony. Symfony viene fornito in bundle con Twig, anche se non è obbligatorio utilizzarlo.
Twig offre molte funzionalità interessanti che vanno oltre lo scopo di questo articolo, ma sentiti libero di dargli un'occhiata sul sito ufficiale di Twig.
Se ti apri EPBlogBundle: default: index.html.twig vedrai il codice che assomiglia a questo:
Ciao nome!
Twig utilizza e %% come tag di inizio e fine. Doppie parentesi graffe significano generare qualcosa, simile all'equivalente PHP di . Così nome significa emettere il valore della nostra variabile nome $ (che abbiamo detto a Symfony che volevamo usare quando abbiamo creato il nostro oggetto response).
Per darti un piccolo assaggio di Twig's awesomeness ti mostrerò alcuni filtri. Un filtro è una funzione che puoi applicare a una variabile. Viene applicato utilizzando questa sintassi var | filtro. Ecco alcuni esempi.
name | upper // restituisce la variabile in UPPERCASE name | length // restituisce la lunghezza della variabile name | url_encode // restituisce la versione codificata dell'URL della variabile
Puoi vedere un elenco completo di tag, filtri e funzioni nella documentazione ufficiale di Twig. Ciò che rende davvero Twig fantastico è che è davvero molto facile creare i propri filtri e funzioni. Ma dovrai aspettare un altro tutorial per maggiori informazioni su Twig e la sua estensibilità.
Questa è la fine del nostro magnifico viaggio - e che avventura!
Non solo abbiamo appreso la struttura di Symfony e dei bundle, ma anche la forza delle rotte e dei loro controllori. Cospargilo con un po 'di Twig e sei stato presentato a Symfony! Tornerò tra poco con tutorial più approfonditi su argomenti più specifici come la gestione patrimoniale con Assetic e la tempistica di Twig. Grazie per aver letto.
