Merge branch '2.6' into 2.7

Conflicts:
	best_practices/configuration.rst
	best_practices/controllers.rst
	best_practices/creating-the-project.rst
	best_practices/forms.rst
	best_practices/templates.rst
	best_practices/tests.rst
	cookbook/security/access_control.rst

best_practices/configuration.rst

@@ -42,6 +42,8 @@ con il comportamento dell'applicazione. In altre parole, l'applicazione non si d
 sapere dov'è posizionata la base dati o come vi accede. L'unica cosa che gli importa sapere
 è che la base dati sia configurata correttamente.
 
+.. _best-practices-canonical-parameters:
+
 Parametri canonici
 ------------------
 

best_practices/controllers.rst

@@ -13,7 +13,7 @@ iniziare a rifattorizzare il codice del controllore e spostarlo in un servizio.
 
 .. best-practice::
 
-    Estendere il controller dalla classe base fornita da FrameworkBundle
+    Estendere il controllore dalla classe base fornita da FrameworkBundle
     e usare le annotazioni per configurare rotte, cache e sicurezza, quando possibile.
 
 L'accoppiamento dei controllore al framework sottostante consente di sfruttare tutte
@@ -30,13 +30,13 @@ Non sarà necessario esplorare decine di file di formati diversi
 (YAML, XML, PHP): tutta la configurazione è lì dove serve e in un solo formato.
 
 Complessivamente, quindi, si dovrebbe disaccoppiare totalmente la logica di business
-dal framework e nello stesso tempo accoppiare totalmente al framework controller e rotte,
+dal framework e nello stesso tempo accoppiare totalmente al framework controllori e rotte,
 in modo da ottenere il massimo da Symfony.
 
 Configurazione delle rotte
 --------------------------
 
-Per caricare tutte le rotte definite nelle annotazioni dei controller del bundle
+Per caricare tutte le rotte definite nelle annotazioni dei controllori del bundle
 `AppBundle` aggiungete la seguente configurazione al file principale delle rotte:
 
 .. code-block:: yaml
@@ -46,8 +46,8 @@ Per caricare tutte le rotte definite nelle annotazioni dei controller del bundle
         resource: "@AppBundle/Controller/"
         type:     annotation
 
-Questa configurazione caricherà le annotazioni da ogni controller presente sia nella
-directory ``src/AppBundle/Controller/`` che nelle sue sottocartelle. Se
+Questa configurazione caricherà le annotazioni da ogni controllore presente sia nella
+cartella ``src/AppBundle/Controller/`` sia nelle sue sottocartelle. Se
 l'applicazione definisce molti controllori, è perfettamente lecito organizzare il
 tutto in sottocartelle.
 
@@ -76,25 +76,20 @@ Configurazione dei template
     Non usare l'annotazione ``@Template()`` per configurare il template
     usato dal controllore.
 
-Anche se l'annotazione ``@Template()`` risulta molto utile essa nasconde qualche trabocchetto. Per
-questo motivo, si raccomanda di non usarla.
+Anche se l'annotazione ``@Template()`` risulta molto utile, essa nasconde qualche trucco.
+Ritenendo che il gioco non valga la candela, si raccomanda di non
+usarla.
 
-La maggior parte delle volte ``@Template`` è usato senza parametri il che rende più difficile
-sapere quale template viene renderizzato. Il suo utilizzo inoltre rende meno ovvio
-ai principianti che un controller deve sempre ritornare un oggetto Response (a meno che non si usi
-un view layer).
-
-Infine l'annotazione ``@Template`` usa la classe ``TemplateListener`` per ascoltare
-l'evento ``kernel.view`` del framework. L'ascoltatore ha un impatto non trascurabile
-sulle prestazioni dell'applicazione. Nell'esempio dell'applicazione blog il rendering
-dell'homepage impiega 5 millisecondi usando il metodo ``$this->render()``, mentre ben
-26 millisecondi usando l'annotazione ``@Template``.
+La maggior parte delle volte ``@Template`` è usato senza parametri, il che rende più difficile
+sapere quale template viene reso. Il suo utilizzo inoltre rende meno ovvio
+ai principianti che un controllore deve sempre restituire un oggetto Response (a meno che non si usi
+il livello della vista).
 
 Come dovrebbe essere il controllore
 -----------------------------------
 
-Considerando tutto, ecco un esempio di come dovrebbe essere il controller
-per l'homepage della nostra applicazione:
+Considerando tutto, ecco un esempio di come dovrebbe essere il controllore
+per l'homepage di un'applicazione:
 
 .. code-block:: php
 
