La procedura descritta nel cookbook è assolutamente corretta, ma l’utilizzo del bundle VichUploaderBundle rende il tutto più efficace e risolve, abbastanza bene, anche un paio di problemi. Ecco la mia esperienza con questo bundle.

Quando mi sono trovato ad implementare il mio primo file upload sono partito, ovviamente, dalla documentazione. Seguendo il cookbook non ho avuto particolari problemi, ma qualcosa non mi ha convinto del tutto:

1. La mia entità avrebbe dovuto conoscere dettagli legati all’upload (il percorso di upload) che, secondo me, non sono tanto di sua competenza
2. Il codice per gestire l’upload, seppur semplice, era piuttosto verboso e ripeterlo per ogni entità legata ad un upload sarebbe stata operazione noiosa.

Ho sentito insomma la necessità di una soluzione migliore, più efficiente, per risolvere il problema. Cercando su KnpBundles ho trovato VichUploaderBundle.

Sostanzialmente il bundle si occupa di gestire il file  upload introducendo un set di annotazioni che permettono di definire il file come “Uploadabile” e di configurare quale proprietà dell’entità conterrà il file (e tutto il resto necessario a gestire l’upload). Il plugin si occupa anche di ascoltare gli eventi di doctrine per gestire caricamento e cancellazione dell’entità (e quindi in cascata dei file su file system). A completare l’opera alcuni helper per facilitare la vita nei template.

Tramite parametri di configurazione è inoltre possibile configurare destinazione dell’upload o, addirittura, il servizio utilizzato per la generazione del nome del file caricato.

Insomma un pacchetto veramente completo per la soluzione del problema upload.

L’installazione del bundle non presenta difficoltà e per i dettagli rimando alla documentazione ufficiale che è affidabile e completa.

Una delle cose che manca (almeno per il mio caso d’uso) è la possibilità di gestire l’upload su file system diversi da quello locale. Dato che spesso mi capita di lavorare con CDN questo è un punto debole. Fortunatamente il bundle sembra ben implementato e il salvataggio del file è delegato al componente:

Vich\UploaderBundle\Storage\FileSystemStorage

Che implementa l’interfaccia:

Vich\UploaderBundle\Storage\StorageInterface

Sono abbastanza sicuro che sia possibile integrare facilmente un (ad esempio) CDNStorage da poter usare in caso di upload su CDN. Questo ovviamente permetterebbe di legare l’upload di file a qualsiasi cosa, CDN e servizi di ogni tipo.

Non ho ancora avuto modo di verificare quanta fatica possa richiedere l’implementazione e l’integrazione di StorageInterface differenti ma spero di poterlo fare nei prossimi giorni.

In generale il bundle mi piace parecchio e penso che lo userò, da qui in avanti, per gestire i miei upload.

Mi piacerebbe anche leggere la tua opinione al riguardo, conosci qualche alternativa ? Hai già implementato qualcosa che potebbe essere integrato in questo bundle ?

Tre sono le cose che, se spostate in RAM, consentono un risparmio di tempo interessante:

• Database
• File di Log
• Cache

Di queste il database è probabilmente la cosa più importante. La vostra suite di test unitari non dovrebbe dipendere dal database, ma probabilmente quella funzionale lo farà. A meno che la vostra applicazione non abbia esigenze particolari probabilmente potete rimpiazzare il classico MySql con un sqlite per l’ambiente di test. Questa dovrebbe già essere la vostra situazione se siete abituati ad usare LiipFunctionalTestBundle. Sqlite prevede la possibilità di creare il database direttamente in memoria (usando :memory: come dsn) ma questo approccio introduce degli svantaggi (non è possibile mantenere il db tra processi diversi ad esempio). Utilizzando un normale db sqlite creato all’interno di un FS RAM si ottiene un db persistente (può essere utile per debug oppure ottimizzazioni particolari) ma in ram.

Metto nell’elenco delle cose che tipicamente mi piace spostare in RAM anche cache e log perché sono gli altri due componenti che richiedono maggiori accessi a disco e che, tipicamente, non mi interessa mantenere nel tempo. Sono quindi candidati ideali per finire in RAM, sollevando il mio disco da inutile lavoro.

Per creare un RAM Disk su OSX basta lanciare il comando:

diskutil erasevolume HFS+ "ramdisk" `hdiutil attach -nomount ram://1165430`

Che creerà una nuova partizione “ramdisk” disponibile in /Volumes.

Su macchine linux probabilmente la stessa cosa si può ottenere con un mount (non ho verificato questo comando):

mount -t tmpfs -o size=512M tmpfs /tmp/ram/

