Author: garak
Date: 2010-02-10 12:29:36 +0100 (Wed, 10 Feb 2010)
New Revision: 27812
Modified:
doc/branches/1.4/tutorial/it/deprecated.markdown
doc/branches/1.4/tutorial/it/upgrade.markdown
doc/branches/1.4/tutorial/it/whats-new.markdown
Log:
[doc-it][1.4] minor fixes
Modified: doc/branches/1.4/tutorial/it/deprecated.markdown
===================================================================
--- doc/branches/1.4/tutorial/it/deprecated.markdown 2010-02-10 11:28:59 UTC
(rev 27811)
+++ doc/branches/1.4/tutorial/it/deprecated.markdown 2010-02-10 11:29:36 UTC
(rev 27812)
@@ -2,7 +2,7 @@
===================================
Questo documento elenca tutte le impostazioni, le classi, i metodi, le funzioni
-ed i task che sono stati deprecati o rimossi in symfony 1.3.
+e i task che sono stati deprecati o rimossi in symfony 1.3.
Plugin del Core
---------------
@@ -129,7 +129,7 @@
* `sfWidgetFormChoiceMany`, `sfWidgetFormPropelChoiceMany`,
`sfWidgetFormDoctrineChoiceMany`, `sfValidatorChoiceMany`,
`sfValidatorPropelChoiceMany`, `sfValidatorPropelDoctrineMany`: Usare le
- stesse classi, ma senza `Many` finale ed impostando l'opzione `multiple` a
+ stesse classi, ma senza `Many` finale e impostando l'opzione `multiple` a
`true`
* `SfExtensionObjectBuilder`, `SfExtensionPeerBuilder`,
@@ -173,7 +173,7 @@
di symfony era condivisa tra diversi clienti. Essendo una cattiva pratica
da
symfony 1.1 (occorre inserire la versione di symfony in ciascun progetto),
l'impostazione non ha più senso. Inoltre, quando l'impostazione è impostata
- a `on`, la verifica aggiunge anche un piccolo overhead ad ogni richiesta,
+ a `on`, la verifica aggiunge anche un piccolo overhead a ogni richiesta,
poiché ha bisogno di recuperare il contenuto di un file.
* `max_forwards`: Questa impostazione controlla il numero di rinvii
consentiti
@@ -221,7 +221,7 @@
I seguenti task sono stati rimossi in symfony 1.3:
- * `project:freeze` e `project:unfreeze`: Questi task servivano ad includere
+ * `project:freeze` e `project:unfreeze`: Questi task servivano a includere
la versione di symfony usata dal progetto nel progetto stesso. Non servono
più, perché la cosa migliore già da tempo è includere symfony nel progetto.
Inoltre, cambiando versione di symfony è ora molto semplice, dati che basta
@@ -266,7 +266,7 @@
task si basava su tale opzione, la si può aggiungere come opzione locale nella
classe del task.
-I template di Propel per l'admin generator 1.0 ed il CRUD 1.0 saranno rimossi
+I template di Propel per l'admin generator 1.0 e il CRUD 1.0 saranno rimossi
in symfony 1.4 (`plugins/sfPropelPlugin/data/generator/sfPropelAdmin/`).
Il "Dynarch calendar" (che si trova in data/web/calendar/) sarà rimosso in
Modified: doc/branches/1.4/tutorial/it/upgrade.markdown
===================================================================
--- doc/branches/1.4/tutorial/it/upgrade.markdown 2010-02-10 11:28:59 UTC
(rev 27811)
+++ doc/branches/1.4/tutorial/it/upgrade.markdown 2010-02-10 11:29:36 UTC
(rev 27812)
@@ -61,10 +61,10 @@
$ php symfony project:upgrade1.3
Il task può essere lanciato diverse volte, senza effetti collaterali.
- Ogni volta che si aggiorna ad una versione di symfony 1.3 beta / RC o all
+ Ogni volta che si aggiorna a una versione di symfony 1.3 beta / RC o all
versione finale symfony 1.3, si deve lanciare il task.
- * Occorre ricostruire i modelli ed i form, a causa di alcune modifiche
+ * Occorre ricostruire i modelli e i form, a causa di alcune modifiche
descritte più avanti:
# Doctrine
@@ -165,14 +165,14 @@
Il filtro è stato rimosso per diverse ragioni:
* Abbiamo già una soluzione migliore, semplice e più flessibile (gli
- helper `include_stylesheets()` ed `include_javascripts()`)
+ helper `include_stylesheets()` e `include_javascripts()`)
* Anche se il filtro può essere rimosso facilmente, non è semplice farlo,
- perché richiede di conoscerne l'esistenza ed il suo lavoro "dietro le
quinte"
+ perché richiede di conoscerne l'esistenza e il suo lavoro "dietro le quinte"
* L'uso degli helper fornisce un controllo più granulare su quando e dove
includere gli elementi nel layout (ad esempio, i fogli di stile nel tag
`head`
- ed i JavaScript subito prima della fine del tag `body`)
+ e i JavaScript subito prima della fine del tag `body`)
* È sempre meglio essere espliciti piuttosto che impliciti (nessuna magia e
nessun effetto indesiderato; si veda la mailing list degli utenti per
@@ -302,9 +302,9 @@
delivery_strategy: none
Con tale configurazione, i messaggi email non saranno inviati. Ovviamente,
-saranno ancora nei log ed il tester `mailer` funzionerà nei test funzionali.
+saranno ancora nei log e il tester `mailer` funzionerà nei test funzionali.
-Se invece si preferisce ricevere tutti i messaggi email ad un unico indirizzo,
+Se invece si preferisce ricevere tutti i messaggi email a un unico indirizzo,
si può usare la strategia di invio `single_address` (ad esempio per l'ambiente
`dev`):
@@ -333,7 +333,7 @@
vanno eseguite manualmente.
Se non si vogliono controllare tutti i proprio file YAML, si può forzare il
-parser YAML ad usare le specifiche YAML 1.1, usando il metodo
+parser YAML a usare le specifiche YAML 1.1, usando il metodo
`sfYaml::setSpecVersion()`:
[php]
Modified: doc/branches/1.4/tutorial/it/whats-new.markdown
===================================================================
--- doc/branches/1.4/tutorial/it/whats-new.markdown 2010-02-10 11:28:59 UTC
(rev 27811)
+++ doc/branches/1.4/tutorial/it/whats-new.markdown 2010-02-10 11:29:36 UTC
(rev 27812)
@@ -26,7 +26,7 @@
$this->getMailer()->composeAndSend('[email protected]', '[email protected]',
'Oggetto', 'Corpo');
Se si ha bisogno di maggiore flessibilità, si può anche usare il metodo
-`compose()` ed inviare in seguito. Ecco ad esempio come aggiungere un allegato
+`compose()` e inviare in seguito. Ecco ad esempio come aggiungere un allegato
al messaggio:
[php]
@@ -204,9 +204,9 @@
Il nuovo metodo `sfForm::useFields()` rimuove da un form tutti i campi non
nascosti, tranne quelli passati come parametro. A volte è più semplice
esplicitare i campi da mantenere piuttosto che eliminare tutti quelli non
-necessari. Ad esempio, quando si aggiungono nuovi campi ad un form di base,
+necessari. Ad esempio, quando si aggiungono nuovi campi a un form di base,
essi non appariranno nel form a meno che non siano esplicitamente aggiunti
-(si pensi ad un modello di form in cui si aggiungono nuove colonne alla
+(si pensi a un modello di form in cui si aggiungono nuove colonne alla
tabella relativa).
[php]
@@ -224,7 +224,7 @@
### `sfForm::getEmbeddedForm($name)`
-Ora si può accedere ad uno specifico form annidato, usando il metodo
+Ora si può accedere a uno specifico form annidato, usando il metodo
`->getEmbeddedForm()`. È stato aggiunto un paramentro per disabilitare
la ricorsione, utile se si rendono dei form annidati usando un formatter.
@@ -248,7 +248,7 @@
* `form.post_configure`: Questo evento è notificato dopo che ogni form è
configurato
- * `form.filter_values`: Questo evento filtra i parametri ed i file fusi e
+ * `form.filter_values`: Questo evento filtra i parametri e i file fusi e
quelli grezzi subito prima del bind
* `form.validation_error`: Questo evento è notificato ogni volta che un form
fallisce
@@ -323,7 +323,7 @@
di test per assicurarsi di non aver creato problemi altrove. Ma finché
i test falliti non sono sistemati, non serve eseguire di nuovo tutti gli
altri test. Da symfony 1.3/1.4, i task `test:all` e `symfony:test` hanno
un'opzione
-`--only-failed` (scorciatoia: `-f`), che forza i task ad eseguire nuovamente
+`--only-failed` (scorciatoia: `-f`), che forza i task a eseguire nuovamente
solo i test falliti durante la precedente esecuzione:
$ php symfony test:all --only-failed
@@ -539,7 +539,7 @@
### Miglioramenti a `sfTask::run()`
-Si può ora passare un array associativo di parametri ed opzioni al task
+Si può ora passare un array associativo di parametri e opzioni al task
`sfTask::run()`:
[php]
@@ -667,9 +667,9 @@
### `propel:generate-module`, `propel:generate-admin`,
`propel:generate-admin-for-route`
-The `propel:generate-module`, `propel:generate-admin`, and
-`propel:generate-admin-for-route` tasks now takes a `--actions-base-class`
option that allows
-the configuration of the actions base class for the generated modules.
+I task `propel:generate-module`, `propel:generate-admin` e
+`propel:generate-admin-for-route` ora accettano un'opzione
`--actions-base-class`, che
+consente la configurazione della classe base delle azioni per i moduli
generati.
### Comportamenti di Propel
@@ -754,7 +754,7 @@
### Colorazione dell'Otput
-Symfony prova ad indovinare se la console supporta i colori, quando si usano
+Symfony prova a indovinare se la console supporta i colori, quando si usano
gli strumenti della CLI. Ma a volte symfony si sbaglia; ad esempio quando si
usa Cygwin (poiché la colorazione è sempre spenta su Windows).
@@ -854,7 +854,7 @@
.settings:
file_link_format: txmt://open?url=file://%f&line=%l
-Il segnaposto `%f` sarà sostituito con il percorso assoluto del file ed il
+Il segnaposto `%f` sarà sostituito con il percorso assoluto del file e il
segnaposto `%l` sarà sostituito dal numero di riga.
Integrazione con Doctrine
@@ -928,7 +928,7 @@
$ php symfony doctrine:clean-model-files
-Il task confronterà i file di schema YAML con i modelli ed i file che
+Il task confronterà i file di schema YAML con i modelli e i file che
sono stati generati e determinerà quali rimuovere. Questi modelli
sono passati al task `doctrine:delete-model-files`. Una conferma
sarà richiesta prima della cancellazione effettiva.
@@ -945,7 +945,7 @@
$ php symfony doctrine:reload-data
-equivale ad eseguire questi comandi:
+equivale a eseguire questi comandi:
$ php symfony doctrine:drop-db
$ php symfony doctrine:build-db
@@ -975,7 +975,7 @@
$ php symfony doctrine:build --model --and-migrate
--and-append=data/fixtures/categories.yml
Questo costruisce il modello (`:build-model`), migra il database (`:migrate`)
-ed appende le fixture per le categorie
+e appende le fixture per le categorie
(`:data-load --append --dir=data/fixtures/categories.yml`).
Per ulteriori informazioni, si veda la pagina di aiuto del task
@@ -1001,7 +1001,7 @@
$ php symfony doctrine:generate-migration AddUserEmailColumn
--editor-cmd=mate
-Questo esempio genererà la nuova classe di migrazione ed aprirà il nuovo
+Questo esempio genererà la nuova classe di migrazione e aprirà il nuovo
file in TextMate.
#### `doctrine:generate-migrations-diff`
@@ -1121,7 +1121,7 @@
}
La personalizzazione di un form filtro è ora più facile. Per aggiungere
-un campo al filtro, basta aggiungere il widget ed un metodo per
+un campo al filtro, basta aggiungere il widget e un metodo per
processarlo.
[php]
@@ -1274,7 +1274,7 @@
### Parametri `PUT` e `DELETE`
-Quando una richiesta arriva con metodo HTTP `PUT` o `DELETE` ed il
+Quando una richiesta arriva con metodo HTTP `PUT` o `DELETE` e il
content-type impostato a `application/x-www-form-urlencoded`, symfony
ora analizza il body grezzo e rende i parametri accessibili come
normali parametri `POST`.
--
You received this message because you are subscribed to the Google Groups
"symfony SVN" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/symfony-svn?hl=en.