@@ -130,7 +125,7 @@ per effettuare la ricerca dell'entity in modo automatico e passarla come paramet
 
 .. best-practice::
 
-    Usare il ParamConverter per caricare automaticamente le entità di Doctrine
+    Usare ParamConverter per caricare automaticamente le entità di Doctrine,
     nei casi più semplici.
 
 Per esempio:
@@ -153,7 +148,7 @@ Per esempio:
         ));
     }
 
-Solitamente ci si aspetterebbe un argomento ``$id`` nel metodo ``showAction``. Invece,
+Solitamente ci si aspetterebbe un parametro ``$id`` nel metodo ``showAction``. Invece,
 creando un nuovo parametro (``$post``) e specificando il tipo di classe ``Post``
 (che è un'entità Doctrine), ParamConverter cercherà automaticamente
 un oggetto la cui proprietà ``$id`` corrisponde al valore ``{id}``. Nel
@@ -204,8 +199,8 @@ perché è abbastanza flessibile:
         // ...
     }
 
-Possiamo infine dire che la scorciatoia di ParamConverter è buona nelle situazioni semplici.
-Nonostante ciò non si dovrebbe mai dimenticare che la ricerca diretta di entity è un'operazione 
+Si può infine dire che la scorciatoia di ParamConverter è buona nelle situazioni semplici.
+Nonostante ciò, non si dovrebbe mai dimenticare che la ricerca diretta di entity è un'operazione 
 molto facile.
 
 Eseguire codice prima e dopo

best_practices/creating-the-project.rst

@@ -8,35 +8,15 @@ In passato, i progetti Symfony erano creati con `Composer`_, il gestore di dipen
 per applicazioni PHP. Tuttavia, la raccomandazione attuale è di usare **l'installatore di Symfony**,
 che deve essere installato prima della creazione del primo progetto.
 
-Sistemi Linux e Mac OS X
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Aprire una console dei comandi ed eseguire i seguenti comandi:
-
-.. code-block:: bash
-
-    $ curl -LsS http://symfony.com/installer > symfony.phar
-    $ sudo mv symfony.phar /usr/local/bin/symfony
-    $ chmod a+x /usr/local/bin/symfony
-
-Ora si può eseguire l'installatore di Symfony come comando globale di sistema, di nome
-``symfony``.
-
-Sistemi Windows
-~~~~~~~~~~~~~~~
-
-Aprire una console dei comandi ed eseguire i seguenti comandi:
-
-.. code-block:: bash
-
-    c:\> php -r "readfile('http://symfony.com/installer');" > symfony.phar
+.. best-practice::
 
-Quindi spostare il file ``symfony.phar`` appena scaricato nella cartella dei progetti
-ed eseguirlo, come segue:
+    Usare l'installatore di Symfony per creare nuovi progetti basati su Symfony.
 
-.. code-block:: bash
+Leggere il :doc:`capitolo dell'installazione </book/installation>` del libro di Symfony per
+sapere come installare e usare l'installatore di Symfony.
 
-    c:\> php symfony.phar
+.. _linux-and-mac-os-x-systems:
+.. _windows-systems:
 
 Creare un'applicazione Blog
 ---------------------------

best_practices/forms.rst

@@ -12,16 +12,16 @@ Creazione dei form
 
     Definire i form come classi PHP.
 
-Il componente `Form` consente di creare form direttamente dal controller.
+Il componente `Form` consente di creare form direttamente dal controllore.
 A meno che non si voglia riusare il form da qualche altra parte, quest'abitudine
-non è del tutto sbagliata. Nonostante ciò, per form più complessi da poter riutilizzare in altri controller
+non è del tutto sbagliata. Nonostante ciò, per form più complessi da poter riutilizzare in altri controllori
 si raccomanda di definire ogni form nella propria classe PHP::
 
     namespace AppBundle\Form;
 
     use Symfony\Component\Form\AbstractType;
     use Symfony\Component\Form\FormBuilderInterface;
-    use Symfony\Component\OptionsResolver\OptionsResolverInterface;
+    use Symfony\Component\OptionsResolver\OptionsResolver;
 
     class PostType extends AbstractType
     {
@@ -36,7 +36,7 @@ si raccomanda di definire ogni form nella propria classe PHP::
             ;
         }
 
