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

1
2
3
4
5
6

// funzione originale
public function pippo()
{
  parent:pippo()
  // ecc. ecc.
}

Se siamo in un caso come questo e ci serve sovrascrivere la funzione pippo(), non possiamo ricorrere a parent::, perché richiamerebbe appunto la funzione che vogliamo aggirare. La soluzione è tanto semplice quanto efficace:

1
2
3
4
5
6

// nostra funzione di override
public function pippo()
{
  call_user_func(array(get_parent_class(get_parent_class($this)), 'pippo'));
  // ecc. ecc.
}

In questo modo possiamo richiamare direttamente il nonno della nostra classe, invece del padre

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

<?php
 
/**
 * progressbar task
 *
 * PEAR's Console_ProgressBar is required.
 * If Console_ProgressBar is not installed, no bar is displayed and no error is given
 * @see http://pear.php.net/package/Console_ProgressBar
 *
 * Usage: extend this class instead of sfBaseTask in your task.
 *        in your execute() method, call $this->init() and then other methods
 *        where appropriate.
 *
 * @author  Massimiliano Arione
 */
abstract class progressbarTask extends sfBaseTask
{
  protected
    $bar,
    $hasBar = false;
 
  /**
   * initialize ProgressBar
   */
  protected function init()
  {
    $this->hasBar = @include_once 'Console/ProgressBar.php';
  }
 
  /**
   * start bar
   * @param integer $count total number of items
   */
  protected function start($count = 0)
  {
    if ($this->hasBar)
    {
      $this->bar = new Console_ProgressBar('[%bar%] %percent% %elapsed%', '=>', ' ', 90, $count);
    }
  }
 
  /**
   * update the bar
   * @param integer $step
   */
  protected function update($step)
  {
    if ($this->hasBar)
    {
      $this->bar->update($step);
    }
  }
 
  /**
   * erase the bar
   */
  protected function erase()
  {
    if ($this->hasBar)
    {
      $this->bar->erase();
      $this->log('');
    }
  }
}

L’utilizzo è molto semplice: basta richiamare il metodo init(), quindi ogni volta che serve barra di progressione richiamare start(), update() ed erase() rispettivamente prima, durante e dopo il ciclo. Al metodo update() va passato un contatore, che deve essere incrementato nel ciclo stesso.

1
2
3

login:
  url:   /login
  param: { module: default, action: login }

Inseriamo poi le credenziali dell’utente che deve accedere al backend, nel file app.yml dell’applicazione:

1
2
3
4

all:
  admin_user:     admin
  # qui conviene mettere una password migliore :-)
  admin_password: admin

Basterà quindi inserire la sequente azione nel modulo default:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public function executeLogin(sfWebRequest $request)
{
  if ($this->getUser()->isAuthenticated())
  {
    return $this->redirect('@homepage');
  }
  if (isset($_SERVER['PHP_AUTH_USER']))
  {
    if ($_SERVER['PHP_AUTH_USER'] == sfConfig::get('app_admin_user') &&
        $_SERVER['PHP_AUTH_PW'] == sfConfig::get('app_admin_password'))
    {
      $this->getUser()->setAuthenticated(true);
 
      return $this->redirect($request->getUri());
    }
  }
  $this->getResponse()->setStatusCode(401);
  $this->getResponse()->setHttpHeader('WWW_Authenticate', 'Basic realm="Authentication required"');
 
  return sfView::NONE;
}

E il gioco è fatto. Eventualmente si può personalizzare il messaggio “Authentication required”.
Nei test funzionali, sarà possibile effettuare il login usando il metodo setAuth(), con l’accortezza di seguire il redirect dopo il primo get.

1
2
3
4
5

$browser->
  setAuth('admin', 'admin')->
  get('/')->
  with('response')->isRedirected()->followRedirect()->
 // eccetera...

In questi casi sfTesterMailer, che con il metodo withMessage(), ci viene incontro dandoci la possibilità di filtrare, filtrando per destinatario, l’email che vogliamo testare.

Supponiamo ad esempio di aver spedito due email, una a admin@example.org e l’altra ad user@example.org in questo ordine.

Il test funzionale corrispondente sarà:

1
2
3
4
5
6

with('mailer')->begin()->
  hasSent(2)->
  checkHeader('to', '/admin@example.org/')->
  withMessage('user@example.org')->
  checkHeader('to', '/user@example.org/')->
end();

Inoltre il metodo withMessage() ci permette anche di ciclare all’interno dei messaggi, usando un secondo parametro denominato $position, casomai i messaggi inviati all’utente siano più di uno.