Per quanto riguarda sistemi windows invece non sono abbastanza ferrato da dare suggerimenti, ma sono pronto a scommettere che ci sia qualche utility disponibile per ottenere lo stesso risultato.

La quantità di spazio necessario dipende dalle vostre esigenze ma probabilmente qualche centinaio di MB saranno sufficienti.

Una volta creato il RAM Disk è necessario configurare Symfony per utilizzarlo per caching e logging. In Symfony2 la cosa è particolarmente semplice visto che il componente Kernel espone due parametri di configurazione proprio per questo, che basterà personalizzare (ad esempio nel parameters.ini):

• kernel.logs_dir
• kernel.cache_dir

In Symfony1 la stessa cosa dovrebbe essere fattibile modificando i parametri sf_cache_dir e sf_log_dir.

Il repository DoctrineExtensions prevede queste estensioni:

• Translatable
• Sluggable
• Timestampable
• Loggable
• Tree
• Sortable

I nomi sono piuttosto indicativi riguardo allo scopo di ognuna. Chi viene da symfony 1.x e doctrine 1.x ricorderà certamente una serie di plugin *ActAs* che avevano esattamente lo stesso scopo di queste estensioni.

Come detto, per utilizzare questi comportamenti in progetti symfony2, è possibile usufruire del bundle StofDoctrineExtensionsBundle che mette a disposizione listener e configurazioni varie per semplificare l’integrazione all’interno del progetto.

In questo momento il bundle non sembra gestire l’estensione Sortable ma non ho ancora verificato se si tratta di una carenza di documentazione o di una reale mancanza nell’implementazione dell’estensione.

Nei prossimi post spiegherò come configurare e utilizzare correttamente ognuna delle estensioni disponibili con il bundle.

• Debug
• I18n
• Intl
• Text

Per default questo viene clonato all’interno della dir “vendor/twig-extensions”, potete identificare facilmente la posizione dei sorgenti tramite il file di autoload (app/autoload.php).

Abilitare una di queste estensioni richiede semplicemente di taggare il servizio corrispondente con il tag twig.extension tramite la configurazione del DIC.

Volendo ad esempio abilitare l’estensione Text (Twig_Extensions_Extension_Text) sarà sufficiente aggiungere al file config.yml, all’interno del blocco “services”, queste righe:

twig.extension.text:
        class: Twig_Extensions_Extension_Text
        tags:
            - { name: twig.extension }

A questo punto le funzionalità dell’estensione sono disponibili all’interno dei nostri template.

Delle 4 estensioni disponibili Debug è l’unica che merita una nota particolare, almeno per quanto riguarda l’installazione. Questa estensione infatti, anche se abilitata, si attiva solamente se twig è in modalità debug. In configurazione predefinita lo stato di debug di twig viene ereditato dall’ environment di Symfony, questo significa che avrete a disposizione informazioni di debug solamente utilizzando l’environment dev.

Ovviamente tramite file di configurazione siete liberi di attivare o disattivare il debug di twig per ogni ambiente, aggiungendo o modificando la chiave “debug” all’intero del blocco twig in config.yml.

Per i dettagli di funzionamento delle singole estensioni vi rimando alle relative documentazioni.  Anche in questo caso però debug merita una piccola nota rispetto alle altre. Attivando il debug su un intero template infatti twig cercherà di fare un var_dump di tutte le variabili presenti. Questo vuol dire, senza xdebug attivo, che è molto probabile che il rendering vada in timeout o in memory_limit. Una buona pratica è quella di attivare il debug solo per le variabili che volete veramente ispezionare.

Queste estensioni non aggiungono funzionalità incredibili a twig, ma offrono comunque delle utility interessanti. In particolare ho trovato utili Text e Debug, ma credo che in futuro guadagneremo altre estensioni che andranno a fare da complemento al già ottimo template engine.

Nel caso aveste qualche buona idea per un’estensione non dimenticatevi di mandare la vostra pull request.

Sappiamo che Symfony2 predilige l’utilizzo di git come sistema di versionamento. Tuttavia, potrebbero esserci tutta una serie di ragioni per cui un progetto abbia bisogno di subversion: la stessa documentazione ufficiale ne fa un accenno, purtroppo senza addentrarsi nei dettagli.
Ecco qui cosa fare per avere un progetto Symfony2 funzionante con svn. Diamo per scontato di trovarci un una cartella in cui è stato fatto un checkout di un repository e in cui la cartella vendor di Symfony2 non sia presente (per esempio, perché il repository contiene uno scheletro di progetto simile a quello della Standard Edition senza venditori).
La prima cosa da fare è aggiungere i vari bundle e le altre dipendenza in externals:

mkdir vendor
svn pe svn:externals vendor

