My short presentation at Symfony Live 2008 unconference, about translating Symfony docs (notice: this is a repost, since Slideshare deleted original one and has not be able to recover it. Shame on you, Slideshare!)
la mia presentazione all'incontro di novembre 2013 del PUG Roma, su come gestire le librerie di frontend (tipicamente css e javascript) in un progetto PHP, con alcune considerazioni finali specifiche per Symfony2
2. Il problema della gestione delle dipendenze affligge da tempo qualsiasi sviluppatore che non voglia reinventare la ruota. Questo problema può essere affrontato da due punti di vista: quello dello sviluppatore che ha bisogno di usare una libreria e quello dello sviluppatore che ha creato la propria libreria e vuole distribuirla
3. Una prima possibile soluzione al problema è: scaricare i sorgenti della libreria e installarli a mano. Questa soluzione ovviamente è molto scomoda e ha molti difetti: difficoltà di manutenzione, difficoltà di replicazione, difficoltà o impossibilità di versionamento. È stata mostrata solo per motivi "storici"
4. PEAR è stato per molto tempo lo standard de facto per la gestione delle librerie. Il suo problema principale era nella necessità di dover installare le librerie a livello di sistema, mentre spesso è necessario gestire versioni diverse su progetti diversi. Un altro problema è che è rimasto poco sviluppato e ancorato alla compatibilità con PHP4
5. Un altra possibile soluzione è la gestione delle dipendenze nel sistema di versioanmento: externals per subversion, submoduli per git, eccetera. Difetti di questo approccio: lo sviluppatore di librerie dovrebbe tenere un repository per ogni sistema, l'utilizzatore è costretto a gestire in contemporanea aggiornamenti delle revisioni del suo progetto e aggiornamenti delle librerie
6. Un approccio più recente e interessante è stato quello adottato da Symfony 2.0, cioè uno script di gestione scritto ad hoc. Purtroppo non era in grado di gestire le dipendenze indirette ed era legato strettamente a git
8. Il primo passo per usare Composer è installarlo. La procedura è molto semplice, trattandosi di uno script PHP da linea di comando: basta scaricare l'installer ed eseguirlo. Non obbligatorio, ma consigliato, spostare l'eseguibile sotto a un percorso incluso in $PATH. Pper sistemi non Unix-compatibili... non lo so! Arrangiatevi
9. L'installazione delle librerie è facile: basta eseguire il comando seguito dal parametro "install". Occorre però preparare un file di configurazione
10. Questo esempio di file di configurazione di Composer è tratto da Symfony Standard Edition, con alcune righe tagliate per questioni di spazio.
11. Vediamo ora un esempio su come pubblicare la propria libreria, tratta da un caso reale; un bundle per Symfony2 creato sotto PUGX. Il primo passo è quello di pubblicare il progetto su github
12. Questo è il file composer.json del bundle, con le sue dipendenze e le impostazioni per l'autoloading
13. Il passo successivo consiste nel pubblicare la libreria su Packagist, configurando le impostazioni relative all'integrazione con github
14. Tutto qui! Come direbbe il Principe, è fatta! Non serve niente di più di questo, è molto facile e consente di gestire dipendenze a cascata.
15. Ma se io avessi l'esigenza di usare una libreria che non è open source e quindi non posso mettere su github? Si possono impostare altri reposi
My short presentation at Symfony Live 2008 unconference, about translating Symfony docs (notice: this is a repost, since Slideshare deleted original one and has not be able to recover it. Shame on you, Slideshare!)
la mia presentazione all'incontro di novembre 2013 del PUG Roma, su come gestire le librerie di frontend (tipicamente css e javascript) in un progetto PHP, con alcune considerazioni finali specifiche per Symfony2
2. Il problema della gestione delle dipendenze affligge da tempo qualsiasi sviluppatore che non voglia reinventare la ruota. Questo problema può essere affrontato da due punti di vista: quello dello sviluppatore che ha bisogno di usare una libreria e quello dello sviluppatore che ha creato la propria libreria e vuole distribuirla
3. Una prima possibile soluzione al problema è: scaricare i sorgenti della libreria e installarli a mano. Questa soluzione ovviamente è molto scomoda e ha molti difetti: difficoltà di manutenzione, difficoltà di replicazione, difficoltà o impossibilità di versionamento. È stata mostrata solo per motivi "storici"
4. PEAR è stato per molto tempo lo standard de facto per la gestione delle librerie. Il suo problema principale era nella necessità di dover installare le librerie a livello di sistema, mentre spesso è necessario gestire versioni diverse su progetti diversi. Un altro problema è che è rimasto poco sviluppato e ancorato alla compatibilità con PHP4
5. Un altra possibile soluzione è la gestione delle dipendenze nel sistema di versioanmento: externals per subversion, submoduli per git, eccetera. Difetti di questo approccio: lo sviluppatore di librerie dovrebbe tenere un repository per ogni sistema, l'utilizzatore è costretto a gestire in contemporanea aggiornamenti delle revisioni del suo progetto e aggiornamenti delle librerie
6. Un approccio più recente e interessante è stato quello adottato da Symfony 2.0, cioè uno script di gestione scritto ad hoc. Purtroppo non era in grado di gestire le dipendenze indirette ed era legato strettamente a git
8. Il primo passo per usare Composer è installarlo. La procedura è molto semplice, trattandosi di uno script PHP da linea di comando: basta scaricare l'installer ed eseguirlo. Non obbligatorio, ma consigliato, spostare l'eseguibile sotto a un percorso incluso in $PATH. Pper sistemi non Unix-compatibili... non lo so! Arrangiatevi
9. L'installazione delle librerie è facile: basta eseguire il comando seguito dal parametro "install". Occorre però preparare un file di configurazione
10. Questo esempio di file di configurazione di Composer è tratto da Symfony Standard Edition, con alcune righe tagliate per questioni di spazio.
11. Vediamo ora un esempio su come pubblicare la propria libreria, tratta da un caso reale; un bundle per Symfony2 creato sotto PUGX. Il primo passo è quello di pubblicare il progetto su github
12. Questo è il file composer.json del bundle, con le sue dipendenze e le impostazioni per l'autoloading
13. Il passo successivo consiste nel pubblicare la libreria su Packagist, configurando le impostazioni relative all'integrazione con github
14. Tutto qui! Come direbbe il Principe, è fatta! Non serve niente di più di questo, è molto facile e consente di gestire dipendenze a cascata.
15. Ma se io avessi l'esigenza di usare una libreria che non è open source e quindi non posso mettere su github? Si possono impostare altri reposi
10. FOSUserBundle
● entity User con alcune proprietà
● form registrazione e profilo
● forgot password
● command per aggiungere/promuovere utenti
● autenticazione (con remember me)
● form login e user provider
● impersonate
● permessi e liste di accessi
11. FOSUserBundle (davvero!)
● entity User con alcune proprietà
● form registrazione e profilo
● forgot password
● command per aggiungere/promuovere utenti
● autenticazione (con remember me)
● form login e user provider
● impersonate
● permessi e liste di accessi
22. Codice
Nota: questa slide non era presente nella presentazione originale.
Visto però il feedback ricevuto su https://joind.in/talk/e1ad4 , ho voluto integrare con del codice, in modo
da dare la possibilità a tutti di avere un riscontro più pratico, che putroppo è mancato durante la
conferenza.
https://github.com/garak/progetto_senza_fosub