ugrás a tartalomhoz

symony forms

Hodicska Gergely · 2008. Okt. 26. (V), 13.16
A formos részt nézd meg nagyon, akár symfony nélkül is használható a cucc. A legszimpatikusabb az eddig látott megoldások közül (HTML_QuickForm, Zend_Form).
Ezzel picit vitatkoznék, bár nem használtam, csak a doksiját olvastam el.

A következő dolgok nem tetszenek:
  • Miért kell kézzel megjeleníteni a form egy részét, tökre nem logikus szerintem? Nem lehet ott akkora varázslat, ami ezt indokoltá teszi. Az action-t nyugodtan meg lehetne adni paraméterként (de erre tök jó default az aktuális URL, legtöbb form önmagára postol), az is tök automatikus kéne legyen, hogy ha van fájl, akkor multipartos a form.
  • Miért kell kézzel "bind"-olni a formot, ez is lehetne automatikus: pl. az isValid() metódusban?
  • A form testreszabása egy kicsit érdekesen lett megoldva, elsőre kicsit nehézkes. Nekem szimpatikusabb lett volna, ha van egy form renderer, amit utána lehet díszíteni, nem pedig a view-ban kell az elemeket külön renderelni. Bár gondolom a view helperrel lehet valami hasonlót elérni.
  • Nem lehet az elemeket csoportosítani, egy nagyobb űrlap esetén az elég hasznos tud lenni, de vegyünk csak egy olyan esetet, hogy egy mezőnk az olyan, hogy 12 lehetséges checkboxból lehet választani.
  • Nincs benne automatikus javascript ellenőrzés.

Ezeket a QuickForm tudta már vagy 5 évvel ezelőtt, és már akkor is elég szép kódja volt (egyedül beépített i18n támogatás nincs benne). A Zend_Form is ahogy olvastam tudja ezeket (JS validáció nincs, de könnyű benne csinálni, plusz a Dojo-val biztosan bejön majd ez is). Ez utóbbi is sokat fog dobni rajta, plusz van benne pl. captcha, illetve CSRF elleni védelemre szolgáló elem is (nem akkora szám, de azért kényelmes).
 
1

Izlesek es pofonok

Sulik Szabolcs · 2008. Okt. 27. (H), 00.49
Elore bocsatom, elsosorban sf formokkal dolgozok, a Quickform-ot regebben, a Zend_Form-ot egy-ket egyszerubb esetben hasznaltam, probalgattam.

Elobb nezzuk vegig, ami neked nem tetszik:
Miért kell kézzel megjeleníteni a form egy részét...

Igen, ez erdekes lehet elsore. Ez valszeg azert van, mert a formok egymasba agyazhatok, igy tobb kisebb, mar kesz formbol is osszeallithatsz egy nagyobbat.

A formhoz megadhatsz formatter-t, amit akar sajat magad is keszithetsz. Sablonos esetekben nagyon jol hasznalhato, viszont a tapasztalat azt mutatja, hogy ahany form, annyi megjelenites. Igy egyszerubb a templatet megirni kezzel (es talan konnyebb is), mint formatter osztalyokat irogatni. (mellesleg ez jelenleg eleg nehezkes is, nem nagyon gyozott meg eddig)

Osszessegeben nem hiszem, hogy a template megirasa (vs echo $form) problemat kellene, hogy okozzon, vagy lassitana barmit is egy projekten. Ki hogy szokta meg.

Az 1.2-ben mar lesz a formnak sajat <form> generalo metodusa.

Miért kell kézzel "bind"-olni a formot

Nos, az sf-ben a formok filozofiaja az, hogy bekersz valamilyen adatot (ezt termeszetesen egy formon keresztul - widget-ek segitsegevel), majd azt validalod is tisztitod a formmal. A symfony tudatosan nem koti a formokat a request objektumhoz, pusztan az adatokra van szuksege. Ebbol kovetkezik, hogy barmilyen kulso forrasbol szarmazo adatot ellenorizhetsz vele. Meg egy kis adalek. Amugy a Zend-es doksit elnezve, ok is igy gondolkoznak.

A form testreszabása egy kicsit érdekesen lett megoldva...

Izlesek es pofonok.

Nem lehet az elemeket csoportosítani...

Igen, nem minden esetben lehet konnyen megcsinalni.

...egy mezőnk az olyan, hogy 12 lehetséges checkboxból lehet választani.

Erre az esetre pont nincs widget :) (1.2 mar alapbol lesz), de az sfWidgetFormSelectMany mintajara konnyen megirhatod magadnak.

Nincs benne automatikus javascript ellenőrzés.

Ahogy kesobb a Zend-del kapcsolatban irod, megirhatod magadnak :).

plusz van benne pl. captcha, illetve CSRF elleni védelemre szolgáló elem is

Az sfFormExtraPlugin-ban kapsz tobbek kozott egy captchat is. Sajnos a doksi nem mond rola semmit, viszont a CSRF elleni vedelem talan a legfontosabb eleme az sf formoknak. Benne van es alapertelmezetten be is van kapcsolva.

Ami ezen tul nekem tetszik:

Hm, most hirtelen ennyi.
2

részben