Nella finestra dell’editor, inserire le seguenti righe:

symfony              http://svn.github.com/symfony/symfony.git
twig                 http://svn.github.com/fabpot/Twig.git
monolog              http://svn.github.com/Seldaek/monolog.git
doctrine-common      http://svn.github.com/doctrine/common.git
doctrine-dbal        http://svn.github.com/doctrine/dbal.git
doctrine             http://svn.github.com/doctrine/doctrine2.git
swiftmailer          http://svn.github.com/swiftmailer/swiftmailer.git
assetic              http://svn.github.com/kriswallsmith/assetic.git
twig-extensions      http://svn.github.com/fabpot/Twig-extensions.git
metadata             http://svn.github.com/schmittjoh/metadata.git
 
doctrine-extensions  http://svn.github.com/l3pp4rd/DoctrineExtensions.git
 
bundles/Stof/DoctrineExtensionsBundle       http://svn.github.com/stof/StofDoctrineExtensionsBundle.git
 
bundles/Sensio/Bundle/FrameworkExtraBundle  http://svn.github.com/sensio/SensioFrameworkExtraBundle.git
bundles/Sensio/Bundle/DistributionBundle    http://svn.github.com/sensio/SensioDistributionBundle.git
bundles/Sensio/Bundle/GeneratorBundle       http://svn.github.com/sensio/SensioGeneratorBundle.git
bundles/JMS/SecurityExtraBundle             http://svn.github.com/schmittjoh/JMSSecurityExtraBundle.git
 
cg-library                                  http://svn.github.com/schmittjoh/cg-library.git
bundles/JMS/AopBundle                       http://svn.github.com/schmittjoh/JMSAopBundle.git
 
symfony/src/Symfony/Bundle/AsseticBundle    http://svn.github.com/symfony/AsseticBundle.git

Si noti che sono stati aggiunti, oltre ai bundle di base, alcuni altri bundle utili.
Il problema di questo approccio è che github, almeno attualmente, non supporta il checkout di tag o branch tramite svn. Per questo le versioni dei vari venditori importate saranno quelle dei rispettivi master, quindi le versioni in sviluppo. Se quindi si riscontrano errori o eccezioni dovuti per esempio a metodi mancanti, si verifichi che il file app/bootstrap.php.cache contenga tutto ciò che è necessario. Ovviamente, va adattato anche il file relativo all’autoload:

// app/autoload.php
$loader->registerNamespaces(array(
    'Symfony'          => array(__DIR__.'/../vendor/symfony/src', __DIR__.'/../vendor/bundles'),
    'Sensio'           => __DIR__.'/../vendor/bundles',
    'JMS'              => __DIR__.'/../vendor/bundles',
    'CG'               => __DIR__.'/../vendor/cg-library/src',
    'Doctrine\\Common' => __DIR__.'/../vendor/doctrine-common/lib',
    'Doctrine\\DBAL'   => __DIR__.'/../vendor/doctrine-dbal/lib',
    'Doctrine'         => __DIR__.'/../vendor/doctrine/lib',
    'Monolog'          => __DIR__.'/../vendor/monolog/src',
    'Assetic'          => __DIR__.'/../vendor/assetic/src',
    'Metadata'         => __DIR__.'/../vendor/metadata/src',
    'Gedmo'            => __DIR__.'/../vendor/doctrine-extensions/lib',
    'Stof'             => __DIR__.'/../vendor/bundles',
));

e anche quello relativo all’attivazione dei bundle:

// app/AppKernel.php
public function registerBundles()
{
    $bundles = array(
        new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
        new Symfony\Bundle\SecurityBundle\SecurityBundle(),
        new Symfony\Bundle\TwigBundle\TwigBundle(),
        new Symfony\Bundle\MonologBundle\MonologBundle(),
        new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
        new Symfony\Bundle\DoctrineBundle\DoctrineBundle(),
        new Symfony\Bundle\AsseticBundle\AsseticBundle(),
        new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
        new JMS\AopBundle\JMSAopBundle(),
        new JMS\SecurityExtraBundle\JMSSecurityExtraBundle(),
        new Stof\DoctrineExtensionsBundle\StofDoctrineExtensionsBundle(),
    );
 
    if (in_array($this->getEnvironment(), array('dev', 'test'))) {
        $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
        $bundles[] = new Sensio\Bundle\GeneratorBundle\SensioGeneratorBundle();
    }
 
    return $bundles;
}

Aggiornamento: si può adattare facilmente app/bootstrap.php.cache con il comando

php ./vendor/bundles/Sensio/Bundle/DistributionBundle/Resources/bin/build_bootstrap.php