Symfony è un framework che mette a disposizione un set di tools, cioè di componenti. Il motivo che ci porta ad utilizzare un framework è il non dover reinventare la ruota, Symfony mette a disposizione dei bundles quindi dei casi già risolti.
Contents
Cartelle di Symfony
La cartella app
Andiamo ad analizzare le diverse cartelle di Symfony, la prima che ci troviamo davanti è app al suo interno ha config e resources.
La cartella config
Andiamo a vedere prima la cartella config, in config.yml abbiamo le opzioni che consentono il correto funzionamento dell’applicativo, possiamo ad esempio decidere quale template engines utilizzare se twig o php oppure entrambi.
Importa al suo interno altre configurazioni yml: parameters, security e service.
La versione dev e quella prod importano questa configurazione base presente in config.yml. Il config_dev è l’ambiente di sviluppo, qui possiamo abilitare tutte le funzioni che ci aiutano a livello di debug, ad esempio la toolbar, config_prod è invece la configurazione caricata in produzione.
I due file parameters definiscono delle opzioni come i dati per connettersi al dabase. il .dist serve per comunicare tra vari sviluppatori quali siano i settaggi obbligatori per il funzionamento dell’applicazione. Naturalmente se usiamo git parameters.yml andrà nel gitignore perchè ogni sviluppatore avrà una sua configurazione diversa in locale.
Poi abbiamo routing.yml e il .dev, queste due immagazzinano le rotte. Se apriamo routing.yml vediamo che di default le rotte sono di tipo annotation, quindi sono dichiarate direttamente nel controller sopra il metodo. Il dev chiaramente ci consente di avere delle rotte che siano raggiungibili solamente in fase di sviluppo.
Procedendo oltre vediamo security.yml che serve per gestire alcune pagine dietro autenticazione. Mentre services.yml sono dei servizi che saranno disponibili per tutta l’applicazione.
La cartella Resources
Qui ci sono le wiews di default saranno in formato twig, queste sono le viste. Noteremo che si sono due pagine una base.html.twig che fa da base per tutti i template, e l’altra che è quella che vediamo in homepage che è index.html.twig, questa eredita la prima.
Poi troviamo al di fuori delle cartelle AppCache.php che serve per mettere un proxy tra il client e il server. AppKernel.php ha al suo interno tutti i bundle che servono per il corretto funzionamento dell’applicazione o i bundle che andiamo ad installare. Nella funzione registerBundles ci sono tutti i bundle che vengono caricati dall’applicativo.
C’è anche la distinzione tra l’ambiente dev e quello di produzione, ci sono una serie di bundle che verranno caricati solo nel caso di ambiente dev.
L’ultimo file della cartella App è autoload.php ed è l’autoloading di Composer.
La cartella bin
Solo due file troviamo qui dentro, iniziamo con symfony_requirements, ci dà delle informazioni sull’ambiente di symfony e sulla correttezza dell’installazione.
Il secondo file, console, invece è quello che si userà spessissimo, soprattutto nei nostri comandi dal terminale. Il suo obiettivo è convertire gli input da console in output, se vogliamo una lista completa dei comandi che si possono dare da console possiamo digitare “php bin/console list“, i comandi possono anche essere creati custom.
La cartella src e test
La cartella su cui certamente passeremo più tempo è src, contiene già un buncle di default, al suo interno ha la minima configurazione di un bundle che è quella in cui c’è un controller e poi AppBundle.php che è il file base del bundle Nella cartella test vengono replicati i controlli di src, per lanciare questi test il comando da console è phpunit.
La cartella var
Al suo interno troviamo la chache i log i file si sessione.
All’interno di cache possiamo vedere la cache divisa innanzitutto tra i vari ambienti e poi se andiamo al loro interno quella dei vari componenti.
Nella cartella logs troviamo i vari log che scrive la nostra applicazione, anche queste divise per ambiente.
Bootstrap.php.cache è un file molto utile perchè al suo interno troviamo in cache alcune delle librerie base di symfony in modo da non doverle ricaricare ogni volta da zero.
La cartella vendor e web
Qui ci sono tutte le librerie di terze parti, quando andremo ad installare un bundle esterno il bundle sarà installato all’interno di questa cartella.
Web è invece la cartella pubblica, qui ci troveremo tutti i file pubblici, qui abbiamo app e app_dev, qui c’è la base, il punto di partenza dell’applicazione. In entrambe le pagine php viene attivato prima di tutto l’autoloader e poi nella app_dev viene abilitato il debug. Poi in entrambi i file viene chiamato il kernel, caricate le classi dalla cache. Viene a questo punto creato l’oggetto request che ingloba tutte le variabili globali di PHP. Viene a questo punto chiamata la funzione handle, qui c’è il meccanismo per trasformare una richiesta in una risposta, e poi con send() mandiamo fuori la risposta
Altri file
Nella root del progetto possiamo vedere composer.json e composer.lock che servono per fare l’update di alcune librerie o installare alcune librerie dopo la clonazione di un progetto, composer.json viene chiamato quando da terminale digitiamo “composer update”, mentre composer.lock viene chiamato quando digitiamo “composer install”. In phpunit.xml.dist ci sono le configurazione dei phpunit