A pre- és post validátorokról
Nem találtam túl sok leírás a témában, pedig érdekes tud lenni. Előljáróban: pre- és post validátorok az összes mezőt kapják meg és validáció után az összeset kell visszaadniuk. Ezért az összeállított validátor-strukúra alján (általában) sfValidatorSchema leszármazottak állnak. Ez nem kötelező jellegű, csupán ezek a validátorok fogadnak több mezőt.
j. are discussing. 
j. 10:52 on 2009. 02. 02. Permalink
A Symfony-s doksikra sajnos az a jellemző (és ez nagy negatívuma a Symfonynak szerintem), hogy a doksija látszólag terjedelmes és részletes, viszont tartalmilag kb. 80% olyan információkból áll amire egy fejlesztő magától kb. 10 perc alatt rájön, viszont az összetettebb és bonyolultabb részek pedig iszonyatosan aluldokumentáltak és legjobb esetben is csak egy-egy fórum témában lehet róluk olvasni…persze még így sem lehet okunk panaszra, hiszen ez egy Open Source rendszer, tehát lehet bővíteni önkéntes alapon, de egy kis plusz doksi azért nem ártana ezen a téren, meg a validátorokhoz úgy általában sem…
Sulik Szabolcs 19:43 on 2009. 02. 02. Permalink
Hát a dokumentáció az ilyen, kicsit hiányos az advanced felhasználói rész.
Anno a taskokról akartam írni egy cikket, aztán meggondoltam magam. 1.1 előtt nagyon hypeolták az új task rendszert. Azóta erről hallgatnak (igéret volt, hogy kódból is lehet példányosítani őket). Plusz kicsit over-engineered cuccnak tűnik az egész. Kb 3 osztályból örököl dolgokat az sfBaseTask (ill. az sfPropelBaseTask, sfDoctrineBaseTask). Kérem jelentkezzen az, aki nem sfBaseTask alapú taskokat ír. Nem értem minek ez az egész molyolás, mikor azért írok taskot, mert szükségem van arra a nyűves projectConfiguration példányra. Ha nem lenne szükségem rá, akkor írok egy vacak batchet és kész. Ebben az is benne van, hogy ez egy fölösleges tanulási körre rákényszeríti a fejlesztőt, ha symfony taskot akar használni, gyakorlatilag a semmiért.
Egyre inkább úgy érzem, hogy igaza van Terry Chay-nek: ahol egy könyvre van szükség, hogy használni tudj egy keretrendszert, ott valami gáz van. És mint tapasztaltuk, az említett könyv helyenként igencsak az alapokat adja jelenleg (és akkor a félbehagyott form könyvet hagyjuk).
Mindettől függetlenül úgy gondolom, hogy a symfony rendelkezik az egyik legmasszívabb MVC alappal, tele jó ötlettel. Csak gyorsabban jutnak be az újíŧások a kódba, mint a dokumentációba.
Tipp: nézd meg a kód kommenteket. Azok általában jobbak, mint maga a doksi.
j. 12:59 on 2009. 02. 03. Permalink
A Symfony képességeit és erényeit szerintem nem lehet vitatni, aki ezt teszi az valamit nagyon nem ért
vagy félerért – jobb esetben. Ebben maximálisan egyetértek veled.
Populista picit…, nyuszikásvicc…mert ha meg nem kéne könyv, akkor senki nem venné komolyan 
, ahogyan pl. nem veszik komolyan a kisebb keretrendszereket (olyakor okkal, olykor ok nélkül – keretrendszere válogatja).
Terry Chay irományához kapcsolódóan: picit félreérthető amit ír, nem mindenben értek egyet azzal, hogy “ahol egy könyvre van szükség, hogy használni tudj egy keretrendszert, ott valami gáz van”, mert bár van ebben igazság, de ha jobban belegondolsz egészében csak féligazság
Engem a Symfonyban továbbra is az zavar legjobban amit írtam: a kézenfekvő dolgok agyon vannak dokumentálva, az ún. össszetettebb témák pedig egy-egy mondatban vannak megemlítve, néha mintha szándékosan szivatnák az embert…MENJ A FÓRUMBA és kuncsorogj…és ez oda vezet, hogy bár a rendszer jó: túl nagy a konkurencia ma már ahhoz, hogy egy fejlesztő rá legyen kényszerülve egy keretrendszerre. Viszont a Symfony-nak annyi jó tulajdonsága van, hogy még így is bőven megéri a rááldozott időt, mert a Zend-en kívül talán az egyetlen keretrendszer amire akár egy nagyobb fejlesztő cég is építhet hosszabb távon, talán még a Kohana sorolható ide, de már ez is sokkal “lightesebb” kategória. de ez csak szubjektiv vélemény
Sulik Szabolcs 19:19 on 2009. 02. 03. Permalink
Hát ja. A dokumentáció kicsit ördögi kör
Nem mintha a Zend-é olyan kicsi lenne 
A symfony teljesen megfelel a céljaimnak, a hogyan használd rész pedig inkább az Askeet ill. Jobeet doksikban van benne jobban.
A Kohanaról mostanában sok jót hallottam, csak egy My First Project tutorialt sem találtam az oldalukon. A CodeIgniter meg nem tetszett amikor nézegettem. Viszont a Harry Fuecks név biztatóan hangzik (bár lehet, hogy csak az utf8 kezelést vették tőle).
A Terry Chay idézet pedig nagyon “durva” megfogalmazás, az ő kontextusából teljesen kiragadva. Érdemes elolvasni néhány cikket tőle (szórakoztató tud lenni, ha bírod a stílusát).
Sulik Szabolcs 16:30 on 2009. 02. 04. Permalink
Ja, és a taskos kritika nem az egyetlen. Másik példa: sfWidget osztály. Miért is van ilyen? Hiszen azt csak az sfWidgetForm osztály terjeszti ki. Ez nem csak nekem tűnt fel. Ehhez csak annyit fűznék hozzá, hogy ami html kimenetet generál az a partial. Arra pedig nem árt figyelni, hogy ha egy absztrakt osztályból (sfWidget) származik egy másik absztrakt osztály (sfWidgetForm), akkor ott valami bibi van.
Bármilyen jó is egy rendszer, nem árt némi egészséges kritikával szemlélni.
j. 10:15 on 2009. 02. 05. Permalink
Szerintem az sfWidget osztály egy tervezési minta következetes használata miatt lett
És bár teljesen igazad van abban, hogy “minek van” mégis ha megnézel klasszikus OOP nyelveken írt kódgyűjteményeket (pl. Javávban, Delphiben), akkor ott hasonló dolgokkal fogsz találkozni 
Nekem úgy tűnik, hogy ez a fajta “felesleges” felaprózódás az OOP következetes használatának egyik mellékterméke 
Ballaszt amit mégsem lehet kilőni az űrbe 
(sajnos) 
Sulik Szabolcs 16:19 on 2009. 02. 05. Permalink
Bocs, de ez marhaság (mármint nem amit írsz, hanem ez a hozadékos dolog). A for future purpose tűnik a logikus magyarázatnak, csakhát honnan tudják, hogy majd mire akarják még használni, ha jelenleg nem használják semmi másra (és akkor majd jó lesz-e a jelenlegi kialakítás)? Ráadásul pont a symfony az a rendszer, amelyik a folyamatos refactoring útját járja. Így még érthetetlenebb a dolog számomra.
Egy dolog annyira egyszerű, amennyire csak lehetséges, de semmivel sem egyszerűbb. Albert Einstein
Ez most nem tűnik a lehető legegyszerűbbnek.
Egyébként szerinted melyik minta használatának következménye ez?
Delphit régen használtam, nem nagyon emlékszem az ottani dolgokra.
Félreértés ne essék, nem az a baj, hogy van egy absztrakt osztály és abból más absztrakt osztályok származnak, amelyek más és más irányban terjesztik ki azt. Itt az a probléma, hogy EGYETLEN osztály származik az alaposztályból.
j. 12:28 on 2009. 02. 06. Permalink
Ez nem egy konkrét minta használata, hanem minták félreértelmezéséből keletkező hiba, én nem azt mondtam, hogy ez jó, hanem azt, hogy nagyon sok, általam eddig átnézett, átnyálazott forráskódban előfordulnak hasonló bibik és szerintem nem véletlenül, hanem azért mert az OOP alap filozófiája félreértelmezhető úgy, hogy a dolgok túl lesznek variálva és akkor ilyen “hibák” keletkeznek. Remélem így már érthető mire gondoltam
és nem fog “marhaságnak” tűnni.
Sulik Szabolcs 13:48 on 2009. 02. 06. Permalink
Így már nem.