Changeset 10268
- Timestamp:
- 07/13/08 23:32:00 (2 months ago)
- Files:
Legend:
- Unmodified
- Added
- Removed
- Modified
- Copied
- Moved
doc/branches/1.1/forms_book/hu/02-Form-Validation.txt
r10233 r10268 21 21 22 22 >**Note** 23 >Miért szükséges ellenőrizni a `subject` mezőt? A `<select>` tag előre definiált értékekhez köti a felhasználót. Egy átlagos felhasználó valóban csak a listában szereplő értékek közül tud választani, ám más érték ek is elküdhető olyan eszközökkel, mint például a Firefox Developer Toolbar, vagy tetszőleges kérést lehet szimulálni olyan eszközökkel, mint a `curl` vagy a `wget`.23 >Miért szükséges ellenőrizni a `subject` mezőt? A `<select>` tag előre definiált értékekhez köti a felhasználót. Egy átlagos felhasználó valóban csak a listában szereplő értékek közül tud választani, ám más érték is elküdhető olyan eszközzel, mint például a Firefox Developer Toolbar, vagy tetszőleges kérést lehet szimulálni olyan eszközökkel, mint a `curl` vagy a `wget`. 24 24 25 25 2-1 melléklet bemutatja az 1. fejezetben használt templatet. … … 40 40 </form> 41 41 42 A 2-2 ábrán látható, hogyan törik meg az interakció az alkalmazás és a felhasználó között. Az első lépésben megjelenik az űrlap. Majd a felhasználó elküldi azt. Ezután amennyiben az adatok megfelelőek átkerül a köszönet oldalra, vagy érvénytelen adat aok megadásakor újra megjelenik az űrlap a hibaüzenetekkel együtt.42 A 2-2 ábrán látható, hogyan törik meg az interakció az alkalmazás és a felhasználó között. Az első lépésben megjelenik az űrlap. Majd a felhasználó elküldi azt. Ezután amennyiben az adatok megfelelőek átkerül a köszönet oldalra, vagy érvénytelen adatok megadásakor újra megjelenik az űrlap a hibaüzenetekkel együtt. 43 43 44 44 2-2 ábra - Interakció az alkalmazás és a felhasználó között … … 49 49 ----------- 50 50 51 Egy symfony űrlap mezők összessége. Minden egyes mezőt egyedi név azonosít, ahogy azt az 1. fejezetben láthattuk. Minden mezőhöz egy widgetet kapcsoltunk a megjelenésük sorrendjében , most pedig lássuk hogyan érvényesíthetjük a mezők tartalmát.51 Egy symfony űrlap mezők összessége. Minden egyes mezőt egyedi név azonosít, ahogy azt az 1. fejezetben láthattuk. Minden mezőhöz egy widgetet kapcsoltunk a megjelenésük sorrendjében. Most pedig lássuk hogyan érvényesíthetjük a mezők tartalmát. 52 52 53 53 ### Az `sfValidatorBase` osztály 54 54 55 Minden egyes mező érvényesítéséért objektumok felelnek, amelyek az `sfValidatorBase` osztály az őse. Azért, hogy érvényesíthessük a kapcsolat űrlap adatait, minden egyes mezőhöz (`name`, `email`, `subject` és `message`) meg kell adnunk a megfelelő validator objektumokat. Ezt az űrlap osztályban a `setValidators()` metódus segítségével tehetjük meg, ahogy az a 2-2 mellékleten látható.55 Minden egyes mező érvényesítéséért objektumok felelnek, amelyek az `sfValidatorBase` osztály leszármazottai. Azért, hogy érvényesíthessük a kapcsolat űrlap adatait, minden egyes mezőhöz (`name`, `email`, `subject` és `message`) meg kell adnunk a megfelelő validator objektumokat. Ezt az űrlap osztályban a `setValidators()` metódus segítségével tehetjük meg, ahogy az a 2-2 mellékleten látható. 56 56 57 57 2-2 melléklet - Validatorok felvétele a `ContactForm` osztályban … … 88 88 * `sfValidatorChoice`: egy előre definiált listában szereplő értékek alapján érvényesít 89 89 90 Minden validator az első paraméterben az opciók listáját fogadja. A widgetekhez hasonlóan bizonyos opciók kötelezőek, mások opcionálisak. Például az `sfValidatorChoice` validator egy kötelező opciót vár, ez a `choices`. Minden validatornak megadható még a `required` és a `trim` opció, mely az `sfValidatorBase` osztályban vandefiniálva:90 Minden validator az első paraméterben az opciók listáját fogadja. A widgetekhez hasonlóan bizonyos opciók kötelezőek, mások opcionálisak. Például az `sfValidatorChoice` validator egy kötelező opciót vár, ez a `choices`. Minden validatornak megadható még a `required` és a `trim` opció, amelyek az `sfValidatorBase` osztályban vannak definiálva: 91 91 92 92 | **Opció** | **Alapértelmezett érték** | **Leírás** … … 104 104 | sfValidatorChoice | `choices` | | 105 105 106 Ha most megpróbáljuk elküldeni az űrlapot érvénytelen adatokka tnem tapasztalunk semmilyen változást. Előbb bővítenünk kell a `contact` modult az elküldött adatok érvényesítéséhez, ahogy a 2-3 mellékleten látható.106 Ha most megpróbáljuk elküldeni az űrlapot érvénytelen adatokkal, nem tapasztalunk semmilyen változást. Előbb bővítenünk kell a `contact` modult az elküldött adatok érvényesítéséhez, ahogy a 2-3 mellékleten látható. 107 107 108 108 2-3 melléklet - Érvényesítés megvalósítása a `contact` modulban … … 137 137 $this->form = new ContactForm(); 138 138 139 * Mikor a felhasználó elküldi az adatokat egy `POST` kéréssel, a `bind()` metódus köti össze az elküldött adatokat az űrlappal és elindítja az adat érvényesítést. Az űrlap ekkor **kötött állapt**ba kerül (**bound state**).139 * Mikor a felhasználó elküldi az adatokat egy `POST` kéréssel, a `bind()` metódus köti össze az elküldött adatokat az űrlappal és elindítja az adatok érvényesítését. Az űrlap ekkor **kötött állapt**ba kerül (**bound state**). 140 140 141 141 [php] … … 167 167 ### A validatorok célja 168 168 169 Vegyük észre, hogy az átirányításnál a `$request->getParameter('contact')` helyett a `$this->form->getValues()` használtuk. Ennek az az oka, hogy a `$request->getParameter('contact')` a felhasználó által elküldött adatokkal tér vissza, míg y a`$this->form->getValues()` az érvényesített adatokkal.169 Vegyük észre, hogy az átirányításnál a `$request->getParameter('contact')` helyett a `$this->form->getValues()` használtuk. Ennek az az oka, hogy a `$request->getParameter('contact')` a felhasználó által elküldött adatokkal tér vissza, míg a `$this->form->getValues()` az érvényesített adatokkal. 170 170 171 171 Ha az űrlap érvényes, akkor miért nem egyforma a két kifejezés eredménye? Minden validator két feladatot lát el: egy **érvényesítő feladatot** (**validation task**) és emellett egy **tisztító feladatot** (**cleaning task**). A `getValues()` metódus az érvényesített és tisztított adatokkal tér vissza. … … 173 173 A tisztító folyamat két fő tevékenységből áll: az bejövő adatok **normalizálása** és **konvertálása**. 174 174 175 Az adat normalizálást a `trim` opció segítségével már megismertük. A normalizálás ennél persze sokkal fontosabb például dátumok esetén. Az `sfValidatorDate` dátumokat érvényesít. A valid átor többféle bemenetet fogadhat (egy időbélyeget, egy regexp-en alapuló formátumot, ...). A bemeneti érték egyszerű visszaadása helyett azt a `Y-m-d H:i:s` formátumra alakítja át. Ez garantálja a fejlesztő számára az egységes formátumot, függetlenül az eredeti érték formájától. A rendszer ezáltal a felhasználó számára nagyfokú rugalmasságot tesz lehetővé, míg a fejlesztő számára biztosítja a konzisztens adatokat.176 177 Most nézzük meg a bejövő adat konvertálást egy file feltöltésen keresztül. A file érvényesítését az `sfValidatorFile` végzi. Ha a file feltöltése megtörtént, a neve helyett egy `sfValidatedFile` objektummal tér vissza, ami leegyszerűsíti a file információk kezelését. A fejezet későbbi részé n megnézzükennek a validatornak a működését.175 Az adat normalizálást a `trim` opció segítségével már megismertük. A normalizálás ennél persze sokkal fontosabb például dátumok esetén. Az `sfValidatorDate` dátumokat érvényesít. A validator többféle bemenetet fogadhat (egy időbélyeget, egy regexp-en alapuló formátumot, ...). A bemeneti érték egyszerű visszaadása helyett azt a `Y-m-d H:i:s` formátumra alakítja át. Ez garantálja a fejlesztő számára az egységes formátumot, függetlenül az eredeti érték formájától. A rendszer ezáltal a felhasználó számára nagyfokú rugalmasságot tesz lehetővé, míg a fejlesztő számára biztosítja a konzisztens adatokat. 176 177 Most nézzük meg a bejövő adat konvertálást egy file feltöltésen keresztül. A file érvényesítését az `sfValidatorFile` végzi. Ha a file feltöltése megtörtént, a neve helyett egy `sfValidatedFile` objektummal tér vissza, ami leegyszerűsíti a file információk kezelését. A fejezet későbbi részében látjuk majd ennek a validatornak a működését. 178 178 179 179 >**Tip** … … 210 210 Abban a formában, ahogy 2-4 ábrán látható, a hibaüzenetek nem túl hasznosak. Lássuk hogyan tehetjük őket még intuitívabbá. 211 211 212 Minden validator hibákat adhat az űrlaphoz. Egy hiba áll egy hibakódból és egy hibaüzenetből. Minden validator rendelkezik legalább a `required` és az `invalid` hibával, amelyek az `sfValidatorBase`ben vannak definiálva.212 Minden validator hibákat adhat az űrlaphoz. Egy hiba egy hibakódból és egy hibaüzenetből áll. Minden validator rendelkezik legalább a `required` és az `invalid` hibával, amelyek az `sfValidatorBase`ben vannak definiálva. 213 213 214 214 | **Kód** | **Üzenet** | **Leírás** … … 252 252  253 253 254 A 2-6 ábrán látható a túl rövid üzenet szövegbevitele esetén generált hibaüzenet (az üzenet hosszát legalább 4 karakterben határoztuk meg).254 A 2-6 ábrán látható a túl rövid üzenet bevitele esetén generált hibaüzenet (az üzenet hosszát legalább 4 karakterben határoztuk meg). 255 255 256 256 2-6 ábra - Túl rövid üzenet hiba … … 258 258  259 259 260 Ehhez a hibakódhoz (`min_length`) tartozó hibaüzenet különbözik azoktól, amiket már megismertünk, mivel ez két dinamikus értéket tartalmaz: a felhasználói adatot (`foo`) és a mezőhöz meghatározott minimális karakterszámot (`4`). A 2-5 mellékleten láthatjuk a dinamikus értékek használatát, a 2-7 ábrán pedig a végeredményt.260 Ehhez a hibakódhoz (`min_length`) tartozó hibaüzenet különbözik azoktól, amiket már megismertünk, mivel ez két dinamikus értéket is tartalmaz: a felhasználói adatot (`foo`) és a mezőhöz meghatározott minimális karakterszámot (`4`). A 2-5 mellékleten láthatjuk a dinamikus értékek használatát, a 2-7 ábrán pedig a végeredményt. 261 261 262 262 2-5 melléklet - Dinamikus értékek használata a hibaüzenetben … … 285 285  286 286 287 Minden hibaüzenetben használhatók dinamikus értékek, ehhez az érték nevét kell megadni százalékjelek (`%`) közé zárva. Az elérhető értékek általában a felhasználói adat (`value`) és a hibával kapcsolatosan a validatornak megadott opció érték.287 Minden hibaüzenetben használhatók dinamikus értékek, ehhez az érték nevét kell megadni százalékjelek (`%`) közé zárva. Az elérhető értékek általában a felhasználói adat (`value`) és a hibával kapcsolatosan a validatornak megadott opció neve. 288 288 289 289 >**Tip** 290 >Minden, validatorokhoz tartozó hibakód, opció és alapértelmezett üzenet megtalálható az online API dokumentációban ([http://www.symfony-project.org/api/1_1/](http://www.symfony-project.org/api/1_1/)) . Ott minden hibakód, opció és hibaüzenetrészletesen ki van fejtve (például az `sfValidatorString` validator API oldala megtalálható a [http://www.symfony-project.org/api/1_1/sfValidatorString](http://www.symfony-project.org/api/1_1/sfValidatorString) címen).290 >Minden, validatorokhoz tartozó hibakód, opció és alapértelmezett üzenet megtalálható az online API dokumentációban ([http://www.symfony-project.org/api/1_1/](http://www.symfony-project.org/api/1_1/)), itt minden részletesen ki van fejtve (például az `sfValidatorString` validator API oldala megtalálható a [http://www.symfony-project.org/api/1_1/sfValidatorString](http://www.symfony-project.org/api/1_1/sfValidatorString) címen). 291 291 292 292 Validator biztonság … … 295 295 Alapértelmezetten az űrlap csak akkor érvényes, ha minden elküldött mezőhöz van hozzárendelt validator. Ez biztosítja, hogy minden mezőhöz van érvényesítő szabály és nem lehet olyan mezőkhöz értéket megadni, amik nincsenek előre meghatározva az űrlapon. 296 296 297 Ezen biztonsági szabály megértéséhez nézzük meg a 2-6 melléklet ben lévő User objektumot.297 Ezen biztonsági szabály megértéséhez nézzük meg a 2-6 mellékleten lévő User objektumot. 298 298 299 299 2-6 melléklet - `User` osztály … … 322 322 } 323 323 324 Egy `User` objektumkét tulajdonságot tárol, a felhasználó nevét (`name`) és egy logikai értéket az adminisztrátori státuszról (`is_admin`). A `setFields()` metódus mindkét mezőt frissíti. A 2-7 mellékleten a `User` osztályhoz kapcsolódó űrlap látható, amely csak a `name` tulajdonság megváltoztatását teszi lehetővé.324 A `User` osztály két tulajdonságot tárol, a felhasználó nevét (`name`) és egy logikai értéket az adminisztrátori státuszról (`is_admin`). A `setFields()` metódus mindkét mezőt frissíti. A 2-7 mellékleten a `User` osztályhoz kapcsolódó űrlap látható, amely csak a `name` tulajdonság megváltoztatását teszi lehetővé. 325 325 326 326 2-7 melléklet - `User` űrlap … … 364 364 } 365 365 366 Mindenféle védelem nélkül, ha a felhasználó elküld egy űrlapot a `name` és az `is_admin` mezővel, akkor a kódunk sebezhető . Ez egyszerűen megtehető egy olyan eszközzel, mint a Firebug. Valójában az `is_admin` mező mindig érvényes, hiszen egyetlen validator sem kapcsolódik hozzá. Az értékétől függetlenül a `setFields()` metódus nem csak a `name` tulajdonságot fogja frissíteni, de az `is_admin`t is.366 Mindenféle védelem nélkül, ha a felhasználó elküld egy űrlapot a `name` és az `is_admin` mezővel, akkor a kódunk sebezhető volna. Ez egyszerűen megtehető egy olyan eszközzel, mint a Firebug. Valójában az `is_admin` mező mindig érvényes, hiszen egyetlen validator sem kapcsolódik hozzá. Az értékétől függetlenül a `setFields()` metódus nem csak a `name` tulajdonságot fogja frissíteni, de az `is_admin`t is. 367 367 368 368 Ha a fenti kódnak átadunk egy `name` és egy `is_admin` mezőt is, kapni fogunk egy "Extra field name." globális hibát, ahogy a 2-8 ábrán látszik. Ezt a rendszer akkor generálja a rendszer, ha olyan mezőt küldtek, amelyhez nem kapcsolódik validator; az `is_admin` mező nincs meghatározva a `UserForm` űrlapon. … … 372 372  373 373 374 Az eddig látott validatorok egy bizonyos mezőhöz generáltak hibát. Akkor mi ez a globális hiba? Amikor létrehozzuk a validatorokat a `setValidators()` metódus segítségével, a symfony készít eegy `sfValidatorSchema` objektumot. Az `sfValidatorSchema` validatorok egy csoportját határozza meg. A `setValidators()` hívás megfelel a következő kódnak:374 Az eddig látott validatorok egy bizonyos mezőhöz generáltak hibát. Akkor mi ez a globális hiba? Amikor létrehozzuk a validatorokat a `setValidators()` metódus segítségével, a symfony készít egy `sfValidatorSchema` objektumot. Az `sfValidatorSchema` validatorok egy csoportját határozza meg. A `setValidators()` hívás megfelel a következő kódnak: 375 375 376 376 [php] … … 383 383 Az `sfValidatorSchema` alapértelmezetten két érvényesítő szabályt használ, hogy megóvja a validator csoportot. Ezek a szabályok az `allow_extra_fields` és `filter_extra_fields` opciókon keresztül konfigurálhatók. 384 384 385 Az `allow_extra_fields` opció (alapértelmezett érték: `false`) ellenőrzi, hogy minden felhasználótól jövő adathoz tartozik-e validator. Ha nem, akkor egy "Extra field name." globális hibát generál, ahogy az előző példában láttuk. Fejlesztés közben így a fejlesztő figyelmeztetés kap, ha elfelejtett érvényesíteni egyes mezőket.385 Az `allow_extra_fields` opció (alapértelmezett érték: `false`) ellenőrzi, hogy minden felhasználótól jövő adathoz tartozik-e validator. Ha nem, akkor egy "Extra field name." globális hibát generál, ahogy az előző példában láttuk. Fejlesztés közben így a fejlesztő figyelmeztetés kap, ha elfelejtett érvényesíteni bizonyos mezőket. 386 386 387 387 Térjünk vissza a kapcsolat űrlaphoz. Változtassuk meg az érvényesítő szabályokat úgy, hogy a `name` mező kötelező legyen. Miután a `required` opció alapértelmezett értéke `true`, ezért a `name` validator a következő lesz: … … 444 444 } 445 445 446 Most már érvényesíteni tudjuk az űrlapot és megkapju az összes adatot a köszönet oldalon.447 448 A 4. fejezetben látni fogjuk hogyan használhatók ezek a védelmi mechanizmusok Propel objektumok biztonságos szerializálására az űrlap értékekből.446 Most már érvényesíteni tudjuk az űrlapot és megkapjuk az összes adatot a köszönet oldalon. 447 448 A 4. fejezetben látni fogjuk hogyan használhatók ezek a védelmi mechanizmusok Propel objektumok, az űrlap értékekből való biztonságos szerializálására. 449 449 450 450 Logikai validatorok … … 478 478 } 479 479 480 Űrlap küldésekor a `name` mezőben lévő adat legalább karakter kell legyen **és** illeszkedni kell a regexp mintára (`[\w- ]+`).480 Űrlap küldésekor a `name` mezőben lévő adat legalább 5 karakter kell legyen **és** illeszkedni kell a regexp mintára (`[\w- ]+`). 481 481 482 482 Mivel a logikai validatorok maguk is validatorok, összeállítható belőlük bonyolultabb logikai kifejezés is, ahogy a 2-12 mellékleten látható. … … 507 507 -------------------- 508 508 509 Minden eddig látott validator egy mezőhöz volt rendelve és egyszerre csak egy értéket érvényesített. Bár alapvetően nem veszik figyelembe a felhasználó által elküldött többi adatot, időnként egy mező érvényessége függ a környezettől vagy más mezők értékeitől. Például globális validatorra van szükség, ha két jelszó egyezését vizsgáljuk, vagy ha egy kezdő dátum meg kell, hogy előzzönegy záró dátumot.509 Minden eddig látott validator egy mezőhöz volt rendelve és egyszerre csak egy értéket érvényesített. Bár alapvetően nem veszik figyelembe a felhasználó által elküldött többi adatot, időnként egy mező érvényessége függ a környezettől vagy más mezők értékeitől. Például globális validatorra van szükség, ha két jelszó egyezését vizsgáljuk, vagy ha egy kezdő dátumnak meg kell előznie egy záró dátumot. 510 510 511 511 Mindkét esetben globális validatort kell használnunk, hogy a felhasználói adatot annak környezetében tudjuk érvényesíteni. Attól függően, hogy az egyes mezők érvényesítése előtt vagy után szeretnénk használni, beszélhetünk pre-validatorról vagy post-validatorról. Általában jobb ötlet a post-validator használata, hiszen ekkor már az adatok érvényesítve és tisztítva, azaz normalizált formában vannak. A 2-13 mellékleten látható, hogyan valósítható meg két jelszó egyezésének ellenőrzése az `sfValidatorSchemaCompare` validator segítségével. … … 678 678 679 679 >**Tip** 680 >A file feltöltésekor a böngésző által biztosított mime típus nem megbízható. A maximális biztonság biztosítása miatt érvényesítéskor a `finfo_open`, `mime_content_type` és `file` függvényeket használja a rendszer. Végső esetben, ha a függvények egyike sem tudja megállapítani a mime típus, vagy ha a rendszer nem képes szolgáltatni azt, akkor a böngésző által küldött típust veszi figyelembe. A mime típus megállapító függvények felvételéhez vagy megváltoztatásához az `sfValidatorFile` konstruktornak át kell adni a `mime_type_guessers` opciót.680 >A file feltöltésekor a böngésző által biztosított mime típus nem megbízható. A maximális biztonság biztosítása miatt érvényesítéskor a `finfo_open`, `mime_content_type` és `file` függvényeket használja az osztály. Végső esetben, ha a függvények egyike sem tudja megállapítani a mime típust, vagy ha a rendszer nem képes szolgáltatni azt, akkor a böngésző által küldött típust veszi figyelembe. A mime típus megállapító függvények felvételéhez vagy megváltoztatásához az `sfValidatorFile` konstruktornak át kell adni a `mime_type_guessers` opciót.
