Development

Documentation/it_IT/book/1.1/05-Configuring-Symfony (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of Documentation/it_IT/book/1.1/05-Configuring-Symfony

Show
Ignore:
Author:
garak (IP: 62.101.100.5)
Timestamp:
10/13/08 15:37:32 (9 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/it_IT/book/1.1/05-Configuring-Symfony

    v0 v1  
     1{{{ 
     2#!WikiMarkdown 
     3 
     4Capitolo 5 - Configurare symfony 
     5================================ 
     6 
     7Per essere semplice da usare, symfony definisce alcune convenzioni, che devono soddisfare i requisiti più comuni nello sviluppo web senza bisogno di modifiche. Comunque, utilizzando un insieme di semplici e potenti file di configurazione, è possibile personalizzare il modo in cui il framework e la tua applicazione interagiscono fra loro. Con questi file di configurazione, potrai anche aggiungere parametri speciali alla tua applicazione. 
     8 
     9Questo capitolo spiega come funziona la configurazione del sistema: 
     10 
     11  * La configurazione di symfony è memorizzata in file scritti in YAML, anche se è sempre possibile scegliere un altro formato. 
     12  * Nella struttura di cartelle del progetto, i file di configurazione si trovano ai livelli progetto, applicazione e modulo. 
     13  * Puoi definire diversi insiemi di impostazioni; in symfony, un insieme di configurazioni è chiamato ambiente. 
     14  * I valori definiti nei file di configurazione sono disponibili al codice PHP della tua applicazione. 
     15  * Inoltre, symfony permette l'utilizzo di PHP all'interno dei file di configurazioni, per renderli ancora più flessibili. 
     16 
     17Il sistema di configurazione 
     18---------------------------- 
     19 
     20A parte lo scopo, la maggior parte delle applicazioni web condivide un insieme di caratteristiche comuni. Ad esempio, qualche sezione puo' avere accesso ristretto ad un certo insieme di utenti, oppure le pagine possono essere decorate da un layout, o ancora la possibilità di avere le form già riempite dopo una validazione fallita. Un framework definisce una struttura per simulare queste caratteristiche, e gli sviluppatori possono ulteriormente modificarle cambiando i file di configurazione. Questa strategia fa risparmiare molto tempo durante lo sviluppo, dato che molti cambiamenti non necessitano di alcuna linea di codice, anche se ce n'è molto dietro. Questo sistema è anche molto efficiente, perché assicura che queste informazioni siano reperibili sempre in un punto unico e facile da trovare. 
     21 
     22Questo approccio ha però due seri svantaggi: 
     23 
     24  * Gli sviluppatori di solito finiscono per scrivere complessi file XML senza fine. 
     25  * In un'architettura PHP, ogni richiesta necessita di più tempo per essere eseguita. 
     26 
     27Tenendo conto di questi svantaggi, symfony utilizza file di configurazione solo dove sono veramente necessari. L'ambizione del sistema di configurazione di symfony è di essere: 
     28 
     29 * Potente: ogni aspetto che possa essere gestito tramite file di configurazione lo è veramente. 
     30 * Semplice: diversi parametri di configurazione non sono mostrati in applicazioni normali, in quanto raramente necessitano di essere modificati. 
     31 * Facile: gli sviluppatori troveranno facile leggere, creare e modificare file di configurazione. 
     32 * Personalizzabile: il linguaggio di configurazione di default è YAML, ma puo' essere INI, XML, o qualsiasi altro formato lo sviluppatore preferisca. 
     33 * Veloce: i file di configurazione non vengono processati dall'applicazione ma dal sistema di configurazione, che li compila velocemente in parti di codice PHP sul server. 
     34 
     35### Sintassi YAML e convenzioni di symfony 
     36 
     37Per la propria configurazione, symfony utilizza il formato YAML, invece dei più tradizionali INI e XML. YAML mostra la struttura tramite indentazione ed è veloce da scrivere. I vantaggi e le regole di base sono state mostrate nel Capitolo 1. Comunque, devi tenere a mente qualche convenzione quando vuoi scrivere file di YAML. Questa sezione mostra diverse convenzioni tra le più importanti. Per approfondimenti visita il sito web di YAML ([http://www.yaml.org/](http://www.yaml.org/)). 
     38 
     39Prima di tutto non sono ammessi caratteri di tabulazione in YAML; occorre usare spazi bianchi. I parser YAML non capiscono le tabulazioni, per cui utilizza spazi bianchi per l'indentazione (la convenzione in symfony è di due spazi bianchi), come mostrato nel Listato 5-1. 
     40 
     41Listato 5-1 - YAML vieta l'utilizzo delle tabulazioni 
     42 
     43    # Never use tabs 
     44    all: 
     45    -> mail: 
     46    -> -> webmaster:  webmaster@example.com 
     47 
     48    # Use blanks instead 
     49    all: 
     50      mail: 
     51        webmaster: webmaster@example.com 
     52 
     53Se i tuoi parametri sono stringhe che cominciano o finiscono con spazi vuoti, incapsula il valore tra singoli apici. Se una stringa contiene caratteri particolari, incapsula anche quella tra singoli apici, come mostrato nel Listato 5-2. 
     54 
     55Listato 5-2 - Stringhe non standard dovrebbero essere incapsulate tra singoli apici 
     56 
     57    error1: This field is compulsory 
     58    error2: '  This field is compulsory  ' 
     59    error3: 'Don''t leave this field blank'   # Single quotes must be doubled 
     60 
     61Puoi definire stringhe lunghe in più righe, ed anche stringhe con più di una linea, con gli header speciali di stringa (> e |) più una indentazione addizionale. Il Listato 5-3 illustra questa convenzione. 
     62 
     63Listato 5-3 - Definizione di stringhe lunghe e su più righe 
     64 
     65    # Folded style, introduced by > 
     66    # Each line break is folded to a space 
     67    # Makes YAML more readable 
     68    accomplishment: > 
     69      Mark set a major league 
     70      home run record in 1998. 
     71 
     72    # Literal style, introduced by | 
     73    # All line breaks count 
     74    # Indentation doesn't appear in the resulting string 
     75    stats: | 
     76      65 Home Runs 
     77      0.278 Batting Average 
     78 
     79Per definire un valore come array, racchiudi gli elementi tra parentesi quadre, oppure usa la sintassi estesa con i trattini, come mostrato nel Listato 5-4. 
     80 
     81Listato 5-4 - Sintassi di array in YAML 
     82 
     83    # Shorthand syntax for arrays 
     84    players: [ Mark McGwire, Sammy Sosa, Ken Griffey ] 
     85 
     86    # Expanded syntax for arrays 
     87    players: 
     88      - Mark McGwire 
     89      - Sammy Sosa 
     90      - Ken Griffey 
     91 
     92Per definire un valore come array associativo, o hash, racchiudi gli elementi tra parentesi graffe e inserisci sempre tra la chiave ed il valore. Puoi anche utilizzare la sintassi estesa, aggiungendo indentazione e ritorno a capo per ogni chiave, come mostrato nel Listato 5-5. 
     93 
     94Listato 5-5 - Array associativi in YAML 
     95 
     96    # Incorrect syntax, blanks are missing after the colon 
     97    mail: {webmaster:webmaster@example.com,contact:contact@example.com} 
     98 
     99    # Correct shorthand syntax for associative arrays 
     100    mail: { webmaster: webmaster@example.com, contact: contact@example.com } 
     101 
     102    # Expanded syntax for associative arrays 
     103    mail: 
     104      webmaster: webmaster@example.com 
     105      contact:   contact@example.com 
     106 
     107Per assegnare un booleano, utilizza 1 o true per un valore positivo, 0 o false per uno negativo. Il Listato 5-6 mostra i possibili valori booleani. 
     108 
     109Listato 5-6 - Sintassi YAML per valori booleani 
     110 
     111    true_values:   [ on, 1, true ] 
     112    false_values:  [ off, 0, false ] 
     113 
     114Non esitare ad aggiungere commenti (che devono cominciare con il cancelletto #) e spazi aggiuntivi, per rendere ancora più leggibili tuoi file YAML, come mostrato nel Listato 5-7. 
     115 
     116Listato 5-7 - Sintassi dei commenti in YAML 
     117 
     118    # This is a comment line 
     119    mail: 
     120      webmaster: webmaster@example.com 
     121      contact:   contact@example.com 
     122      admin:     admin@example.com   # extra spaces allow nice alignment of values 
     123 
     124In qualche file di configurazione di symfony, ti capiterà di trovare delle linee che cominciano con un cancelletto (per cui ignorate dal parser YAML) e che assomigliano a normali linee di impostazioni. Questa è una convenzione di symfony: la configurazione di default, ereditata da altri file YAML che si trovano nel core, è ripetuta in linee commentate nella tua applicazione per pura informazione. Se vuoi cambiare uno di tali parametri, devi innanzitutto decommentare la linea, come mostrato nel Listato 5-8. 
     125 
     126Listato 5-8 - La configurazione di default è mostrata commentata 
     127 
     128    # The cache is off by default 
     129    settings: 
     130    # cache: off 
     131 
     132    # If you want to change this setting, uncomment the line first 
     133    settings: 
     134      cache: on 
     135 
     136Qualche volta symfony raggruppa le definizioni dei parametri in categorie. Tutte le impostazioni relative ad una data categoria appaiono indentati sotto il suo header. Strutturare lunghe liste di coppie `chiave: valore` raggruppandole in categorie aumenta la leggibilità della configurazione. Gli header di categoria cominciano con un punto (.). Il Listato 5-9 mostra un esempio di categorie. 
     137 
     138Listato 5-9 - Gli header di categoria sembrano chiavi, ma cominciano un un punto 
     139 
     140    all: 
     141      .general: 
     142        tax:        19.6 
     143 
     144      mail: 
     145        webmaster:  webmaster@example.com 
     146 
     147In questo esempio, `mail` è una chiave e `general` è solo un header di categoria. Tutto funziona come se l'header non esistesse, come mostrato nel Listato 5-10. Il parametro `tax` è effettivamente un figlio di della chiave `all`. 
     148 
     149Listato 5-10 - Gli header di categoria esistono solo per una questione di leggibilità, e sono in effetti ignorati 
     150 
     151    all: 
     152      tax:          19.6 
     153 
     154      mail: 
     155        webmaster:  webmaster@example.com 
     156 
     157>**SIDEBAR** 
     158>E se non ti piace YAML 
     159> 
     160>YAML è solo un'interfaccia per definire impostazioni utilizzate da PHP, per cui le configurazioni YAML finiscono per essere trasformate in PHP. Dopo aver navigato la tua applicazione, controllane la configurazione in cache (ad esempio in `cache/frontend/dev/config/`). Vedrai file PHP corrispondenti alle configurazioni YAML. Imparerai di più sulla cache di configurazione più avanti in questo capitolo. 
     161> 
     162>La buona notizia è che se non vuoi usare YAML, puoi fare la stessa cosa a mano in PHP o con altri formati (come XML o INI). Nel corso di questo libro, incontrerai modi alternativi per definire configurazioni senza YAML, ed imparerai anche come sostituire il gestore di configurazioni di symfony (nel Capitolo 19). Se le usi largamente, questi trucchi ti permetteranno di bypassare i file di configurazione o definire il tuo personale formato di configurazione. 
     163 
     164### Aiuto, un file YAML ha ucciso la mia applicazione! 
     165 
     166I file YAML sono parsati in array o hash PHP, quindi i valori sono usati in varie parti dell'applicazione per modificare il comportamento delle viste, del controller o del modello. Molte volte, quando c'è un errore in un file YAML, esso non viene riconosciuto fino a che il valore non è effettivamente necessario. Ancora più spesso, l'eccezione che ne viene generata non si riferisce chiaramente al file YAML. 
     167 
     168Se la tua applicazione smette improvvisamente di funzionare dopo un cambio di configurazione, devi controllare di non aver fatto qualcuno dei più comuni errori di disattenzione con YAML: 
     169 
     170  * Ti manca uno spazio tra una chiave ed il suo valore: 
     171 
     172        key1:value1      # Manca uno spazio bianco dopo : 
     173 
     174  * Le chiavi in una sequenza non sono indentate nella stessa maniera: 
     175 
     176        all: 
     177          key1:  value1 
     178           key2: value2  # Indentazione sbagliata 
     179          key3:  value3 
     180 
     181  * C'è un carattere riservato in una chiave o un valore, senza delimitatori di stringa: 
     182 
     183        message: tell him: go way    # :, [, ], { e } sono riservati in YAML 
     184        message: 'tell him: go way'  # Sintassi corretta 
     185 
     186  * Stai modificando una linea commentata: 
     187 
     188        # key: value     # Questa linea è ignorata perché comincia con # 
     189 
     190  * Imposti dei valori con la stessa chiave allo stesso livello: 
     191 
     192        key1: value1 
     193        key2: value2 
     194        key1: value3     # key1 è definita due volte, il valore è l'ultimo inserito 
     195 
     196  * Pensi che un valore sia un tipo speciale, mentre resta una stringa fino a che non sarà convertita: 
     197 
     198        income: 12,345   # Ancora una stringa, fino a che non sarà convertita 
     199 
     200Riepilogo dei file di configurazione 
     201------------------------------------ 
     202 
     203La configurazione è suddivisa in file, per oggetto. Questi file contengono definizioni di parametri, o impostazioni. Alcuni di tali parametri possono essere sovrascritti a diversi livelli (progetto, applicazione e modulo); altri specificatamente a certi livelli. I prossimi paragrafi prenderanno in esame le configurazioni relativamente alle loro finalità principali, mentre il Capitolo 19 esaminerà configurazioni avanzate. 
     204 
     205### Configurazione di progetto 
     206 
     207Ci sono per default pochi file di configurazione per progetto. Di seguito quelli che si trovano nella cartella `myproject/config/`: 
     208 
     209 * `ProjectConfiguration.class.php`: Questo è assolutamente il primo file incluso da ogni richiesta o comando. Contiene i percorsi ai file del framework, e può essere cambiato per usare un'installazione diversa. Vedi il Capitolo 19 per usi avanzati di questo file. 
     210 * `databases.yml`: Qui è dove definisci l'accesso e la connessione al database (host, login, password, nome del database, e così via). Imparerai di più su questo nel Capitolo 8. Può essere sovrascritto a livello applicazione. 
     211 * `properties.ini`: Questo file gestisce parametri utilizzati a linea di comando, inclusi il nome del progetto e le impostazioni di connessione a server remoti. Vedi il Capitolo 16 per un sommario delle caratteristiche di utilizzo di questo file. 
     212 * `rsync_exclude.txt`: Questo file specifica quali cartelle devono essere escluse dalla sincronizzazione tra server. È discusso nel Capitolo 16. 
     213 * `schema.yml` e `propel.ini`: Si tratta di file di configurazione per l'accesso ai dati usati da Propel (il livello ORM di symfony). Sono utilizzati per far funzionare le librerie Propel con le classi di symfony ed i dati del tuo progetto. `schema.yml` contiene una rappresentazione del modello relazionale del progetto. `propel.ini` è generato automaticamente, per cui probabilmente non avrai bisogno di modificarlo. Se non usi Propel, questi file non sono necessari. Il Capitolo 8 approfondirà il loro utilizzo. 
     214 
     215Questi file sono usati per lo più da componenti esterni o dalla linea di comando, o devono essere processati prima che il framework carichi il programma di parsing YAML. Ecco perché alcuni di essi non usano il formato YAML. 
     216 
     217### Configurazione dell'applicazione 
     218 
     219La maggior parte della configurazione è occupata dall'applicazione. È definita nel front controller (nella cartella `web/`) per la configurazione principale, in file YAML nella cartella `config/` dell'applicazione, in `i18n/` per l'internazionalizzazione, ed infine nei file del framework per una invisibile (ma sempre utile) configurazione addizionale dell'applicazione. 
     220 
     221#### Configurazione del front controller 
     222 
     223La prima configurazione dell'applicazione in assoluto si trova nel front controller; si tratta del primo script eseguito da una richiesta. Dai un'occhiata al codice di `web/index.php` mostrato nel Listato 5-11. 
     224 
     225Listato 5-11 - Il front controller di default 
     226 
     227    [php] 
     228    <?php 
     229 
     230    require_once(dirname(__FILE__).'/../config/ProjectConfiguration.class.php'); 
     231  
     232    $configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false); 
     233    sfContext::createInstance($configuration)->dispatch(); 
     234 
     235Dopo aver definito il nome dell'applicazione (`frontend`) e l'ambiente (`prod`), la configurazione generale è chiamata prima del dispatching. Per cui qualche costante utile viene definita qui: 
     236 
     237 * `$configuration->getRootDir()`: La cartella di root del progetto (di norma dovrebbe rimanere come è di default, a meno che tu non voglia cambiare la struttura delle cartelle). 
     238 * `$configuration->getApplication()`: Nome dell'applicazione nel progetto. Necessario per computare i percorsi dei file. 
     239 * `$configuration->getEnvironment()`: Nome dell'ambiente ({{{prod}}}, {{{dev}}}, o qualsiasi altro ambiente specifico che tu creerai ad hoc per il tuo progetto). Determinerà quali sono le impostazioni di configurazione da utilizzare. Gli ambienti sono spiegati più avanti in questo capitolo. 
     240 * `$configuration->isDebug()`: Attivazione della modalità di debug (vedere il Capitolo 16 per i dettagli). 
     241 
     242Se vuoi cambiare uno di questi valori, probabilmente avrai bisogno di un front controller addizionale. Il prossimo capitolo spiegherà più nel dettaglio i front controller e come crearne di nuovi. 
     243 
     244#### Configurazione dell'applicazione principale 
     245 
     246La configurazione dell'applicazione principale è memorizzata in file che si trovano nella cartella `myproject/apps/frontend/config/`: 
     247 
     248  * `app.yml`: Questo file dovrebbe contenere configurazioni specifiche all'applicazione; ad esempio variabili globali che definiscono business logic o applicativa specifiche, che non hanno bisogno di essere memorizzate nel db. Tasse, costi di spedizione, indirizzi e-mail sono memorizzati spesso in questo file, che di default è vuoto. 
     249  * `frontendConfiguration.class.php`: questa classe si occupa del bootstrap dell'applicazione, quindi fa tutte le inizializzazioni di base necessarie all'applicazione per partire. È qui che puoi definire una struttura di cartelle particolare, oppure delle costanti specifiche (il Capitolo 19 ne fornirà maggiori dettagli). Estende la classe ProjectConfiguration. 
     250  * `factories.yml`: symfony definisce le proprie classi per gestire le viste, la richiesta, la risposta, le sessioni e così via. Se invece vuoi utilizzare le tue classi personali, questo file è i posto in cui definirle (maggiori informazioni nel Capitolo 19). 
     251  * `filters.yml`: I filtri sono porzioni di codice eseguiti per ogni richiesta. Qui è dove definisci quali filtri devono essere processati, e può essere overridato in ogni modulo. Il Capitolo 6 fornisce maggiori dettagli sui filtri. 
     252  * `logging.yml`: Questo file definisce quale livello di dettaglio deve essere utilizzato nei log, per aiutarti a gestire e debuggare la tua applicazione. L'utilizzo di questo file è approfondito nel Capitolo 16. 
     253  * `routing.yml`: Le regole di routing, che permettono di trasformare una URL illeggibile in una più "intelligente", sono definite in questo file. Per nuove applicazioni, esistono poche regole di default. Il Capitolo 9 è dedicato ai link e al routing. 
     254  * `settings.yml`: Le impostazioni principali di un'applicazione symfony sono definiti in questo file. Qui è dove specifichi se la tua applicazione è internazionalizzata, qual'è la lingua di default, il timeout per le richieste e se la cache è attiva o meno. Cambiando una linea di questo file puoi "spegnere" la tua applicazione, per poterla aggiornare o manutenere. Le impostazioni più comuni ed il loro utilizzo sono approfonditi nel Capitolo 19. 
     255  * `view.yml`: La struttura della vista di default (nome del layout, fogli di stile e JavaScript da includere di default, content-type di default e così via) è definita in questo file. Il Capitolo 7 approfondirà questo file. Queste impostazioni possono essere sovrascritte in ogni modulo. 
     256 
     257#### Configurazione dell'internazionalizzazione 
     258 
     259Applicazioni internazionalizzate possono mostrare le pagine in diverse lingue. Questo richiede una configurazione specifica. Ci sono due file da configurare per l'internazionalizzazione: 
     260 
     261  * `factories.yml` della cartella `config/` dell'applicazione: Questo file definisce il factory i18n e le opzioni generali di traduzione, come ad esempio la cultura di default per la traduzione, se le traduzioni sono in un file o nel database ed il loro formato. 
     262  * File di traduzione nella cartella `i18n/` dell'applicazione: Questi sono fondamentalmente dei dizionari, che forniscono la traduzione delle parole utilizzate nelle template dell'applicazione in modo che le pagine mostrino testo tradotto quando un utente cambia la lingua. 
     263 
     264 
     265Nota che l'attivazione delle feature i18n è impostata nel file `settings.yml`. Approfondimenti a tale proposito nel Capitolo 13. 
     266 
     267#### Configurazioni addizionali dell'applicazione 
     268 
     269Un secondo insieme di file di configurazione è posizionato nella cartella di installazione di symfony (in `$sf_symfony_lib_dir/config/`) e non figura nella cartella di configurazione delle tue applicazioni. Tali impostazioni sono default che raramente hanno bisogno di essere modificate, oppure che sono globali a tutti i progetti. Comunque, se tu avessi bisogno di modificarle, crea un file vuoto nella cartella `myproject/apps/frontend/config/` e sovrascrivi i parametri che vuoi cambiare. Le impostazioni definite nell'applicazione hanno sempre la precedenza rispetto a quelle definiti nel framework. Di seguito i file di configurazione nella cartella `config/` dell'installazione di symfony: 
     270 
     271  * `autoload.yml`: Questo file contiene le impostazioni della funzione di autoloading. Tale funzione ti esonera dall'includere classi personalizzate se esse si trovano in una cartella specifica. Questa funzione è descritta nel Capitolo 19. 
     272  * `core_compile.yml` and `bootstrap_compile.yml`: Queste sono liste di classi da includere per far partire un'applicazione (`bootstrap_compile.yml`) e per processare una richiesta (`core_compile.yml`). Questi file sono effettivamente concatenati in un file PHP ottimizzato senza commenti, che velocizzera' l'esecuzione minimizzando le operazioni di accesso (è caricato un solo file invece di quaranta per ogni richiesta). Questo risulta specialmente utile se non utilizzi un acceleratore PHP. Le tecniche di ottimizzazione sono descritte nel Capitolo 18. 
     273  * `config_handlers.yml`: Qui puoi aggiungere o modificare i gestori usati per processare ogni file di configurazione. Il Capitolo 19 fornisce maggiori dettagli in merito. 
     274  * `php.yml`: Questo file controlla che le variabili in `php.ini` siano definite nel modo giusto e ti permette di farne l'override, se ne avessi bisogno. Controlla il Capitolo 19 per maggiori dettagli. 
     275 
     276### Configurazione del modulo 
     277 
     278Per default un modulo non ha una configurazione specifica. Ma, qualora necessario, puoi fare l'override di qualche impostazione del livello applicazione per un dato modulo. Ad esempio, potresti farlo per includere un file JavaScript specifico in tutte le azioni di un modulo. Puoi anche scegliere di aggiungere nuovi parametri esclusivamente per un dato modulo al fine di preservare l'incapsulazione. 
     279 
     280Come puoi immaginare, le impostazioni di un modulo devono essere nella cartella `myproject/apps/frontend/modules/mymodule/config/`. I file interessati sono i seguenti: 
     281 
     282  * `generator.yml`: Per i moduli generati secondo una tabella di database (scaffolding e amministrazione), questo file descrive il modo in cui le righe e campi devono essere visualizzati, e quali tipi di interazioni sono proposti all'utente (filtri, ordinamenti, pulsanti e cosi' via). Il Capitolo 14 approfondira' l'argomento. 
     283  * `module.yml`: Questo file contiene parametri specifici ad un modulo (equivalente a `app.yml`, ma a livello modulo) e la configurazione dell'azione. Il Capitolo 6 fornisce maggiori dettagli in merito. 
     284  * `security.yml`: Questo file permette di impostare restrizioni per le azioni. Qui puoi impostare il fatto che una certa pagina sia visibile solo agli utenti registrati, oppure ad un sottoinsieme di utenti con permessi speciali. Il Capitolo 6 fornisce maggiori dettagli in merito. 
     285  * `view.yml`: Questo file contiene le configurazioni delle viste di una o tutte le azioni di un modulo. Permette l'override di `view.yml` del livello applicazione, ed è descritto nel Capitolo 7. 
     286 
     287La maggior parte dei file di configurazione dei moduli offrono la possibilita' di definire parametri per tutte le viste o tutte le azioni di un modulo, oppure per un loro sottoinsieme. 
     288 
     289>**SIDEBAR** 
     290>Troppi file? 
     291> 
     292>Ti potresti sentire travolto dal numero di file di configurazione presenti nell'applicazione. Ma ricorda: 
     293> 
     294>La maggior parte delle volte non avrai bisogno di cambiare la configurazione, perché le convenzioni stabilite per default soddisfano i requisiti più comuni. Ogni file di configurazione corrisponde ad una particolare funzione, ed il prossimo capitolo le affrontera' dettagliatamente il loro utilizzo una alla volta. Quando ti focalizzi su di un singlo file, puoi capire chiaramente cosa fa e come è organizzato. Per lo sviluppo web professionale, la configurazione di default è spesso non completamente adatta. I file di configurazione permettono di modificare facilmente i meccanismi di symfony senza scrivere codice. Immagina l'ammontare di codice PHP necessario per raggiungere lo stesso livello di controllo. Se tutti parametri fossero all'interno di un unico file, non solo esso sarebbe illeggibile, ma non ci potrebbe nemmeno essere la possibilita' di fare override di parametri a divresi livelli (v. la sezione "Configurazione a cascata" più avanti in questo capitolo). 
     295> 
     296>Il sistema di configurazione è uno dei punti di forza di symfony, perché lo rende utilizzabile per qualsiasi tipo di applicazione web, e non solamente per quelle per le quali era stato pensato inizialmente. 
     297 
     298Environments 
     299------------ 
     300 
     301Durante lo sviluppo di un'applicazione, avrai probabilmente bisogno di mantenere in parallelo diversi insiemi di configurazioni. Ad esempio avrai bisogno di avere disponibili le impostazioni di connessione al tuo database di test per lo sviluppo, e di avere allo stesso tempo quelli reali per la produzione. Per soddisfare tale fabbisogno, symfony offre diversi ambienti. 
     302 
     303### Cosa è un Environment? 
     304 
     305Una applicazione puo' girare in diversi ambienti. Tali ambienti condividono lo stesso codice PHP (a parte il front controller) ma possono avere configurazioni completamente differenti. Per ogni applicazione, symfony fornisce tre ambienti: produzione (`prod`), test (`test`) e sviluppo (`dev`). Sei inoltre libero di aggiungerne quanti ne vuoi. 
     306 
     307Quindi, fondamentalmente, ambienti e configurazioni sono sinonimi. Ad esempio, un ambiente di test mettera' nei log sia alert che errori, mentre un `prod` scrivera' solo gli errori. La cache è spesso disattivata in ambienti `dev`, ma attivata in `test` e `prod`. Gli ambienti `dev` e `test` avranno bisogno di dati di test, memorizzati in un database diverso da quello di produzione. Tutti gli ambienti possono convivere sulla stessa macchina, sebbene di solito un server di produzione ospiti esclusivamente un ambiente `prod`. 
     308 
     309In `dev`, le impostazioni di logging e debugging sono tutti abilitati, dato che la manutenzione in tale ambiente è' più importante delle performance. Al contrario, l'ambiente di sviluppo è ottimizzato per le performance per default. Una buona regola è quella di navigare sul sito di sviluppo fino a che sei soddisfatto delle funzioni su cui stai lavorando, quindi passare a quello in produzione per verificarne le performance. 
     310 
     311L'ambiente `test` differisce dagli altri due in modi diversi. Interagirai con questo ambiente esclusivamente tramite la linea di comando per finalita' di test funzionali o scripting batch. Conseguentemente, l'ambiente `test` è simile a quello di produzione ma non vi si accede navigando. Simula l'utilizzo di cookie ed altri componenti specifici di HTTP. 
     312 
     313Per cambiare ambiente nel quale stai navigando l'applicazione, devi semplicemente cambiare il front controller. Sino ad ora hai visto solo l'ambiente di sviluppo, dato che le URL utilizzate negli esempi chiamavano sempre il front controller di sviluppo: 
     314 
     315    http://localhost/frontend_dev.php/mymodule/index 
     316 
     317Se vuoi vedere come l'applicazione reagisce in produzione, puoi invece chiamare il front controller per tale ambiente: 
     318 
     319    http://localhost/index.php/mymodule/index 
     320 
     321Se il tuo web server ha il mod_rewrite abilitato, puoi anche utilizzare le regole di symfony per il rewriting, definite in `web/.htaccess`. Esse definiscono il front controller di produzione come esecuzione di default e permettono di chiamare URL come: 
     322 
     323    http://localhost/mymodule/index 
     324 
     325>**SIDEBAR** 
     326>Environments e Servers 
     327> 
     328>Non confondere le nozioni di ambiente e server. In symfony, diversi ambienti sono diverse configurazioni, e corrispondono a diversi front controller (gli script che gestiscono le richieste). Server diversi corrispondono a diversi nomi a dominio nelle URL. 
     329> 
     330> 
     331>     http://localhost/frontend_dev.php/mymodule/index 
     332>            _________ _____________ 
     333>             server    environment 
     334> 
     335> 
     336>Normalmente, gli sviluppatori lavorano alle applicazioni su server di sviluppo, scollegati da Internet e dove le configurazioni possono essere cambiate a piacimento. Quando un'applicazione deve essere pubblicata, i suoi file vengono spostati sul server di sviluppo e resi così pubblici. 
     337> 
     338>Questo significa che diversi ambienti sono disponibili su ogni server. Ad esempio, potresti avere sulla stessa macchina ambiente di produzione e di sviluppo. Comunque, la maggior parte delle volte, sul server di produzione ci dovrebbe essere esclusivamente l'ambiente di produzione, per evitare che la configurazione del server sia visibile pubblicamente e quindi ponga dei rischi di sicurezza. Per prevenire l'esposizione accidentale dei controller che non siano di produzione, symfony aggiunge un semplice controllo dell'IP, che consente l'accesso solo da localhost. Se vuoi che siano accessibili, puoi rimuovere questo controllo, ma devi considerare i rischi di renderli accessibili a chiunque, poiché un utente malintenzionato potrebbe indovinare la posizione di default di frontend_dev.php ed avere accesso a molte informazioni di debug. 
     339> 
     340>Per aggiungere un ambiente, non hai bisogno di create una direcotry o usare la symfony CLI. Crea semplicemente un nuovo front controller e cambia il nome dell'ambiente. Questo ambiente erediterà tutte le configurazioni di default più i parametri comuni a tutti gli ambienti. Il prossimo capitolo ti insegnerà come farlo. 
     341 
     342### Configurazione a cascata 
     343 
     344Le stesse impostazioni possono essere definite più di una volta, in posti diversi. Ad esempio, potresti volere impostare il mime-type delle tue pagine come `text/html` per tutte le applicazioni tranne per le pagine di un modulo `rss`, che dovrebbe invece avere un mime-type `text/xml`. Symfony ti da la possibilità di scrivere la prima impostazione in `frontend/config/view.yml` ed il secondo in `frontend/modules/rss/config/view.yml`. Il sistema di configurazione sa che un'impostazione definita a livello modulo ha la precedenza rispetto alla stessa definito a livello applicazione. 
     345 
     346Infatti, ci sono diversi livelli di configurazione in symfony: 
     347 
     348  * Livelli di granularità: 
     349    * Configurazione di default situata nel framework 
     350    * Configurazione globale per l'intero progetto (in `myproject/config/`) 
     351    * Configurazione locale per un'applicazione del progetto (in `myproject/apps/frontend/config/`) 
     352    * Configurazione ristretta ad un modulo (in `myproject/apps/frontend/modules/mymodule/config/`) 
     353  * Livelli ambiente: 
     354    * Specifico ad un ambiente 
     355    * Per tutti gli ambienti 
     356 
     357Di tutte le proprietà che possono essere personalizzate, diverse sono dipendenti dall'ambiente. Conseguentemente, diversi file di configurazione YAML sono divisi per ambiente, più una sezione di coda per tutti gli ambienti. Il risultato di una tipica configurazione symfony è mostrato nel Listato 5-12. 
     358 
     359Listato 5-12 - Struttura dei file di configurazione di symfony 
     360 
     361    # Production environment settings 
     362    prod: 
     363      ... 
     364 
     365    # Development environment settings 
     366    dev: 
     367      ... 
     368 
     369    # Test environment settings 
     370    test: 
     371      ... 
     372 
     373    # Custom environment settings 
     374    myenv: 
     375      ... 
     376 
     377    # Settings for all environments 
     378    all: 
     379      ... 
     380 
     381In più, il framework stesso definisce dei valori di default in file che non sono situati nel tree del progetto, bensì nella cartella `$sf_symfony_lib_dir/config/config/` dell'installazione di symfony. Questa configurazione è mostrata nel Listato 5-13, e tali impostazioni sono ereditate da tutte le applicazioni. 
     382 
     383Listato 5-13 - Configurazione di default, in `$sf_symfony_lib_dir/config/config/settings.yml` 
     384 
     385     # Default settings: 
     386     default: 
     387       default_module:         default 
     388       default_action:         index 
     389       ... 
     390 
     391Queste configurazione di default sono ripetute nei files di configurazione di progetti, applicazione e moduli come commenti, come mostrato nel Listato 5-14, così che tu possa conoscere quali sono i parametri di defualt e modificarli. 
     392 
     393Listato 5-14 - Configurazione di default, ripetuta per informazione, in `frontend/config/settings.yml` 
     394 
     395    #all: 
     396     #  default_module:         default 
     397     #  default_action:         index 
     398     #  ... 
     399 
     400Ciò significa che una proprietà può essere definita diverse volte, e l'effettivo valore è il risultato di una cascata di definizioni. Il valore di un parametro definito in un ambiente specifico ha la precedenza sullo stesso valore definito per tutti gli ambienti, che a sua volta ha la precedenza su quello definito per default. Un parametro definito a livello modulo ha la precedenza sullo stesso definito a livello applicazione, che a sua volta ha la precedenza su quello definito a livello progetto. Tutto ciò è mostrato nella seguente lista di priorità: 
     401 
     402  1. Modulo 
     403  2. Applicazione 
     404  3. Progetto 
     405  4. Ambiente specifico 
     406  5. Tutti gli ambienti 
     407  6. Default 
     408 
     409La configurazione della cache 
     410----------------------------- 
     411 
     412Fare il parsing di file YAML e avere a che fare con la cascata di configurazioni comporta un grande carico di lavoro per ogni richiesta. Symfony possiede un meccanismo di cache integrato pensato per accelerare le richieste. 
     413 
     414I file di configurazione, in qualsiasi formato, vengono processati da classi speciali, chiamate gestori, che li trasformano in codice PHP processati velocemente. Nell'ambiente di sviluppo, i gestori controllano se ci sono stati cambiamenti nella configurazione ad ogni richiesta, per promuovere l'interattività. Essi fanno il parsing dei file modificati di recente in modo che tu possa vedere un cambiamento in un file YAML immediatamente. Ma nell'ambiente di produzione, questo avviene solo alla prima richiesta, dopodichè il codice PHP processato viene memorizzato in cache per le richieste successive. Le performance sono garantite, dato che ogni richiesta non farà altro che eseguire codice PHP ottimizzato. 
     415 
     416Ad esempio, se il file `app.yml` contenesse: 
     417 
     418    all:                   # Setting for all environments 
     419      mail: 
     420        webmaster:         webmaster@example.com 
     421 
     422allora il file `config_app.yml.php`, situato nella cartella `cache/` del tuo progetto, conterrebbe: 
     423 
     424    [php] 
     425    <?php 
     426 
     427    sfConfig::add(array( 
     428      'app_mail_webmaster' => 'webmaster@example.com', 
     429    )); 
     430 
     431Come conseguenza, il più delle volte, il framework non fa nemmeno il parsing dei file YAML, ma utilizza solo la cache. In ogni caso, in ambiente di sviluppo, symfony controllerà sistematicamente le date dei file YAML e dei file in cache, riprocessando solo il file che sono stati modificati dall'ultima richiesta. 
     432 
     433Questo rappresenta un grande vantaggio rispetto a molti framework PHP, che invece fanno il parsing dei file di configurazione ad ogni richiesta, anche in produzione. Diversamente da Java, PHP non condivide un contesto di esecuzione fra le richieste. Per altri framework PHP, possedere la flessibilità di file XML significa colpire le performance, per poter fare il parsing della configurazione ad ogni richiesta. Questo non è il caso di symfony. Grazie al sistema di cache, il sovraccarico dovuto alla configurazione è molto basso. 
     434 
     435C'è un'importante conseguenza di questo meccanismo. Se cambi la configurazione in produzione, devi forzare il sistema a rileggere i file per poter vedere le tue modifiche. Per poter fare questo, basta pulire la cache, rimuovendo tutti i file dalla cartella `cache/` oppure richiamando il comando: 
     436 
     437    > symfony cache:clear 
     438 
     439Accedere alla configurazione dal codice 
     440--------------------------------------- 
     441 
     442Tutti i file di configurazione sono alla fine trasformati in PHP, e molte delle impostazioni che contengono sono utilizzate dal framework senza ulteriori interventi. Comunque, ti potrebbe capitare di dover accedere ad alcune impostazioni direttamente dal tuo codice (in azioni, template, classi e così via). Le impostazioni definite in settings.yml, app.yml, e module.yml sono disponibili attraverso una classe speciale chiamata `sfConfig`. 
     443 
     444### la classe sfConfig 
     445 
     446Si tratta di un registro dei parametri di configurazione, con un semplice metodo getter utilizzabile da qualunque parte dell'applicazione: 
     447 
     448    [php] 
     449    // Retrieve a setting 
     450    parameter = sfConfig::get('param_name', $default_value); 
     451 
     452Inoltre è anche possibile definire, o fare un ovveride, di un parametro: 
     453 
     454    [php] 
     455    // Define a setting 
     456    sfConfig::set('param_name', $value); 
     457 
     458Il nome del parametro è una concatenazione di diversi elementi, separati da underscore, nel seguente ordine: 
     459 
     460  * Un prefisso relativo al nome del file di configurazione (`sf_` per `settings.yml`, `app_` per `app.yml`, e `mod_` per `module.yml`) 
     461  * La chiave del genitore, se definita, in minuscolo 
     462  * Il nome della chiave, in minuscolo 
     463 
     464 
     465L'ambiente non è incluso, dato che il tuo codice PHP avrà accesso unicamente ai valori definiti per l'ambiente in cui è eseguito. 
     466 
     467Ad esempio, se tu avessi bisogno di accedere ai parametri definiti in `app.yml` mostrato nel Listato 5-15, avrai bisogno del codice mostrato nel Listato 5-16. 
     468 
     469Listato 5-15 - Un esempio di configurazione di `app.yml` 
     470 
     471    all: 
     472      version:        1.5 
     473      .general: 
     474        tax:          19.6 
     475      default_user: 
     476        name:         John Doe 
     477      mail: 
     478 
     479        webmaster:    webmaster@example.com 
     480        contact:      contact@example.com 
     481    dev: 
     482      mail: 
     483        webmaster:    dummy@example.com 
     484        contact:      dummy@example.com 
     485 
     486Listato 5-16 - Recupero di parametri dall'ambiente `dev` 
     487 
     488    [php] 
     489    echo sfConfig::get('app_version'); 
     490     => '1.5' 
     491    echo sfConfig::get('app_tax');   // Remember that category headers are ignored 
     492     => '19.6' 
     493    echo sfConfig::get('app_default_user_name'); 
     494     => 'John Doe' 
     495    echo sfConfig::get('app_mail_webmaster'); 
     496     => 'dummy@example.com' 
     497    echo sfConfig::get('app_mail_contact'); 
     498     => 'dummy@example.com' 
     499 
     500In tal maniera, le impostazioni di configurazione di symfony hanno tutti i vantaggi delle costanti di PHP, ma non gli svantaggi, in quanto i loro valori possono essere modificati. 
     501 
     502Tenendo a mente questo concetto, il file `settings.yml`, nel quale puoi impostare i parametri del framework per l'applicazione, è equivalente ad una lista di chiamate `sfConfig::set()`. Il Listato 5-17 è interpretato come nel Listato 5-18. 
     503 
     504Listato 5-17 - Una parte di `settings.yml` 
     505 
     506    all: 
     507      .settings: 
     508        available:              on 
     509        path_info_array:        SERVER 
     510        path_info_key:          PATH_INFO 
     511        url_format:             PATH 
     512 
     513Listato 5-18 - Ciò che symfony produce quando ne fa il parsing di `settings.yml` 
     514 
     515    [php] 
     516    sfConfig::add(array( 
     517      'sf_available' => true, 
     518      'sf_path_info_array' => 'SERVER', 
     519      'sf_path_info_key' => 'PATH_INFO', 
     520      'sf_url_format' => 'PATH', 
     521    )); 
     522 
     523Il significato dei parametri del file `settings.yml` è spiegato nel Capitolo 19. 
     524 
     525### Impostazioni dell'applicazione personalizzati e app.yml 
     526 
     527La maggior parte delle impostazioni delle funzioni di un'applicazione dovrebbero essere definiti in `app.yml`, dentro la cartella `myproject/apps/frontend/config/`. Questo file dipende dall'ambiente e di default vuoto. Imposta in questo file tutti i parametri che vuoi cambiare facilmente, ed usa la classe `sfConfig` per accedere a tali parametri dal tuo codice. Il Listato 5-19 mostra un esempio. 
     528 
     529Listato 5-19 - Un esempio di `app.yml` per definire operazioni su carta di credito 
     530 
     531    all: 
     532      creditcards: 
     533        fake:             off 
     534        visa:             on 
     535        americanexpress:  on 
     536 
     537    dev: 
     538      creditcards: 
     539        fake:             on 
     540 
     541Per sapere se una carta di credito è accettata nell'ambiente corrente, controlla il valore di: 
     542 
     543    [php] 
     544    sfConfig::get('app_creditcards_fake'); 
     545 
     546>**TIP** 
     547>Ogni qualvolta sei tentato di definire una costante od un parametro nei tuoi script, pensa se non possa essere meglio metterlo nel file `app.yml`. È un posto molto conveniente per memorizzare i parametri dell'applicazione. 
     548 
     549Quando hai bisogno di parametri personalizzati e diventa difficile utilizzare la sintassi di `app.yml`, puoi definire una tua sintassi personalizzata. In questo caso, puoi memorizzare la configurazione in un nuovo file, interpretato da un nuovo gestore. Il Capitolo 19 fornisce maggiori informazioni sui gestori di configurazione. 
     550 
     551Suggerimenti per ottenere di più dai file di configurazione 
     552----------------------------------------------------------- 
     553 
     554C'è qualche trucco ancora da imparare prima di scrivere i tuoi file YAML. Ti servirà per evitare duplicazione della configurazione e per gestire i tuoi file YAML. 
     555 
     556### Utilizzare costanti nei file YAML 
     557 
     558Certi parametri di configurazione si basano sul valore di altri. Per evitare di duplicare i valori, symfony supporta le costanti in YAML. Quando il gestore della configurazione incontra un parametro (accessibile tramite tramite `sfConfig::get()`) in maiuscolo e racchiuso tra %, esso lo sostituisce con il suo valore effettivo. Il Listato 5-20 ne mostra un esempio. 
     559 
     560Listato 5-20 - Utilizzo delle costanti in YAML, esempio da `autoload.yml` 
     561 
     562    autoload: 
     563      symfony: 
     564        name:           symfony 
     565        path:           %SF_SYMFONY_LIB_DIR% 
     566        recursive:      on 
     567        exclude:        [vendor] 
     568 
     569Il parametro path verrà sostituito con il valore di `sfConfig::get('sf_symfony_lib_dir')`. Se vuoi che un file di configurazione si basi su di un altro, devi essere certo che quello su cui si basa venga parsato per primo (controlla i sorgenti di symfony per verificare l'ordine in cui i file di configurazione vengono parsati). `app.yml` è uno degli ultimi file di cui viene fatto il parsing, per cui si può basare su altri. 
     570 
     571### Utilizzare codice nella configurazione 
     572 
     573Potrebbe succedere che la tua configurazione si debba basare su parametri esterni (database od un altro file di configurazione). Per gestire questi casi particolari, viene fatto il parsing dei file di configurazione di symfony da PHP prima che essi vengano passi al parser YAML. Questo significa che i file YAML possono contenere codice PHP, come mostrato nel Listato 5-21. 
     574 
     575Listato 5-21 - I file YAML possono contenere codice PHP 
     576 
     577    all: 
     578      translation: 
     579        format:  <?php echo sfConfig::get('sf_i18n') == true ? 'xliff' : 'none' ?> 
     580 
     581Ma fai attenzione al fatto che il parsing di questi file viene eseguito molto presto durante il ciclo di vita di una richiesta, per cui non avrai a tua disposizione i metodi o funzioni di symfony. 
     582 
     583>**CAUTION** 
     584>Nell'ambiente di produzione la configurazione è in cache, per cui il parsing (e l'esecuzione) dei file di configurazione avviene esclusivamente dopo che la cache è stata pulita. 
     585 
     586### Navigare i tuoi file YAML personali 
     587 
     588Ogni qualvolta tu voglia leggere un file YAML direttamente, puoi usare la classe `sfYaml`. Si tratta di un parser YAML che ne trasforma i file in array associativi di PHP. Il Listato 5-22 presenta un file YAML di esempio, mentre il Listato 5-23 mostra come farne il parsing. 
     589 
     590Listato 5-22 - File di esempio `test.yml` 
     591 
     592    house: 
     593      family: 
     594        name:     Doe 
     595        parents:  [John, Jane] 
     596        children: [Paul, Mark, Simone] 
     597      address: 
     598        number:   34 
     599        street:   Main Street 
     600        city:     Nowheretown 
     601        zipcode:  12345 
     602 
     603Listato 5-23 - Utilizzo della classe `sfYaml` per trasformare il file precedente in array associativo 
     604 
     605    [php] 
     606    $test = sfYaml::load('/path/to/test.yml'); 
     607    print_r($test); 
     608 
     609    Array( 
     610      [house] => Array( 
     611        [family] => Array( 
     612          [name] => Doe 
     613          [parents] => Array( 
     614            [0] => John 
     615            [1] => Jane 
     616          ) 
     617          [children] => Array( 
     618            [0] => Paul 
     619            [1] => Mark 
     620            [2] => Simone 
     621          ) 
     622        ) 
     623        [address] => Array( 
     624          [number] => 34 
     625          [street] => Main Street 
     626          [city] => Nowheretown 
     627          [zipcode] => 12345 
     628        ) 
     629      ) 
     630    ) 
     631 
     632Riepilogo 
     633--------- 
     634 
     635Il sistema di configurazione di symfony utilizza il linguaggio YAML per poter essere semplice e leggibile. La capacità di gestire ambienti multipli e di definire insiemi di parametri tramite cascata offre grande versatilità allo sviluppatore. Alcuni dei parametri sono accessibili via codice tramite l'oggetto `sfConfig`, specialmente quelli specifici dell'applicazione memorizzati nel file `app.yml`. 
     636È vero, symfony ha molti file di configurazione, ma questo approccio lo rende molto adattabile. Ricorda che non hai bisogno di annoiarti con essi se non hai bisogno di un alto livello di personalizzazione. 
     637 
     638}}}