Development

Documentation/hu_HU/forms_book/1.1/01-Form-Creation (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of Documentation/hu_HU/forms_book/1.1/01-Form-Creation

Show
Ignore:
Author:
blerou (IP: 89.134.198.125)
Timestamp:
06/27/08 22:33:58 (9 years ago)
Comment:

piszkozat, r9798

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/hu_HU/forms_book/1.1/01-Form-Creation

    v0 v1  
     1{{{ 
     2#!WikiMarkdown 
     3 
     41. fejezet - Űrlap készítés 
     5=========================== 
     6 
     7Egy űrlap bizonyos mezők (rejtett, beviteli, szövegdoboz, lenyíló list, ...) összessége. Ebben a fejezetben az űrlap készítését és űrlapmezők kezelését mutatjuk be az symfony űrlap keretrendszerének segítségével. 
     8 
     9A következő fejezetekben található leírás a symfony 1.1 verziójáról szól. Szükség lesz még egy projektre és azon belül egy `frontend` alkalmazásra. Symfony projekt készítéséről további információ a könyv ide vonatkozó fejezetében található. 
     10 
     11Előkészítés 
     12----------- 
     13 
     14Egy kapcsolat űrlap felvételével kezdjük. 
     15 
     161-1 ábra mutatja az űrlapot, amin keresztül a felhasználó üzenetet küldhet nekünk. 
     17 
     181-1 ábra - Kapcsolat űrlap 
     19 
     20![Kapcsolat űrlap](/images/forms_book/en/01_01.png "Kapcsolat űrlap") 
     21 
     22Három mezőt használunk az űrlapon: a felhasználó nevét, az email címét és az üzenetet, amit elküld nekünk. Ezután egyszerűen megjelenítjük az elküldött adatokat, ahogy az 1-2 ábrán látható. 
     23 
     241-2 ábra - Üzenet oldal 
     25 
     26![Üzenet oldal](/images/forms_book/en/01_02.png "Üzenet oldal") 
     27 
     281-3 ábra - a felhasználó és az alkalmazás közötti kölcsönhatást mutatja 
     29 
     30Figure 1-3 - Kölcsönhatás a felhasználóval 
     31 
     32![Kölcsönhatás a felhasználóval séma](/images/forms_book/en/01_03.png "Kölcsönhatás a felhasználóval séma") 
     33 
     34Widgetek 
     35-------- 
     36 
     37### `sfForm` és `sfWidget` osztályok 
     38 
     39Az űrlapot mezők alkotják, melyeket a felhasználó tölt ki adatokkal. A symfonyban az űrlap egy objektum, mely az `sfForm` osztályból származik. Példánkban létrehoztunk egy `ContactForm` osztályt, melynek őse az `sfForm`. Az `sfForm` minden űrlap ősosztálya. Az `sfForm` teszi lehetővé űrlapjaink egyszerű kezelését és konfigurálását. 
     40 
     41>**Note** 
     42>Az `sfForm` osztály minden űrlap ősosztálya, mely lehetővé teszi azok egyszerű kezelését és konfigurálást. 
     43 
     44Az űrlaphoz a `configure()` metóduson keresztül adhatunk **widget**eket. 
     45 
     46Egy **widget** egy űrlap mezőt ábrázol. Példánknál maradva három widgetre lesz szükségünk a három mező ábrázolásához: `name`, `email` és `message`. Az 1-1 jegyzet mutatja be a `ContactForm` első megvalósítását. 
     47 
     481-1 jegyzet - `ContactForm` osztály három mezővel 
     49 
     50    [php] 
     51    // lib/form/ContactForm.class.php 
     52    class ContactForm extends sfForm 
     53    { 
     54      public function configure() 
     55      { 
     56        $this->setWidgets(array( 
     57          'name'    => new sfWidgetFormInput(), 
     58          'email'   => new sfWidgetFormInput(), 
     59          'message' => new sfWidgetFormTextarea(), 
     60        )); 
     61      } 
     62    } 
     63 
     64A widgetek a `configure()` metóduson belül vannak definiálva. Ez a metódus automatikusan meghívásra kerül az `sfForm` osztály konstruktorában. 
     65 
     66A `setWidgets()` metódussal lehet az űrlapon használt widgeteket definiálni. A `setWidgets()` metódus egy asszociatív tömböt vár, ahol a kulcsok jelölik az egyes mezők nevét, az értékek pedig a widget objektumokat. Minden widget egy objektum, melynek az `sfWidget` osztály az őse. Példánkban két típusú widgetet használunk: 
     67 
     68  * `sfWidgetFormInput`  : ez a widget egy `input` mezőt ábrázol 
     69  * `sfWidgetFormTextarea`: ez a widget egy szövegdobozt (`textarea`) ábrázol 
     70 
     71>**Note** 
     72>Megegyezés szerint a form osztályok a `lib/form/` könyvtárban találhatók. Igazság szerint az űrlapok bárhol tárolhatók, ahol a symfony autoloading mechanizmusa megtalálja azokat, de később látni fogjuk, hogy a rendszer a `lib/form/` könyvtárba hozza létre a model objektumokból generált űrlapokat. 
     73### Displaying the Form 
     74### Űrlapok megjelenítése 
     75 
     76Űrlapunk használatra készen áll. Már csak létre kell hozni egy modult, hogy megjelenítsük azt. 
     77 
     78    $ cd ~/PATH/TO/THE/PROJECT 
     79    $ php symfony generate:module frontend contact 
     80 
     81A `contact` modul `index` action-ét módosítsuk, hogy a form példányt átadjuk a templatenek, ahogy az 1-2 jegyzeten látható. 
     82 
     831-2 jegyzet - Action osztály a `contact` modulban 
     84 
     85    [php] 
     86    // apps/frontend/modules/contact/actions/actions.class.php 
     87    class contactActions extends sfActions 
     88    { 
     89      public function executeIndex() 
     90      { 
     91        $this->form = new ContactForm(); 
     92      } 
     93    } 
     94 
     95Mikor létrehozzuk az űrlapot, a korábban definiált `configure()` metódus automatikusan lefut. 
     96 
     97Már csak egy templatere van szükségünk, hogy megjelenjen űrlapunk. 
     98 
     991-3 jegyzet - Űrlap megjelenítése templateben 
     100 
     101    [php] 
     102    // apps/frontend/modules/contact/templates/indexSuccess.php 
     103    <form action="<?php echo url_for('contact/submit') ?>" method="POST"> 
     104      <table> 
     105        <?php echo $form ?> 
     106        <tr> 
     107          <td colspan="2"> 
     108            <input type="submit" /> 
     109          </td> 
     110        </tr> 
     111      </table> 
     112    </form> 
     113 
     114Az űrlap csak a felhasználó számára fontos információt kezeli. Az `indexSuccess` templateben a `<?php echo $form ?>` sor csak három mezőt jelenít meg. A többi elemet, mint a `form` tag és a `submit` gomb magunknak kell hozzáadni. Első pillantásra ez nem túl nyilvánvaló, viszont később látni fogjuk milyen hasznos, ha az űrlapjaink között átfedések vannak. 
     115 
     116A `<?php echo $form ?>` használata rendkívül hasznos űrlap prototípusok készítésénél. Lehetővé teszi, hogy a fejlesztő az üzleti logikára koncentráljon anélkül, hogy a megjelenés miatt keljen aggódnia. A 3. fejezet mutatja be az űrlapok megjelenésének testreszabását. 
     117 
     118>**Note** 
     119Mikor a `<?php echo $form ?>` formát használjuk megjelenítésre, a PHP a `$form` objektum szöveges alakját jeleníti meg. Az objektum szöveggé konvertálásakor a PHP a `__toString()` magic metódust próbálja meg futtatni. Minden widget megvalósítja ezt, hogy az objektum HTML alakját vissza tudja adni. A `<?php echo $form ?>` meghívása egyenértékű a `<?php echo $form->__toString() ?>` hívással. 
     120 
     121Most már meg tudjuk jeleníteni az űrlapot a böngészőben (1-4 ábra) és ellenőrizhetük az eredményt a `contact/index` action begépelésével (`/frontend_dev.php/contact`). 
     122 
     123Figure 1-4 - Generated Contact Form 
     1241-4 ábra - Generált kapcsolat űrlap 
     125 
     126![Generált kapcsolat űrlap](/images/forms_book/en/01_04.png "Generált kapcsolat űrlap") 
     127 
     128Listing 1-4 Shows the generated code by the template. 
     1291-4 jegyzet A template által generált kód 
     130 
     131    [html] 
     132    <form action="/frontend_dev.php/contact/submit" method="POST"> 
     133      <table> 
     134         
     135        <!-- A <?php echo $form ?> által generált űrlap kezdete --> 
     136        <tr> 
     137          <th><label for="name">Name</label></th> 
     138          <td><input type="text" name="name" id="name" /></td> 
     139        </tr> 
     140        <tr> 
     141          <th><label for="email">Email</label></th> 
     142          <td><input type="text" name="email" id="email" /></td> 
     143        </tr> 
     144        <tr> 
     145          <th><label for="message">Message</label></th> 
     146          <td><textarea rows="4" cols="30" name="message" id="message"></textarea></td> 
     147        </tr> 
     148        <!-- A <?php echo $form ?> által generált űrlap vége --> 
     149 
     150        <tr> 
     151          <td colspan="2"> 
     152            <input type="submit" /> 
     153          </td> 
     154        </tr> 
     155      </table> 
     156    </form> 
     157 
     158Azt láthatjuk, hogy az űrlap egy HTML táblázat három `<tr>` sorban jelenik meg. Ezért tettük az egészet egy `<table>` tagba. Minden sor tartalmaz egy `<label>` taget és egy űrlap taget (`<input>` vagy `<textarea>`). 
     159 
     160### Cimkék 
     161 
     162Minden mezőhöz automatikusan létrejön egy cimke. Alapbeállításban a cimke nevet a mező nevéből képzi a rendszer a következő szabályok alapján: az első betű nagy betű, az aláhúzások cseréje szóközökkel. 
     163Példa: 
     164 
     165 
     166    [php] 
     167    $this->setWidgets(array( 
     168      'first_name' => new sfWidgetFormInput(), // generált cimke: "First name" 
     169      'last_name'  => new sfWidgetFormInput(), // generált cimke: "Last name" 
     170    )); 
     171  
     172Habár az automatikus cimke generálás nagyon hasznos, a keretrendszer megengedi a cimkék testreszabását is a `setLabels()` metóduson keresztül: 
     173 
     174    [php] 
     175    $this->widgetSchema->setLabels(array( 
     176      'name'    => 'Your name', 
     177      'email'   => 'Your email address', 
     178      'message' => 'Your message', 
     179    )); 
     180 
     181A `setLabel()` metóduson keresztül az egyes mezők cimkéje is módosítható: 
     182 
     183    [php] 
     184    $this->widgetSchema->setLabel('email', 'Your email address'); 
     185 
     186Végül, a 3. fejezetben látni fogjuk, hogyan terjeszthetjük ki a cimkéket a templatekben, tovább finomítva az űrlapon. 
     187 
     188>**Sidebar** 
     189>Widget Séma 
     190> 
     191>Mikor a `setWidgets()` metódust használjuk, a symfony létrehoz egy `sfWidgetFormSchema` objektumot. Ez az objetum is egy widget, amely widgetek egy halmazát ábrázolja. A `ContactForm` űrlapunkban használtunk a `setWidgets()` metódust. Ez egyenértékű a következő kóddal: 
     192> 
     193>     [php] 
     194>     $this->setWidgetSchema(new sfWidgetFormSchema(array( 
     195>       'name'    => new sfWidgetFormInput(), 
     196>       'email'   => new sfWidgetFormInput(), 
     197>       'message' => new sfWidgetFormTextarea(), 
     198>     ))); 
     199> 
     200>     // majdnem egyenértékű a : 
     201> 
     202>     $this->widgetSchema = new sfWidgetFormSchema(array( 
     203>       'name'    => new sfWidgetFormInput(), 
     204>       'email'   => new sfWidgetFormInput(), 
     205>       'message' => new sfWidgetFormTextarea(), 
     206>     )); 
     207> 
     208>The `setLabels()` method is applied to a collection of widgets included in the `widgetSchema` object . 
     209>A `setLabels()` metódus használatakor azt widgetek egy csoportján alkalmazzuk, melyeket a `widgetSchema` objektum tartalmmazza. 
     210> 
     211>Az 5. fejezetben látjuk majd, hogy a "schema widget" használata mennyire leegyszerűsíti az egymást átfedő űrlapok használatát. 
     212 
     213### A generált táblázatokon túl 
     214 
     215Even if the form display is an HTML table by default, the layout format can be changed. These different types of layout formats are defined in classes inheriting from `sfWidgetFormSchemaFormatter`. By default, a form uses the `table` format as defined in the `sfWidgetFormSchemaFormatterTable` class. You can also use the `list` format: 
     216Habár az űrlap HTML táblázatként jelenik meg alapból, a layout megváltoztatható.  
     217 
     218    [php] 
     219    class ContactForm extends sfForm 
     220    { 
     221      public function configure() 
     222      { 
     223        $this->setWidgets(array( 
     224          'name'    => new sfWidgetFormInput(), 
     225          'email'   => new sfWidgetFormInput(), 
     226          'message' => new sfWidgetFormTextarea(), 
     227        )); 
     228 
     229        $this->widgetSchema->setFormFormatterName('list'); 
     230      } 
     231    } 
     232 
     233Those two formats come by default and we will see in Chapter 5 how to create your own format classes. Now that we know how to display a form, let's see how to manage the submission. 
     234 
     235### Submitting the Form 
     236 
     237When we created a template to display a form, we used the internal URL `contact/submit` in the `form` tag to submit the form. We now need to add the `submit` action in the `contact` module. Listing 1-5 shows how an action can get the information from the user and redirect to the `thank you` page where we just display this information back to the user. 
     238 
     239Listing 1-5 - Use of the `submit` action in the `contact` module 
     240 
     241    [php] 
     242    public function executeSubmit($request) 
     243    { 
     244      $this->forward404Unless($request->isMethod('post')); 
     245 
     246      $params = array( 
     247        'name'    => $request->getParameter('name'), 
     248        'email'   => $request->getParameter('email'), 
     249        'message' => $request->getParameter('message'), 
     250      ); 
     251 
     252      $this->redirect('contact/thankyou?'.http_build_query($params)); 
     253    } 
     254 
     255    public function executeThankyou() 
     256    { 
     257    } 
     258 
     259    // apps/frontend/modules/contact/templates/thankyouSuccess.php 
     260    <ul> 
     261      <li>Name:    <?php echo $sf_params->get('name') ?></li> 
     262      <li>Email:   <?php echo $sf_params->get('email') ?></li> 
     263      <li>Message: <?php echo $sf_params->get('message') ?></li> 
     264    </ul> 
     265 
     266>**Note** 
     267>`http_build_query` is a built-in PHP function that generates a URL-encoded query string from an array of parameters. 
     268 
     269`executeSubmit()` method executes three actions: 
     270 
     271  * For security reasons, we check that the page has been submitted using the HTTP method `POST`. If not sent using the `POST` method then the user is redirected to a 404 page. In the `indexSuccess` template, we declared the submit method as `POST` (`<form ... method="POST">`): 
     272 
     273        [php] 
     274        $this->forward404Unless($request->isMethod('post')); 
     275 
     276  * Next we get the values from the user input to store them in the `params` table: 
     277 
     278        [php] 
     279        $params = array( 
     280          'name'    => $request->getParameter('name'), 
     281          'email'   => $request->getParameter('email'), 
     282          'message' => $request->getParameter('message'), 
     283        ); 
     284 
     285  * Finally, we redirect the user to a Thank you page  (`contact/thankyou`) to display his information: 
     286 
     287        [php] 
     288        $this->redirect('contact/thankyou?'.http_build_query($params)); 
     289 
     290Instead of redirecting the user to another page, we could have created a `submitSuccess.php` template. While it is possible, it is better practice to always redirect the user after a request with the `POST` method: 
     291 
     292  * This prevents the form from being submitted again if the user reloads the Thank you page. 
     293 
     294  * The user can also click on the back button without getting the pop-up to submit the form again. 
     295 
     296>**Tip** 
     297>You might have noticed that `executeSubmit()` is different from `executeIndex()`. When calling these methods symfony passes the current `sfRequest` object as the first argument to the `executeXXX()` methods. With PHP, you do not have to collect all parameters, that is why we did not define the `request` variable in `executeIndex()` since we do not need it. 
     298 
     299Figure 1-5 shows the workflow of methods when interacting with the user. 
     300 
     301Figure 1-5 - Methods workflow 
     302 
     303![Methods workflow](/images/forms_book/en/01_05.png "Methods workflow") 
     304 
     305>**Note** 
     306>When redisplaying the user input in the template, we run the risk of a XSS (Cross-Site Scripting) attack. You can find further information on how to prevent the XSS risk by implementing an escaping strategy in the [Inside the View Layer](http://www.symfony-project.org/book/1_1/07-Inside-the-View-Layer#Output%20Escaping) chapter of "The Definitive Guide to symfony" book. 
     307 
     308After you submit the form you should now see the page from Figure 1-6. 
     309 
     310Figure 1-6 - Page displayed after submitting the form 
     311 
     312![Page displayed after submitting the form](/images/forms_book/en/01_06.png "Page displayed after submitting the form") 
     313 
     314Instead of creating the `params` array, it would be easier to get the information from the user directly in an array. Listing 1-6 modifies the `name` HTML attribute from widgets to store the field values in the `contact` array. 
     315 
     316Listing 1-6 - Modification of the `name` HTML attribute from widgets 
     317 
     318    [php] 
     319    class ContactForm extends sfForm 
     320    { 
     321      public function configure() 
     322      { 
     323        $this->setWidgets(array( 
     324          'name'    => new sfWidgetFormInput(), 
     325          'email'   => new sfWidgetFormInput(), 
     326          'message' => new sfWidgetFormTextarea(), 
     327        )); 
     328 
     329        $this->widgetSchema->setNameFormat('contact[%s]'); 
     330      } 
     331    } 
     332 
     333Calling `setNameFormat()` allows us to modify the `name` HTML attribute for all widgets. `%s` will automatically be replaced by the name of the field when generating the form. For example, the `name` attribute will then be `contact[email]` for the `email` field. PHP automatically creates an array with the values of a request including a `contact[email]` format. This way the field values will be available in the `contact` array. 
     334 
     335We can now directly get the `contact` array from the `request` object as shown in Listing 1-7. 
     336 
     337Listing 1-7 - New format of the `name` attributes in the action widgets 
     338 
     339    [php] 
     340    public function executeSubmit($request) 
     341    { 
     342      $this->forward404Unless($request->isMethod('post')); 
     343 
     344      $this->redirect('contact/thankyou?'.http_build_query($request->getParameter('contact'))); 
     345    } 
     346 
     347When displaying the HTML source of the form, you can see that symfony has generated a `name` attribute depending not only on the field name and format, but also an `id` attribute. The `id` attribute is automatically created from the `name` attribute by replacing the forbidden characters by underscores (`_`): 
     348 
     349  | **Name**  | **Attribute `name`** | **Attribute `id`**  | 
     350  | --------- | -------------------- | ------------------- | 
     351  | name      | contact[name]        | contact_name        | 
     352  | email     | contact[email]       | contact_email       | 
     353  | message   | contact[message]     | contact_message     | 
     354 
     355### Another solution 
     356 
     357In this example, we used two actions to manage the form: `index` for the display, `submit` for the submit. Since the form is displayed with the `GET` method and submitted with the `POST` method, we can also merge the two methods in the `index` method as shown in Listing 1-8. 
     358 
     359Listing 1-8 - Merging of the two actions used in the form 
     360 
     361    [php] 
     362    class contactActions extends sfActions 
     363    { 
     364      public function executeIndex($request) 
     365      { 
     366        $this->form = new ContactForm(); 
     367 
     368        if ($request->isMethod('post')) 
     369        { 
     370          $this->redirect('contact/thankyou?'.http_build_query($request->getParameter('contact'))); 
     371        } 
     372      } 
     373    } 
     374 
     375You can change the form method in the `indexSuccess.php` template by changing the `form` method attribute: 
     376 
     377    [php] 
     378    <form action="<?php echo url_for('contact/index') ?>" method="POST"> 
     379 
     380As we will see later, we prefer to use this syntax since it is shorter and makes the code more coherent and understandable. 
     381 
     382Configuring the Widgets 
     383----------------------- 
     384 
     385### Widgets options 
     386 
     387If a website is managed by several webmasters, we would certainly like to add a drop-down list with themes in order to redirect the message according to what is asked (Figure 1-7). Listing 1-9 adds a `subject` with a drop-down list using the `sfWidgetFormSelect` widget. 
     388 
     389Figure 1-7 - Adding a `subject` Field to the Form 
     390 
     391![Adding a `subject` Field to the Form](/images/forms_book/en/01_07.png "Adding a `subject` Field to the Form") 
     392 
     393Listing 1-9 - Adding a `subject` Field to the Form 
     394 
     395    [php] 
     396    class ContactForm extends sfForm 
     397    { 
     398      protected static $subjects = array('Subject A', 'Subject B', 'Subject C'); 
     399 
     400      public function configure() 
     401      { 
     402        $this->setWidgets(array( 
     403          'name'    => new sfWidgetFormInput(), 
     404          'email'   => new sfWidgetFormInput(), 
     405          'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects)), 
     406          'message' => new sfWidgetFormTextarea(), 
     407        )); 
     408 
     409        $this->widgetSchema->setNameFormat('contact[%s]'); 
     410      } 
     411    } 
     412 
     413>**SIDEBAR** 
     414>The `choices` option of the `sfWidgetFormSelect` Widget 
     415> 
     416>PHP does not make any distinction between an array and an associative array, so the array we used for the subject list is identical to the following code: 
     417> 
     418>     [php] 
     419>     $subjects = array(0 => 'Subject A', 1 => 'Subject B', 2 => 'Subject C'); 
     420> 
     421>The generated widget takes the array key as the `value` attribute of the `option` tag, and the related value as content of the tag: 
     422> 
     423>     [php] 
     424>     <select name="contact[subject]" id="contact_subject"> 
     425>       <option value="0">Subject A</option> 
     426>       <option value="1">Subject B</option> 
     427>       <option value="2">Subject C</option> 
     428>     </select> 
     429> 
     430>In order to change the `value` attributes, we just have to define the array keys: 
     431> 
     432>     [php] 
     433>     $subjects = array('A' => 'Subject A', 'B' => 'Subject B', 'C' => 'Subject C'); 
     434> 
     435>Which generates the HTML template: 
     436> 
     437>     [php] 
     438>     <select name="contact[subject]" id="contact_subject"> 
     439>       <option value="A">Subject A</option> 
     440>       <option value="B">Subject B</option> 
     441>       <option value="C">Subject C</option> 
     442>     </select> 
     443 
     444The `sfWidgetFormSelect' widget, like all widgets, takes a list of options as the first argument. An option may be mandatory or optional. The `sfWidgetFormSelect` widget has a mandatory option, `choices`. Here are the available options for the widgets we already used: 
     445 
     446  | **Widget**             | **Mandatory Options** | **Additional Options**           | 
     447  | ---------------------- | --------------------- | -------------------------------- | 
     448  | `sfWidgetFormInput`    | -                     | `type` (default to `text`)       | 
     449  |                        |                       | `is_hidden` (default to `false`) | 
     450  | `sfWidgetFormSelect`   | `choices`             | `multiple` (default to `false`)  | 
     451  | `sfWidgetFormTextarea` | -                     | -                                | 
     452 
     453>**Tip** 
     454>If you want to know all of the options for a widget, you can refer to the complete API documentation available online at  ([http://www.symfony-project.org/api/1_1/](http://www.symfony-project.org/api/1_1/)). All of the options are explained, as well as the additional options default values. For instance, all of the options for the `sfWidgetFormSelect` are available here: ([http://www.symfony-project.org/api/1_1/sfWidgetFormSelect](http://www.symfony-project.org/api/1_1/sfWidgetFormSelect)). 
     455 
     456### The Widgets HTML Attributes 
     457 
     458Each widget also takes a list of HTML attributes as second optional argument. This is very helpful to define default HTML attributes for the generated form tag. Listing 1-10 shows how to add a `class` attribute to the `email` field. 
     459 
     460Listing 1-10 - Defining Attributes for a Widget 
     461 
     462    [php] 
     463    $emailWidget = new sfWidgetFormInput(array(), array('class' => 'email')); 
     464 
     465    // Generated HTML 
     466    <input type="text" name="contact[email]" class="email" id="contact_email" /> 
     467 
     468HTML attributes also allow us to override the automatically generated identifier, as shown in Listing 1-11. 
     469 
     470Listing 1-11 - Overriding the `id` Attribute 
     471 
     472    [php] 
     473    $emailWidget = new sfWidgetFormInput(array(), array('class' => 'email', 'id' => 'email')); 
     474 
     475    // Generated HTML 
     476    <input type="text" name="contact[email]" class="email" id="email" /> 
     477 
     478It is even possible to set default values to the fields using the `value` attribute as Listing 1-12 shows. 
     479 
     480Listing 1-12 - Widgets Default Values via HTML Attributes 
     481 
     482    [php] 
     483    $emailWidget = new sfWidgetFormInput(array(), array('value' => 'Your Email Here')); 
     484 
     485    // Generated HTML 
     486    <input type="text" name="contact[email]" value="Your Email Here" id="contact_email" /> 
     487 
     488This option works for `input` widgets, but is hard to carry through with `checkbox` or `radio` widgets, and even impossible with a `textarea` widget. The `sfForm` class offers specific methods to define default values for each field in a uniform way for any type of widget. 
     489 
     490 
     491>**Note** 
     492>We recommend to define HTML attributes inside the template and not in the form itself (even if it is possible) to preserve the layers of separation as we will see in Chapter three. 
     493 
     494### Defining Default Values For Fields 
     495 
     496It is often useful to define a default value for each field. For instance, when we display a help message in the field that disappears when the user focuses on the field. Listing 1-13 shows how to define default values via the `setDefault()` and `setDefaults()` methods. 
     497 
     498Listing 1-13 - Default Values of the Widgets via the `setDefault()` and `setDefaults()` Methods 
     499 
     500    [php] 
     501    class ContactForm extends sfForm 
     502    { 
     503      public function configure() 
     504      { 
     505        // ... 
     506 
     507        $this->setDefault('email', 'Your Email Here'); 
     508 
     509        $this->setDefaults(array('email' => 'Your Email Here', 'name' => 'Your Name Here')); 
     510      } 
     511    } 
     512 
     513The `setDefault()` and `setDefaults()` methods are very helpful to define identical default values for every instance of the same form class. If we want to modify an existing object using a form, the default values will depend on the instance, therefore they must be dynamic. Listing 1-14 shows the `sfForm` constructor has a first argument that set default values dynamically. 
     514 
     515Listing 1-14 - Default Values of the Widgets via the Constructor of `sfForm` 
     516 
     517    [php] 
     518    public function executeIndex($request) 
     519    { 
     520      $this->form = new ContactForm(array('email' => 'Your Email Here', 'name' => 'Your Name Here')); 
     521 
     522      // ... 
     523    } 
     524 
     525>**SIDEBAR** 
     526>Protection XSS (Cross-Site Scripting) 
     527> 
     528>When setting HTML attributes for widgets, or defining default values, the `sfForm` class automatically protects these values against XSS attacks during the generation of the HTML code. This protection does not depend on the `escaping_strategy` configuration of the `settings.yml` file. If a content has already been protected by another method, the protection will not be applied again. 
     529> 
     530>It also protects the `'` and `"` characters that might invalidate the generated HTML. 
     531> 
     532>Here is an example of this protection: 
     533> 
     534>     [php] 
     535>     $emailWidget = new sfWidgetFormInput(array(), array( 
     536>       'value' => 'Hello "World!"', 
     537>       'class' => '<script>alert("foo")</script>', 
     538>     )); 
     539>      
     540>     // Generated HTML 
     541>     <input 
     542>       value="Hello &quot;World!&quot;" 
     543>       class="&lt;script&gt;alert(&quot;foo&quot;)&lt;/script&gt;" 
     544>       type="text" name="contact[email]" id="contact_email" 
     545>     /> 
     546 
     547}}} 
     548 
     549,,Fordította: Sulik Szabolcs,,