-        public function setDefaultOptions(OptionsResolverInterface $resolver)
+        public function configureOptions(OptionsResolver $resolver)
         {
             $resolver->setDefaults(array(
                 'data_class' => 'AppBundle\Entity\Post'
@@ -207,3 +207,21 @@ In secondo luogo si raccomand di usare ``$form->isSubmitted()`` nel costrutto ``
 per rendere il codice più chiaro. Tecnicamente non è necessario, dato che ``isValid()``  esegue prima
 ``isSubmitted()``. Senza questo, tuttavia, il flusso risulterebbe un po' strano
 e il form sembrerebbe *sempre* processato, anche per le richieste GET.
+
+TIpi di campo personalizzati
+----------------------------
+
+.. best-practice::
+
+    Aggiungere il prefisso ``app_`` ai campi personalizzati, per evitare collisioni.
+
+I tipi di campo personalizzati ereditano dalla classe ``AbstractType``, che definisce il metodo
+``getName()`` per configurare il nome del tipo. Tali nomi devono essere univoci
+nell'applicazione.
+
+Se un tipo personalizzato usa lo stesso nome di uno dei tipi di Symfony,
+lo sovrascriverà. Lo stesso accade quando il tipo personalizzato corrisponde
+a un qualsiasi tipo definito da bundle di terze parti installati nell'applicazione.
+
+Aggiungere il prefisso ``app_`` ai campi personalizzati, per evitare collisioni
+che potrebbero portare a errori.

best_practices/templates.rst

@@ -33,8 +33,8 @@ Solitamente gli sviluppatori Symfony mettevano i template dell'applicazione nell
 ``Resources/views/`` di ciascun bundle. Per riferirsi ad essi usavano il nome logico
 (p.e. ``AcmeDemoBundle:Default:index.html.twig``).
 
-Anche se per i bundle a terzi quest'abitudine è corretta, è molto più conveniente, invece,
-inserire i template dell'applicazione nella directory ``app/Resources/views/``.
+Anche se per i bundle di terzi questa abitudine è corretta, è molto più conveniente, invece,
+inserire i template dell'applicazione nella cartella ``app/Resources/views/``.
 Innanzitutto questo semplifica drasticamente il nome logico dei template:
 
 =================================================  ==================================
@@ -51,12 +51,16 @@ Un altro vantaggio è che centralizzare i template semplifica il lavoro dei
 grafici. Essi non dovranno cercare più i template in tante cartelle sparpagliate fra
 i bundle.
 
+.. best-practice::
+
+    Usare la notazione_serpente in minuscolo per nomi di cartelle e template.
+
 Estensioni Twig
 ---------------
 
 .. best-practice::
 
-    Definire le estensioni di Twig nella directory ``AppBundle/Twig``, configurandole
+    Definire le estensioni di Twig nella cartella ``AppBundle/Twig``, configurandole
     nel file ``app/config/services.yml``.
 
 All'applicazione serve un filtro Twig personalizzato `m2html` in modo da poter

best_practices/tests.rst

@@ -11,8 +11,8 @@ Test unitari
 
 I test unitari sono usati per testare la "logica di business"; essa è
 totalmente indipendente dal framework motivo per cui Symfony non include al suo interno
-nessun tool per i test unitari. Tuttavia, gli strumenti più conosciuti sono
-[PhpUnit](https://phpunit.de/) e [PhpSpec](http://www.phpspec.net/).
+nessuno strumento per i test unitari. Tuttavia, gli strumenti più conosciuti
+sono `PhpUnit`_ e `PhpSpec`_.
 
 Test funzionali
 ---------------
@@ -30,25 +30,35 @@ Un semplice esempio di un test funzionale:
 
 .. code-block:: php
 
-    /** @dataProvider provideUrls */
-    public function testPageIsSuccessful($url)
-    {
-        $client = self::createClient();
-        $client->request('GET', $url);
+    // src/AppBundle/Tests/ApplicationAvailabilityFunctionalTest.php
+    namespace AppBundle\Tests;
 
-        $this->assertTrue($client->getResponse()->isSuccessful());
-    }
+    use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;
 
-    public function provideUrls()
+    class ApplicationAvailabilityFunctionalTest extends WebTestCase
     {
-        return array(
-            array('/'),
-            array('/posts'),
-            array('/post/fixture-post-1'),
-            array('/blog/category/fixture-category'),
-            array('/archives'),
-            // ...
-        );
+        /**
+         * @dataProvider urlProvider
+         */
+        public function testPageIsSuccessful($url)
+        {
+            $client = self::createClient();
+            $client->request('GET', $url);
+
+            $this->assertTrue($client->getResponse()->isSuccessful());
+        }
+
+        public function urlProvider()
+        {
+            return array(
+                array('/'),
+                array('/posts'),
+                array('/post/fixture-post-1'),
+                array('/blog/category/fixture-category'),
+                array('/archives'),
+                // ...
+            );
+        }
     }
 
 Questo codice controlla che tutti gli URL vengano caricati correttamente, cioè