Hodicska Gergely · 2008. Okt. 27. (H), 16.24
Néha nem könnyű értelmes subjectet találni. :) Amúgy mielőtt félreértődnék, nem gondolom, hogy az sfForm rossz cucc lenne, inkább csak a többiek védelmében írtam, illetve van amire úgy gondolom, hogy lehetne nyugodtan okosabb default működés. Ami ugyeáltalában elég fontos alap szervező elve a mai frameworkoknek (CoC).

Igen, ez erdekes lehet elsore. Ez valszeg azert van, mert a formok egymasba agyazhatok, igy tobb kisebb, mar kesz formbol is osszeallithatsz egy nagyobbat.
Ezt láttam, de lehetne okosabb default működés, ami a legtöbb esetben elég. Így sok esetben lesz ismétlődő kis kódocska, amit persze ki lehet védeni egy helperrel.

Sablonos esetekben nagyon jol hasznalhato, viszont a tapasztalat azt mutatja, hogy ahany form, annyi megjelenites.

Osszessegeben nem hiszem, hogy a template megirasa (vs echo $form) problemat kellene, hogy okozzon, vagy lassitana barmit is egy projekten.

Ez eléggé függ az alkalmazás jellegétől is, egy weboldalnál eleve relatív kevés form van, de mondjuk egy adminnál már elég sok ilyen lehet, és ezek többnyire egyformán néznek ki, ilyenkor elég hasznos ha van ilyen formatter lehetőség (doksiban nem láttam amúgy).

Nos, az sf-ben a formok filozofiaja az, hogy bekersz valamilyen adatot (ezt termeszetesen egy formon keresztul - widget-ek segitsegevel), majd azt validalod is tisztitod a formmal.
Ez szinten oké, csak megint a default működés lehetne okosabb, vagy pl. kaphatná az alternatív adatot az isValidban is.

Ettől függetlenül én érzek itt egy kis logikai bukfencet. Mert igazából maga a form az mindig a requesthez fog kötődni, csak a validálás az, ami érdekes lehet más forrásból jövő adatra is.

Ahogy kesobb a Zend-del kapcsolatban irod, megirhatod magadnak :).
Ott a dekorátorok miatt relatív egyszerű. Vlaszeg SF-ben sem atomfizika. A listába csak azért került bele, mert elég gyakori igény lehet, és QuickForm-ban már ősidők óta benne van.

finomabb validacios lehetoseg (and, or validator)
Ez valóban hasznos lehet, bár elég ritkán lehet rá szükség, akkor is vlaszeg egy regexp validator megoldás tud lenni.

a validator schema allow_extra_fields, filter_extra_fields lehetosegehez hasonlot egyiknel sem talaltam
Amit a link hoz példát, az szerintem rossz default működés. Ha elkérem egy formból az értékeket, akkor a default az legyen, hogy csak azt adja vissza, ami definiálva volt. QuickFormban pl. hogy lehet a mezőket konstanssá tenni (vagy pl. fagyasztani), akár programozottan is: van a formnak is_admin mezője, de alapból konstans (nem tudja állítani), de ha admin jogú ember nézi az oldalt, akkor feloldja az ember ezt a korlátozást. De lehet simán konstans hidden mező is. Az lehet persze érdekes, hogy pl. bővülni tudjon a form, de ez is megoldható.
3

egeszben :)

Sulik Szabolcs · 2008. Okt. 28. (K), 11.50
En sem a tobbiek ellen irtam, csak szamomra ez a legszimpatikusabb (emellett nyilvan ezt ismerem a legjobban, hiszen ezt hasznalom napi szinten). A Quickform volt az elso ertelmes megoldas formkezelesre, jopar helyen hasznaltam. A Zend_Form pedig minel tovabb nezem, annal szimpatikusabb (hasznalataban alapvetoen sok kulonbseget nem latok az sf formhoz kepest).

A sablonos eseteket epp az admin feluletre ertettem, ott eleg jol hasznalhato a formatter (ez volt az egyetlen szitu ahova irtam egyet). Valoban nem egy atomfizika, doksi nelkul (mivel nincs) is ossze lehet dobni egy jol mukodo sajatot 1-2 ora alatt. Bar volt valami, amit nem tudtam vele rendesem megcsinalni (mar nem emlekszem), de az csak egy aprosag.

Ez szinten oké, csak megint a default működés lehetne okosabb, vagy pl. kaphatná az alternatív adatot az isValidban is.

Hat ja. Elgondolkoztam a zend nezegetese kozben es nem tudnam megmondani, miert igy csinaltak meg :). Bar azon az egy soron nem fog mulni.

Amit a link hoz példát, az szerintem rossz default működés.

Lehet, hogy a leiras kicsit felreertheto. A mukodes: allow_extra_fields (default: false) ha olyan mezo is erteket kap bind()-nel, ami nincs definialva, akkor invalid -> hibauzenet megy. Ha ezt atallitom true-re, meg akkor is ott van a filter_extra_fields (default: true), ami unseteli azokat a mezoket amik nincsenek definialva. Szvsz ez igy jonak tunik.

Ami meg eszembe jutott: file feltoltes utan az sfValidatorFile nem egy tombot ad vissza, hanem egy sfValidatedFile objektumot. Ezt aztan egy mozdulattal lehet menteni. Nem olyan dolog, amit a zendben ne lehetne megcsinalni, csak kenyelmes.