Author: garak
Date: 2010-02-04 13:56:13 +0100 (Thu, 04 Feb 2010)
New Revision: 27559
Modified:
doc/branches/1.4/forms/it/01-Form-Creation.txt
doc/branches/1.4/forms/it/02-Form-Validation.txt
doc/branches/1.4/forms/it/04-Propel-Integration.txt
doc/branches/1.4/forms/it/11-Doctrine-Integration.txt
doc/branches/1.4/forms/it/A-Widgets.txt
Log:
[doc-it][1.4] minor fixes
Modified: doc/branches/1.4/forms/it/01-Form-Creation.txt
===================================================================
--- doc/branches/1.4/forms/it/01-Form-Creation.txt 2010-02-04 12:24:41 UTC
(rev 27558)
+++ doc/branches/1.4/forms/it/01-Form-Creation.txt 2010-02-04 12:56:13 UTC
(rev 27559)
@@ -6,7 +6,7 @@
form e la gestione di campi di form usando il framework per i form di symfony.
È richiesto symfony 1.1 per seguire questo libro. Si avrà anche bisogno
-di creare un progetto ed un'applicazione `frontend` per andare avanti.
+di creare un progetto e un'applicazione `frontend` per andare avanti.
Fare riferimento all'introduzione per maggiori informazioni sulla
creazione di un progetto symfony.
@@ -206,14 +206,14 @@
Possiamo vedere che il form viene mostrato con tre righe `<tr>` di
una tabella HTML. Per questo abbiamo dovuto racchiuderla in un tag
-`<table>`. Ogni riga comprende un tag `<label>` ed un tag `<input>`
+`<table>`. Ogni riga comprende un tag `<label>` e un tag `<input>`
o `<textarea>`.
### Label
Le etichette (`label`) di ogni campo sono generate automaticamente.
Per default, le label sono una trasformazione del nome del campo seguendo
-due regole: una lettera maiuscola iniziale ed un trattino basso sono
+due regole: una lettera maiuscola iniziale e un trattino basso sono
sostituiti da spazi. Se il nome del campo termina per "_id", il
suffisso è rimosso dalla label.
Esempio:
Modified: doc/branches/1.4/forms/it/02-Form-Validation.txt
===================================================================
--- doc/branches/1.4/forms/it/02-Form-Validation.txt 2010-02-04 12:24:41 UTC
(rev 27558)
+++ doc/branches/1.4/forms/it/02-Form-Validation.txt 2010-02-04 12:56:13 UTC
(rev 27559)
@@ -433,7 +433,7 @@
}
Un oggetto `User` è composto da due proprietà, il nome dell'utente
-(`name`) ed un booleano che memorizza lo stato di amministratore
+(`name`) e un booleano che memorizza lo stato di amministratore
(`is_admin`). Il metodo `setFields()` aggiorna entrambe le
proprietà. Il Listato 2-7 mostra il form relativo alla classe
`User`, che consente all'utente di modificare solo la proprietà
Modified: doc/branches/1.4/forms/it/04-Propel-Integration.txt
===================================================================
--- doc/branches/1.4/forms/it/04-Propel-Integration.txt 2010-02-04 12:24:41 UTC
(rev 27558)
+++ doc/branches/1.4/forms/it/04-Propel-Integration.txt 2010-02-04 12:56:13 UTC
(rev 27559)
@@ -64,7 +64,7 @@
Ecco le relazioni tra le tabelle:
* Relazione 1-n tra la tabella `article` e la tabella `author`:
- un articolo è scritto da uno ed un solo autore
+ un articolo è scritto da uno e un solo autore
* Relazione 1-n tra la tabella `article` e la tabella `category`:
un articolo appartiene ad una o nessuna categoria
* Relazione n-n tra le tabelle `article` e `tag`
@@ -115,7 +115,7 @@
BaseTagForm.class.php
Il task `propel:build-forms` genera due classi per ogni tabella dello
-schema, una classe base nella cartella `lib/form/base` ed una nella
+schema, una classe base nella cartella `lib/form/base` e una nella
cartella `lib/form/`. Ad esempio la tabella `author` ha le classi
generate `BaseAuthorForm` e `AuthorForm` nei file
`lib/form/base/BaseAuthorForm.class.php` e
@@ -257,7 +257,7 @@
schema: `id`, `first_name`, `last_name`, `email`.
Per ogni colonna della tabella `author`, il task `propel:build-forms`
-genera un widget ed un validatore secondo la definizione dello schema.
+genera un widget e un validatore secondo la definizione dello schema.
Il task genera sempre i validatori più sicuri possibile. Consideriamo
il campo `id`. Potremmo solo verificare se il valore è un intero valido.
Invece il validatore generato ci consente anche di validare che
@@ -440,7 +440,7 @@
</form>
>**TIP**
->L'opzione `--with-show` ci consente di generare un'azione ed un template
+>L'opzione `--with-show` ci consente di generare un'azione e un template
>che possiamo usare per vedere un oggetto (in sola lettura).
Ora si può aprire in un browser l'URL `/frontend_dev.php/author` per vedere
@@ -1038,7 +1038,7 @@
gestire gli elementi collaterali come l'invio di file.
Vediamo come allegare un file ad ogni articolo. I file sono memorizzati
-nella cartella `web/uploads` ed un riferimento al percorso del file viene
+nella cartella `web/uploads` e un riferimento al percorso del file viene
tenuto nel campo `file` della tabella `article`, come mostrato nel Listato
4-24.
Listato 4-24 - Schema per la tabella `article` con file associato
@@ -1056,13 +1056,13 @@
$ ./symfony propel:build-all
>**CAUTION**
->Ricordate che il task `propel:build-all` cancella tutte le tabelle dello
+>Ricordare che il task `propel:build-all` cancella tutte le tabelle dello
>schema e le ricrea. I dati presenti nelle tabelle sono quindi
->sovrascritti. Per questo è importante creare dei dati di test (`fixtures`)
+>sovrascritti. Per questo è importante creare dei dati di test (`fixtures`),
>che si possono ricaricare ad ogni modifica del modello.
Il Listato 4-25 mostra come modificare la classe `ArticleForm` per
-collegare un widget ed un validatore al campo `file`.
+collegare un widget e un validatore al campo `file`.
Listato 4-25 - Modifica del campo `file` del form `ArticleForm`.
Modified: doc/branches/1.4/forms/it/11-Doctrine-Integration.txt
===================================================================
--- doc/branches/1.4/forms/it/11-Doctrine-Integration.txt 2010-02-04
12:24:41 UTC (rev 27558)
+++ doc/branches/1.4/forms/it/11-Doctrine-Integration.txt 2010-02-04
12:56:13 UTC (rev 27559)
@@ -77,7 +77,7 @@
Ecco le relazioni tra le tabelle:
* Relazione 1-n tra la tabella `article` e la tabella `author`:
- un articolo è scritto da uno ed un solo autore
+ un articolo è scritto da uno e un solo autore
* Relazione 1-n tra la tabella `article` e la tabella `category`:
un articolo appartiene ad una o nessuna categoria
* Relazione n-n tra le tabelle `article` e `tag`
@@ -129,7 +129,7 @@
BaseTagForm.class.php
Il task `doctrine:build-forms` genera due classi per ogni tabella dello
-schema, una classe base nella cartella `lib/form/base` ed una nella
+schema, una classe base nella cartella `lib/form/base` e una nella
cartella `lib/form/`. Ad esempio la tabella `author` ha le classi
generate `BaseAuthorForm` e `AuthorForm` nei file
`lib/form/base/BaseAuthorForm.class.php` e
@@ -245,7 +245,7 @@
schema: `id`, `first_name`, `last_name`, `email`.
Per ogni colonna della tabella `author`, il task `doctrine:build-forms`
-genera un widget ed un validatore secondo la definizione dello schema.
+genera un widget e un validatore secondo la definizione dello schema.
Il task genera sempre i validatori più sicuri possibile. Consideriamo
il campo `id`. Potremmo solo verificare se il valore è un intero valido.
Invece il validatore generato ci consente anche di validare che
@@ -394,7 +394,7 @@
>puntare il form all'azione di modifica, senza curarsi se l'oggetto sia
>nuovo o vecchio.
-Il task genera anche tre template ed un partial: `indexSuccess`, `editSuccess`,
+Il task genera anche tre template e un partial: `indexSuccess`, `editSuccess`,
`newSuccess` e `_form`. Il template `_form` è stato generato senza usare
l'istruzione
`<?php echo $form ?>`. Possiamo modificare questo comportamento, usando
`--non-verbose-templates`:
@@ -434,7 +434,7 @@
</form>
>**TIP**
->L'opzione `--with-show` ci consente di generare un'azione ed un template
+>L'opzione `--with-show` ci consente di generare un'azione e un template
>che possiamo usare per vedere un oggetto (in sola lettura).
Ora si può aprire in un browser l'URL `/frontend_dev.php/author` per vedere
@@ -1059,7 +1059,7 @@
gestire gli elementi collaterali come l'invio di file.
Vediamo come allegare un file ad ogni articolo. I file sono memorizzati
-nella cartella `web/uploads` ed un riferimento al percorso del file viene
+nella cartella `web/uploads` e un riferimento al percorso del file viene
tenuto nel campo `file` della tabella `article`, come mostrato nel Listato
4-24.
Listato 4-24 - Schema per la tabella `article` con file associato
@@ -1077,13 +1077,13 @@
$ ./symfony doctrine:build-all
>**CAUTION**
->Ricordate che il task `doctrine:build-all` cancella tutte le tabelle dello
+>Ricordare che il task `doctrine:build-all` cancella tutte le tabelle dello
>schema e le ricrea. I dati presenti nelle tabelle sono quindi
->sovrascritti. Per questo è importante creare dei dati di test (`fixtures`)
+>sovrascritti. Per questo è importante creare dei dati di test (`fixtures`),
>che si possono ricaricare ad ogni modifica del modello.
Il Listato 4-25 mostra come modificare la classe `ArticleForm` per
-collegare un widget ed un validatore al campo `file`.
+collegare un widget e un validatore al campo `file`.
Listato 4-25 - Modifica del campo `file` del form `ArticleForm`.
Modified: doc/branches/1.4/forms/it/A-Widgets.txt
===================================================================
--- doc/branches/1.4/forms/it/A-Widgets.txt 2010-02-04 12:24:41 UTC (rev
27558)
+++ doc/branches/1.4/forms/it/A-Widgets.txt 2010-02-04 12:56:13 UTC (rev
27559)
@@ -157,7 +157,7 @@
* [`sfWidgetFormDate`](A-Widgets#chapter_a_sub_sfwidgetformdate)
* [`sfWidgetFormDateRange`](A-Widgets#chapter_a_sub_sfwidgetformdaterange)
* [`sfWidgetFormDateTime`](A-Widgets#chapter_a_sub_sfwidgetformdatetime)
- *
[`sfWidgetFormDoctrineChoice`](A-Widgets#chapter_a_sub_scelta_legata_ad_un_modello_doctrine)
+ *
[`sfWidgetFormDoctrineChoice`](A-Widgets#chapter_a_sub_scelta_legata_a_un_modello_doctrine)
* [`sfWidgetFormFilterInput`](A-Widgets#chapter_a_sub_sfwidgetformfilterinput)
* [`sfWidgetFormFilterDate`](A-Widgets#chapter_a_sub_sfwidgetformfilterdate)
* [`sfWidgetFormI18nDate`](A-Widgets#chapter_a_sub_sfwidgetformi18ndate)
@@ -175,7 +175,7 @@
*
[`sfWidgetFormInputPassword`](A-Widgets#chapter_a_sub_sfwidgetforminputpassword)
*
[`sfWidgetFormJQueryAutocompleter`](A-Widgets#chapter_a_sub_autocompletamento)
* [`sfWidgetFormJQueryDate`](A-Widgets#chapter_a_sub_sfwidgetformjquerydate)
- *
[`sfWidgetFormPropelChoice`](A-Widgets#chapter_a_sub_scelta_legata_ad_un_modello_Propel)
+ *
[`sfWidgetFormPropelChoice`](A-Widgets#chapter_a_sub_scelta_legata_a_un_modello_propel)
* [`sfWidgetFormReCaptcha`](A-Widgets#chapter_a_widget_captcha)
* [`sfWidgetFormSchema`](A-Widgets#chapter_a_sfwidgetformschema)
*
[`sfWidgetFormSchemaDecorator`](A-Widgets#chapter_a_sub_sfwidgetformschemadecorator)
@@ -264,18 +264,18 @@
| `edit_mode` | Un booleano: `true` per abilitare la modalità modifica,
`false` altrimenti
| `is_image` | Se il file è una immagine visualizzabile
| `with_delete` | Se aggiungere un checkbox di cancellazione o no
-| `delete_label` | La label delete utilizzata dal template
+| `delete_label` | La label di cancellazione utilizzata dal template
| `template` | Il template HTML da utilizzare per generare questo widget
| | I segnaposto disponibili sono:
| | * `input` (il widget di caricamento immagini)
-| | * `delete` (la checkbox di cancellazione)
+| | * `delete` (il checkbox di cancellazione)
| | * `delete_label` (il testo della label di cancellazione)
| | * `file` (il tag file)
>**CAUTION**
>Nella modalità `edit`, questo widget genera un widget aggiuntivo chiamato
->dopo l'upload di file con un widget con un suffisso "_delete". Così, quando
si crea
->un form, non dimenticate di aggiungere un validatore per questo ulteriore
campo.
+>come il widget del file da caricare, ma con un suffisso "_delete". Così,
quando si crea
+>un form, non dimenticare di aggiungere un validatore per questo ulteriore
campo.
### ~`sfWidgetFormTextarea`~
@@ -348,10 +348,10 @@
generazione a un altro widget. La costruzione è controllata da due opzioni:
`expanded` e `multiple`:
- | | `expanded` è `false` | `expanded` è `true`
- | ------------------------ | ------------------------ |
----------------------------
- | `multiple` è `false` | `sfWidgetFormSelect` |
`sfWidgetFormSelectRadio`
- | `multiple` è `true` | `sfWidgetFormSelectMany` |
`sfWidgetFormSelectCheckbox`
+ | | `expanded` è `false` | `expanded` è `true`
+ | -------------------- | ------------------------ |
----------------------------
+ | `multiple` è `false` | `sfWidgetFormSelect` | `sfWidgetFormSelectRadio`
+ | `multiple` è `true` | `sfWidgetFormSelectMany` |
`sfWidgetFormSelectCheckbox`
>**NOTE**
>~`sfWidgetFormSelect`~, ~`sfWidgetFormSelectMany`~,
@@ -472,14 +472,14 @@
I widget `sfWidgetFormSelectCheckbox` e `sfWidgetFormSelectRadio` supportano
le seguenti opzioni:
-| Opzione | Descrizione
-| ------------------ | -----------
-| `label_separator` | Il separatore da utilizzare tra il bottone input
checkbox/radiobutton e la label
-| `class` | La classe da utilizzare per il tag principale `<ul>`
-| `separator` | Il separatore da utilizzare tra ciascun bottone di
input checkbox/radio
-| `formatter` | Un callable da chiamare per formattare la scelta con
checkbox
-| | Il callable riceve il widget e l'array di input come
parametri
-| `template` | Il template da utilizzare per l'opzione di
raggruppamento in gruppi (`%group% %options%`)
+| Opzione | Descrizione
+| ----------------- | -----------
+| `label_separator` | Il separatore da utilizzare tra il bottone input
checkbox/radiobutton e la label
+| `class` | La classe da utilizzare per il tag principale `<ul>`
+| `separator` | Il separatore da utilizzare tra ciascun bottone di input
checkbox/radio
+| `formatter` | Un callable da chiamare per formattare la scelta con
checkbox
+| | Il callable riceve il widget e l'array di input come
parametri
+| `template` | Il template da utilizzare per l'opzione di
raggruppamento in gruppi (`%group% %options%`)
### Rappresentazione con doppio elenco
@@ -560,7 +560,7 @@
| `config` | Un array JavaScript che configura il widget JQuery di
autocompletamento
| `value_callback` | Una callback che converte il valore prima che venga
visualizzato
-Se le scelte sono collegate ad un modello di Propel, il
+Se le scelte sono collegate a un modello di Propel, il
widget `sfWidgetFormPropelJQueryAutocompleter` è ottimizzato per la ricerca di
chiavi esterne:
@@ -573,14 +573,14 @@
),
));
-| Opzione | Descrizione
-| ---------------- | -----------
-| `model` | La classe model (obbligatoria)
-| `method` | Il metodo da utilizzare oer convertire un oggetto in una
stringa (`__toString()` di default)
+| Opzione | Descrizione
+| -------- | -----------
+| `model` | La classe del modello (obbligatoria)
+| `method` | Il metodo da utilizzare per convertire un oggetto in una stringa
(`__toString()` di default)
-### Scelta legata ad un modello Propel
+### Scelta legata a un modello Propel
-Se le scelte sono legate ad un modello Propel (di solito quando si vuole
consentire
+Se le scelte sono legate a un modello Propel (di solito quando si vuole
consentire
all'utente di cambiare una chiave esterna), è possibile utilizzare il
widget ~`sfWidgetFormPropelChoice`~:
@@ -609,9 +609,9 @@
| `multiple` | `true` se il tag select deve consentire selezioni multiple
| `peer_method` | Il metodo peer da usare per il fetch degli oggetti
-### Scelta legata ad un modello Doctrine
+### Scelta legata a un modello Doctrine
-Se le scelte sono legate ad un modello Doctrine (di solito quando si vuole
+Se le scelte sono legate a un modello Doctrine (di solito quando si vuole
consentire all'utente di cambiare una chiave esterna), si può usare il
widget ~`sfWidgetFormDoctrineChoice`~:
@@ -654,7 +654,7 @@
>Ovviamente il formato data è protetto lato server da un validatore.
>Fortunatamente, il validatore delle date di symfony propone un validatore
>potente e molto flessibile a proposito del formato di data che è in
->grado di riconoscere ed analizzare.
+>grado di riconoscere e analizzare.
### ~`sfWidgetFormDate`~
@@ -711,7 +711,7 @@
);
Le opzioni `years`, `months` e `days` accettano un array in cui le chiavi
-sono i valori dei tag `option` ed i valori sono le stringhe mostrate
+sono i valori dei tag `option` e i valori sono le stringhe mostrate
all'utente.
### ~`sfWidgetFormTime`~
@@ -783,13 +783,13 @@
Le opzioni `hours`, `minutes` e `seconds` accettano un array in cui le
-chiavi sono i valori dei tag `option` ed i valori sono le stringhe
+chiavi sono i valori dei tag `option` e i valori sono le stringhe
mostrate all'utente.
### ~`sfWidgetFormDateTime`~
`sfWidgetFormDateTime` è un widget che mostra altri due widget: un widget
-`sfWidgetFormDate` ed uno `sfWidgetFormTime`:
+`sfWidgetFormDate` e uno `sfWidgetFormTime`:
[php]
$w = new sfWidgetFormDateTime();
@@ -833,7 +833,7 @@
A seconda della cultura, il widget riconosce anche l'ordine dei
-tre diversi tag select ed il separatore da usare tra loro.
+tre diversi tag select e il separatore da usare tra loro.
>**CAUTION**
>Questo widget dipende dal sotto-framework i18n di symfony.
@@ -843,7 +843,7 @@
`sfWidgetFormI18nTime` estende il widget standard `sfWidgetFormTime`.
Secondo la cultura passata come opzione, il widget conosce l'ordine
-dei tre diversi select ed il separatore da usare tra loro:
+dei tre diversi select e il separatore da usare tra loro:
[php]
$w = new sfWidgetFormI18nTime(array('culture' => 'ar'));
@@ -856,7 +856,7 @@
### ~`sfWidgetFormI18nDateTime`~
`sfWidgetFormI18nDateTime` è un widget che mostra altri due a widget:
-un widget `sfWidgetFormI18nDate` ed uno `sfWidgetFormI18nTime`.
+un widget `sfWidgetFormI18nDate` e uno `sfWidgetFormI18nTime`.
>**CAUTION**
>Questo widget dipende dal sotto-framework i18n di symfony.
@@ -910,13 +910,13 @@
>**CAUTION**
>Questo widget fa parte del plugin `sfFormExtraPlugin`. Siccome
>JQuery e JQuery UI non sono distribuiti con `sfFormExtraPlugin`, occorre
->installarli ed includerli manualmente.
+>installarli e includerli manualmente.
-| Opzione | Descrizione
-| ----------- | -----------
-| `image` | Il percorso dell'immagine per rappresentare il widget (`false`
di default)
-| `config` | Un array JavaScript che configura il widget data di JQuery
-| `culture` | La cultura dell'utente
+| Opzione | Descrizione
+| ---------- | -----------
+| `image` | Il percorso dell'immagine per rappresentare il widget (`false`
di default)
+| `config` | Un array JavaScript che configura il widget data di JQuery
+| `culture` | La cultura dell'utente
Widget I18n
-----------
@@ -1125,7 +1125,7 @@
>**CAUTION**
>Quando uno schema di widget è contenuto in un form, il form
->dà accesso ad un campo "bound" nel template, non al widget
+>dà accesso a un campo "bound" nel template, non al widget
>stesso. Si veda il capitolo del libro dei form per ulteriori
>informazioni.
--
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.
