Vi consigliamo di iniziare a testare i vecchi progetti con questa versione in quanto le migliorie iniziano veramente a farsi interessanti.

Questo significa che per portare le nostre applicazioni a symfony 1.3 dovremo controllare di non includere nessun helper derivante dalla vecchia gestione dei form o che utilizzi sfProtoculousPlugin.

Non solo. Sono stati rimossi i task project:freeze e project:unfreeze in quanto dalle ultime specifiche il path di symfony sarà impostato direttamente all’interno della classe ProjectConfiguration definita in config/ProjectConfiguration.class.php. Mi raccomando, seguite le linee guida che suggeriscono di inserire i sorgenti di symfony in lib/vendor/symfony/ poi al massimo userete dei symlink per questa directory.

Mancano ancora 3-4 mesi al rilascio di questa versione di symfony, ma vi consiglio fin da ora di dare un occhio al vostro progetto al fine di migrare il più facilmente possibile quando sarà pronta.

Come aggiornare dalla precedente 1.1 o addirittura dalla ormai veneranda 1.0?

Innanzitutto i riferimenti alla documentazione ufficiale, che non guastano mai:

http://www.symfony-project.org/installation/1_2/upgrade

Ricordiamo che non si può fare il salto dalla 1.0 alla 1.2 senza passare dal via... ops volevo dire dalla 1.1

È utile quindi anche questa pagina:

http://www.symfony-project.org/installation/1_1/upgrade

Se ci si trova nella situazione ottimale di essere già alla 1.1 e di non aver implementato parti di Model troppo complesse (a livello di Propel, intendo), è sufficiente aggiornare le librerie usando la modalità preferita (via PEAR, riscaricando la sandbox o uppando il subversion) e quindi lanciare

Sarà però necessario aggiornare i file di configurazione propel.ini e databases.yml. Il modo più rapido è quello di creare un nuovo progetto, inserire i corretti parametri di accesso (nome del database, credenziali di accesso) e quindi copiare tali file nel progetto esistente. Ovviamente sarà necessario ricostruire il Model e pulire la cache, ma questo ormai dovrebbe essere il nostro pane quotidian:

Se eravate impazienti di provare Propel 1.3 con la precedente versione di symfony e quindi avete usato finora l'ottimo sfPropelPlugin, non avete nemmeno bisogno di cambiare nulla e potete tranquillamente rimuovere il plugin. Per scrupolo, però, meglio fare come sopra e creare un nuovo progetto, per verificare che tutte le impostazioni di Propel coincidano.

Il passaggio dalla 1.0 potrebbe non essere così semplice. Non è ancora chiaro se il plugin che garantisce la retrocompatibilità sia ancora utilizzabile, perlomeno io non sono riuscito (ancora) a far funzionare delle vecche form. Il mio consiglio è di aggiornare intanto alla 1.1, che comunque ha introdotto a sua volta diverse interessanti novità, e di aspettare ancora un poco.

Particolare attenzione è stata riservata al sub-framework di gestione dei form, risolvendo molti problemi riguardanti Validator e Widget. Sono stati corretti anche alcuni bug riguardanti la sandbox (che ora è aggiornata a questa release).

Il blog ufficiale del progetto riporta un sommario con le modifiche più importanti mentre l'elenco completo è consultabile qui.

Se usate PEAR l'upgrade è come al solito molto semplice:

La "Dependency Injection" si ha quando i componenti ricevono le proprie dipendenze dai loro costruttori, metodi o direttamente dai loro attributi.

Al symfony camp, ho assistito alla presentazione della versione 2.0 di symfony, fatta da Fabien, e sono rimasto veramente impressionato.

• Symfony 2.0 sarà un evoluzione di symfony 1.0 non una rivoluzione;
• Molte modifiche fatte nella release 1.1 e 1.2 sono state fatte per supportare la release 2.0;
• Il disaccoppiamento delle classi fatto nella 1.1 è stato fatto per supportare symfony 2.0;
• Ci sarà sicuramente un symfony 1.3;
• La maggior parte dei componenti già scritti resteranno tali;

Ma le vere novità saranno:

• Un "Dependency injection container" che implementa il patter della "Dependecy Injection" per risolvere la dipendenza tra le classi, poter caricare solo i componenti che si vogliono usare, descrivere la relazione tra i componenti, testarli in maniera più semplice ed efficente e riusarli con molta più semplicità.
• La creazione di un template layer, per separare veramente la parte di presentazione e poter utilizzare il template engine più consono alle singole esigenze.
• La creazione di un controller layer sotto forma di servizio.

Nello specifico sono stati corretti problemi riguardanti Propel, la gestione del caching dei moduli e l'overriding dei plugin.

E proprio per questi è nata anche la nuova directory dei plugins, dove è possibile filtrare plugin per compatibilità, requisiti e poter collaborare meglio allo sviluppo degli stessi. Più o meno come avviene su Launchpad di Canonical.

Tra le principali novità del framework:

• La nuova, più flessibile e leggera, architettura di Symfony 1.1
• Un parser YAML con supporto al report degli errori
• Propel 1.2 come plugin e non più come componente del core
• Il sotto-framework delle form e quello della validazione
• Il sistema per gestire diversi formati per la stessa applicazione
• ... ed oltre 8,500 unit and functional tests!

Per installare la nuova versione di Symfony il comando da pear è

Ho deciso quindi che ne parlerò in post dedicati cercando di dare un qualche spazio di approfondimento a quelle che a mio parere sono delle novità veramente interessanti.

Per ora mi limiterò ad una piccola premessa su come il team di sviluppo ha deciso di operare per le prossime versioni di Symfony in modo da chiarire alcuni dubbi su compatibilità, orm e quant'altro.

Innanzitutto Fabien ha spiegato che le release di Symfony seguono uno schema ben preciso:
php 5.x => Symfony 1.x

Quindi Symfony 1.1 necessiterà di php 5.1 per poter funzionare, allo stesso modo Symfony 1.2 necessiterà di php 5.2 e così via.

Perchè è importante questa precisazione? Perchè questo comporterà in Symfony 1.1 l'abbandono (diciamo più messa da parte) di Propel a favore di Doctrine. Infatti la nuova versione di Propel attualmente è dipendente da php 5.2, e va contro le specifiche del framework.

Inoltre come potete vedere dall'immagine qui a fianco (e da quella che la segue) la gestione delle dipendenze del framework è stata interamente rivista. Questo ha permesso di scrivere il famoso sotto-framework di validazione, di cui parlemo in futuro, e di dare accesso ai metodi principali direttamente da tutte le parti del codice, senza contare un buon incremento delle performance. Inoltre è stato implementato una gestione di scambio dei messaggi (tra una classe e l'altra) più semplice ed efficace.

Nella maggior parte dei casi non ci sarà comunque da riscrivere la propria applicazione, ma basterà aggiornare alcuni criteri di selezione/query usati.