Come abbiamo già visto nel capitolo precedente, la struttura di default di un progetto Laravel è questa:
.app-prova ├── .editorconfig ├── .env ├── .env.example ├── .gitattributes ├── .gitignore ├── app ├── artisan ├── bootstrap ├── composer.json ├── composer.lock ├── config ├── database ├── lang ├── package.json ├── phpunit.xml ├── public ├── README.md ├── resources ├── routes ├── storage ├── tests ├── vendor └── vite.config.js
Viene intesa come punto di partenza di qualsiasi progetto, ma siamo liberi di aggiungere tutte le directory che reputiamo necessarie al nostro progetto e aggiungere file PHP in ogni posizione. Per sfruttare i meccanismi di autoloading di composer, il mio consiglio è quindi quello di rispettare la struttura originale ed aggiungere le directory necessarie.
app
La directory che ci interessa maggiormente è quella app
, dove scriveremo il codice del nostro progetto. Al suo interno, troveremo le directory Console
, Exceptions
, Http
, Models
e Providers
. Teniamo presente che molte altre directory verranno create automaticamente dal comando Artisan una volta che aggiungeremo più funzioni/strutture al nostro progetto, ma è in questa directory che lavoreremo maggiormente.
config
Come suggerisce il suo nome, la directory config contiene i file di configurazione, che approfondiremo più avanti in questa guida. Dato che quasi tutti i file presenti di default “dichiarano qualcosa” e non eseguono comandi, una buona idea è quella di dare una rapida occhiata per scoprire i vari setting che possiamo liberamente impostare.
database
Questa directory è fondamentale e, come approfondiremo in seguito, conterrà le Migrations, ovvero i “cambi di struttura” al nostro database, i Seed e altro. È importante capire che l’impostazione di collegamento al database NON viene effettuata qui.
public
La directory public
è fondamentale quanto quella app, perché conterrà tutti i file che saranno accessibili pubblicamente dal nostro sito/dominio, come i file CSS e Javascript. Qui inoltre troviamo il file index.php
(da non toccare) verso il quale vengono reindirizzate tutte le richieste HTTP del nostro progetto. Sarà lui poi a inizializzare il framework e a “smistare le richieste” tramite le routes, che vedremo fra poco.
resources
Laravel include un template engine, Blade, a cui dedicheremo un capitolo a parte. Per il momento ci serve sapere che nella directory resources
i file di questo template, ovvero le view, vengono conservate qui, nella sottodirectory views
.
routes
Probabilmente la directory routes
è la seconda per importanza dopo app
, ed è la prima nella quale lavoreremo in questa guida. Le routes sono appunto le “rotte” del nostro sito: corrispondono alla gestione delle richieste che avvengono quando un utente chiama un URL del nostro progetto. Dovremmo, ad esempio, essere pronti a rispondere alla route /user/1 (ovvero https://nostrodominio.com/user/1) definendola qui. Per farlo, Laravel predispone 4 tipi di routes, che sono intercambiabili fra di loro, in quattro file separati a seconda “dello scopo”: in api.php definiremo le routes per i nostri endpoint API, se il nostro progetto naturalmente ne ha. In web.php saranno definite
La definizione delle route non cambia, “si scrive uguale”, quindi la differenziazione è soltanto logica.
Vedremo più avanti, nei casi specifici, le altre directory, solo nel momento in cui saranno rilevanti ai fini della nostra guida.