Symfony 4: Compose your Applications

Nota: Symfony 4 sarà pubblicato a novembre nel 2017. Questo è il primo articolo di una serie dedicata a spiegare le novità che saranno introdotte un Symfony 4.

Symfony 3.0 è stata la versione più noiosa della storia di symfony, perché era semplicemente una versione "pulita" di Symfony 2.8:

Symfony 3.0 = Symfony 2.8 - funzionalità obsolete.

Symfony 4.0, che richiede anche PHP 7.0, come minimo, sarà molto diversa:

Symfony 4.0 = Symfony 3.4 - funzionalità obsolete + una nuova forma di sviluppare applicazioni.

Inoltre, mentre pensavo cosa cambiare in Symfony 4, ho pensato che avremmo potuto cambiare per migliorare lo sviluppo giornaliero di Symfony. Il resto dell’articolo spiega tutti questi miglioramenti.

Installare bundles non è il massimo

Il modo migliore per aggiungere nuove funzionalità in Symfony è installare bundles e librerie con Composer.

Di fatto, Composer è emerso da un dibattito su come installare i pacchetti, i plugin, estensioni, ecc in Symfony e phpBB.

La cosa strana è che né phpBB né Symfony utilizzano Composer per installare i loro pacchetti, plugins, estensioni, ecc

Quando si installa un pacchetto di Symfony, non è sufficiente eseguire un comando Composer. Per poterlo utilizzare, è necessario attivare e configurare il pacchetto. Questi sono i passi che di solito seguono:

— eseguire a mano “composer require symfony/bundle” per scegliere esattamente il pacchetto che si desidera installare. Tuttavia, se siamo nel contesto di un’applicazione Symfony, dovrebbe essere molto più facile da installare nuove funzionalità. Ad esempio: perché non eseguire “composer req mailer” per installare un mailer o composer req admin per nstallare un generatore di admin?
— registrare il bundle nella classe AppKernel.
— opzionalmente, registrare le routes del bundle.
— configurare il bundle (come minimo aggiungere la configurazione iniziale per attivarlo).
Il primo passo non può essere automatizzato, ma per quanto riguarda il resto? Ad esempio, la configurazione non può essere completamente automatizzata, ma sarebbe possibile definire una configurazione iniziale per il bundle.

Disinstallare un bundle è puntroppo un’attività complessa.

Nelle applicazioni Symfony che evolvono con il tempo, è normale elimnare i bundles che non si utilizzano più. In teoria sarebbe sufficiente utilizzare il comando “composer remove symfony/bundle”.

Ma non è abbastanza.

Per disinstallare un bundle si devono eseguire tutti i passi fatti per installarlo: eliminarlo dalla class AppKernel, elimanre le routes, elimnare la configurazione, etc. Siccome si toccano diversi files, eliminare un bundle non è solo difficile ma può provocare anche errori.

La versione “Symfony Standard” non è sufficinete.

Le “distribuzioni Symfony” sono state un modo per minimizzare questi problemi attraverso applicazioni Symfony pronte all’uso.

La distribuzioni più popolare è la “Symfony Standard Edition”, che è stata pensata per facilitare lo sviluppo tradizioni di applicazioni web, nelle quali si utilizzano data base, templates, mail, etc. Senza dubbio, è necessario chiedersi se questa forma “tradizionale” di creare applicazioni web è ancora valida. Per esempio, se vorresti sviluppare un’applicazione tipo microframework? o se si sviluppa un sernizio web o API?

La distribuzione “Symfony Standard Edition” prende decisioni al posto del programmatore, ma sono scelte sempre o troppe o troppo poche. Quindi le distribuzioni Symfony non sono una buona idea nella realtà, in quanto non facilitano il processo di aggiunta o eliminazione di funzionalità.

Un altro problema è che le distribuzioni includono i file che non sono necessari come i file README e le licenze. La maggior parte dei progetti che si sviluppano sul posto di lavoro non utilizzano una licenza open source, quindi perché includono questo file?. Stessa cosa con il file composer.json: è necessario cambiare la maggior parte del suo contenuto per soddisfare il progetto.

Si possono eliminare facilmente uno o due files, ma il problema è che presto dovrai eliminare più cose.

Ad esempio, alcuni anni fa, il “Symfony Standard Edition” comprendeva un piccolo bundle di test (il famoso AcmeDemoBundle). Dal momento che non era facile eliminare completamente questo pacchetto, abbiamo dovuto smettere di includerlo. E questa decisione è stato tanto buona come cattiva. Il “Symfony Standard Edition” è peggiorato perché i programmatori non hanno più avuto un esempio da cui imparare. Ma nello stesso tempo è migliorato, in quanto gli stessi programmatori non hanno dovuto perdere tempo per cancellare il pacchetto di prova.

Non ti ha convinto questa spiegazione? Bene, butta un occhio al file README della distribuzione REST:

Dove sono tutte le altre distribuzioni di Symfony?

Probabilmente a causa di quanto sopra, l’idea di distribuzioni Symfony non è mai dientata popolare. A parte la “Standard Edition”, non c’è una singola distribuzione Symfony che è popolare. Infatti, in symfony.com ce ne sono solo tre di distribuzioni.

Le distribuzioni non sono abbastanza flessibili. Non è possibile cambiarle da una all’altra. Inoltre, è necessario utilizzarne tutte le caratteristiche o nessuna e non si possono evolvere.

Le distribuzioni Symfony sono un’astrazione sbagliata. Non c’è bisogno di un’applicazione complessa già pronta all’uso. Quello che serve è un meccanismo semplice perchè un’applicazione possa crescere.

L’esperienza di utilizzo ideale

Come i programmatori, vogliamo iniziare nel modo più semplice possibile, con poche dipendenze. Ma vogliamo anche far crescere le nostre applicazioni in modo semplice ogni volta che ne abbiamo bisogno. Qualcosa come iniziare con un micro-framework da far crescere, se vogliamo, fino a un monolite gigante. Il framework che si utilizza (in questo caso, Symfony) non dovrebbe ostacolare questa crescita.

In definitiva, creare un progetto Symfony da zero o far crescere un progetto è abbastanza difficile per coloro che stanno iniziando e abbastanza pesante per coloro che sono esperti. Possiamo farlo meglio.

Meglio “composizione” che “ereditarietà”

Se ci si ferma a pensare, le distribuzioni Symfony utilizzano l’equivalente dell’esreditarietà del codice. La maggior parte di loro sono fork di Symfony Standard Edition a cui sono state aggiunti più bundles. Che cosa succederebbe se utilizzassimo la “composizione” invece dell’”ereditarietà”? Per esempio, io voglio usare una distribuzione REST, ma combinarla con la distribuzione dell’admin generator. O meglio ancora, che cosa succede se ci si dimentica le distribuzioni Symfony per sempre?

Quì è dove entra Symfony Flex, una nuova forma di creare applicazioni Symfony e farle crescere.

Symfony Flex permette di creare applicazioni Symfony molto facilmente, tanto se è un micro applicazione come se è una mega applicazione con dozzine di dipendenze. Inoltre, installa e disinstalla bundles automaticamente. Aggiunge anche una configurazione di default per i bundles. Infine ti permette di scoprire i migliori bundles.

Symfony Flex è lo strumento predefinito per gestire le applicazioni Symfony 4. Ma se si vuole, Symfony Flex è utilizzabile per gestire applicazioni Symfony 3.3 e 3.4. In ogni caso, si noti che Symfony Flex è ancora in alfa , quindi il suo funzionamento può variare leggermente da qui a Symfony 4.

Nel prossimo articolo di questa serie, vi racconterò di più su Symfony Flex. Nel frattempo, potete dare un’occhiata alla nuova struttura delle applicazioni Symfony create con Symfony Flex. Forse non ti aspettavi che la struttura predefinita era completamente vuota, giusto?

Questo articolo è la traduzione dell’articolo “Symfony 4: Compose your Applications” pubblicato da Fabien Potencier