Tagged: symfony RSS

  • Szabolcs Sulik 16:58 on 2009. 10. 25. Permalink | Válasz
    Tags: , sfEvent, sfEventDispatcher, symfony, , symfony 1.3   

    néhány kevéssé dokumentált symfony esemény 

    Korábban gondolkoztam rajta, hogy készítek egy írást a symfony eseménykezeléséről, összefoglalva, hogy melyik eseményt ki váltja mi és milyen listenerek vannak alapból. Aztán, ahogy telt az idő nem írtam semmit, illetve kijött a reference book, amelyben külön fejezetet szenteltek az események összefoglalásának.

    Van néhány esemény, aminek nem szentelnek túl nagy figyelmet, pedig roppant hasznosak tudnak lenni. Ezek az admin genertároban találhatók:

    • admin.pre_execute: minden admin action preExecute() metódusának végén értesít ki. Speciel ennek még nem láttam hasznát.
    • admin.save_object: minden (admin generátor oldalon végzett) objektum mentés után értesíŧ ki. Nagyon hasznos minden olyan tevékenység elvégzésére, amely nem kötődik szorosan a modell osztályhoz, de meg kell történnie mentéskor (pl. cache ürítés, lucene index frissítés, …).
    • admin.delete_object: minden (admin generátor oldalon végzett) objektum törlés előtt értesít ki. Hasonló előnyökkel kecsegtet, mint a mentésnél láttuk.
     
  • Szabolcs Sulik 10:37 on 2009. 08. 23. Permalink | Válasz
    Tags: , symfony, ,   

    symfony textarea widget érdekesség 

    Érdemes erre a widgetre odafigyelni, különben nem várt meglepetésben lesz részed. A textareaban megjelenő szöveget illik escapelni, erre tökéletes is lenne a htmlspecialchars függvény. Csakhogy a symfony nem pontosan ezt csinálja. Az sfWidgetFormTextarea::render() kicsit megpróbál tovább menni. A form framework jó pár widgetben használja az sfWidget::escapeOnce() metódust, itt azonban ez igen veszélyes.

    A kedves olvasóra bízom, hogy mi lesz az alábbi szöveggel, miután kétszer egymás után postolja az egy formon.

    <p>ez itt egy bekezdes</p> &lt;script&gt;alert(&quot;aaa&quot;);&lt;/script&gt;
     
  • Szabolcs Sulik 08:00 on 2009. 04. 05. Permalink | Válasz
    Tags: , symfony,   

    URL alapú szűrés symfony 1.2 admin generatorral 

    A probléma

    Symfony 1.0 admin generator alatta a lista nézet szűrése nagyon egyszerűen volt megoldva: az űrlapon megadott paraméterek GET-ként közlekedtek, maga a szűrés alkalmazása is a list actionben volt implementálva. Így máshonnan is könnyen használható volt, saját magunk által készített egyedi URLben is. Ez az új admin generator alatt most nem működik. Legalább is egyből nem, de mint látni fogjuk könnyen szóra bírható.

    (More …)

     
  • Szabolcs Sulik 19:55 on 2009. 03. 22. Permalink | Válasz
    Tags: , symfony,   

    Symfony 1.2 admin generator 

    Elöljáróban

    Ez már nem játék. :) Legalábbis nem teljesen. Elöljáróban megsúgom, annyira nem rossz a helyzet, mint korábbi cikkemben lefestettem. Az új admin generator egy nagyon rugalmas eszköz a kezünkben, amivel ha jól bánunk, mindenféle nagyobb hackelés nélkül teljesíti egyedi igényeinket is.

    Ott folytatnám, ahol a hivatalos dokumentáció abbahagyja, hiszen itt kezd érdekessé válni a dolog. Ehhez persze szükséges némi előképzettség. A dokumentációban leírtakat nem taglalom újra, azt tessék elolvasni szép angol nyelven. Feltételezem, hogy tisztában vagy az 1.0 admin generátorával, valamint ismered az új generator.yml és a generator template (theme) felépítését.

    Még egy megjegyzés: mivel Doctrine-nel dolgozom, így az itt leírtak is erős Doctrine függőséget fognak mutatni. Habár mindez (néhány különbséggel) teljesen így működik Propel alatt is.

    (More …)

     
  • Szabolcs Sulik 16:13 on 2009. 03. 15. Permalink | Válasz
    Tags: , symfony, symfony 2.0   

    Symfony 2 előzetes 

    Mi várható a symfony 2-ben. Mivel az 1.3-at év végére igérik, ezért nem kell félni a jövőheti megjelenéstől. ;)

     
  • Szabolcs Sulik 10:41 on 2009. 02. 06. Permalink | Válasz
    Tags: ellenőrzés, , , symfony, , , ,   

    symfony űrlapok további bővítési lehetőségei 

    Korábbi cikkemben bemutattam egy módszert, hogyan lehet részlegesen adatok validálni symfony formokkal. Most nézzünk meg további hasznos bővíŧési lehetőséget.

    3 új funkciót fogok megmutatni:

    1. űrlap kötése közvetlenül a kéréshez (bindRequest())
    2. űrlap kéréshez kötése részlegesen (bindRequestPartial())
    3. error séma beszerzése tömbként (getErrorsAsArray())

    Röviden nézzük végig egyesével és lássuk a kódot. :)

    (More …)

     
    • j. 12:12 on 2009. 03. 03. Permalink

      Helló!

      Szuper amit írsz továbbra is :)

      Az sfForm::convertFileInformation()-ban egy regex van, ami a

      static public function arrayToPaths($array = array(), $prefix = ”)

      statikus metódussal nyeri ki az adatokat feldolgozás előtt, szerintem ezzel te is ki tudod nyerni.

    • Sulik Szabolcs 17:15 on 2009. 03. 05. Permalink

      kosz

      Az sfForm::convertFileInformation()-ban egy regex van, ami …

      De miért tennék ilyet? Ha jobban megnézed ott két static metódushivás van. Pont ezt használja az sfForm is, ezért gondoltam hogy jó az nekem is.

      Egyébként érdekes, hogy enélkül az előzetes átalakítás nélkül képtelen felfogni a bind(), hogy ez tömb valóban egy FILES tömb akar lenni. Számomra ez rejtély.

    • j. 09:27 on 2009. 03. 06. Permalink

      Akkor csak félreértettelek, annyira nem néztem utána, csak segíteni akartam, hátha…de ezek szerint teljesen más volt a problémád. :)

  • Szabolcs Sulik 21:07 on 2009. 02. 01. Permalink | Válasz
    Tags: , symfony, , , ,   

    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.

    (More …)

     
    • 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.
      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 :) Populista picit…, nyuszikásvicc…mert ha meg nem kéne könyv, akkor senki nem venné komolyan :D , ahogyan pl. nem veszik komolyan a kisebb keretrendszereket (olyakor okkal, olykor ok nélkül – keretrendszere válogatja).

      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 :D Ballaszt amit mégsem lehet kilőni az űrbe :) (sajnos) :D

    • 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. :D

  • Szabolcs Sulik 00:53 on 2009. 01. 09. Permalink | Válasz
    Tags: , partial validation, symfony, , zend framework   

    symfony űrlapok részleges ellenőrzése 

    Mostanában megnéztem magamnak a Zend Frameworköt. A zf is biztosít egy saját űrlap készítési módozatot. Ami megfogott benne az az, hogy az űrlapokat részlegesen is lehet ellenőrizni, tehát csak a mezők egy részét adjuk át neki (Zend_Form::isValidPartial()).

    Erre jelenleg symfonyban nincs lehetőség, pedig nagyon kényelmes és rugalmas megoldás tudna lenni. Egészen pontosan az embeded form megoldást valószínűleg ennek kezelésére találták ki (nem tudok másra gondolni), viszont könnyen lehet rá példát mondani, ahol ez a megoldás már inkább nyűg mint feature.

    (More …)

     
    • j. 16:37 on 2009. 01. 27. Permalink

      Ez nagyon zsír, csak nem igazán értem, hogy hol használható, mert ugye egy Symfony űrlap egyáltalán nem űrlap hanem csak widget konténer, amit tetszőlegesen kombinálhatok, embedelhetek stb. Ha viszont egy űrlap FORM tag közé teszem és elpostolom akkor onnantól kezdve nekem az jó ha mindent levalidálok ami a FORM tagon belül van. Ezek szerinte a Zend tudja azt, hogy postolás után csak az első 3 widgetet (mezőt) validálja? :) vagy nem értem és egészen máshol van a Nagy Szellemi Élmény a dologban? :)

    • Sulik Szabolcs 17:41 on 2009. 01. 27. Permalink

      Pontosan.

      Ha van egy rakat meződ egy userhez mondjuk, és az adatait több körben szeretnéd bekérni, akkor ha csak a mezők egy általad meghatározott részét adod át is működik (és jól működik) a dolog, nem kell a validator sémának az allow_extra_fields, filter_extra_fields opcióival játszani. Neked nem kell azzal sem foglalkoznod, hogy a mezők melyik részét határoztad meg, azt majd a bindPartial összeszedi.

      Az embed form is jó lehet a fenti példában, viszont ha az alkalmazás másik öt helyén is kell adatot bekérni a usertől, és valszeg nem lesznek ezek a részhalmazok diszjunktak, akkor lőheted az embed formjaidat. Ez viszont szépen működ. :)

      Emellett ez a megoldás csak a validálás idejére cseréli le a validátor sémát, utána visszaállítja az eredetit. Hátránya, hogy a pre és post validátorok nem működnek.

      Hamarosan tovább is folytatódik a történet (van még néhány cikk a tarsolyomban :) ).

    • j. 18:27 on 2009. 01. 29. Permalink

      Oké! Meggyőztél a példáddal! :)

  • Szabolcs Sulik 10:26 on 2008. 12. 31. Permalink | Válasz
    Tags: , , symfony,   

    Symfony 1.2 admin generator játék 

    Végül csak kipróbáltam, hiszen már 1.2.1-nél jár a rendszer. :) Nem lettem fiatalabb. :( Elöljáróban annyit, hogy kissé megbonyolították a dolgokat (több szinten is), és ez nem biztos, hogy a symfony javát szolgálja. De lássuk a szaftos részleteket.

    (More …)

     
    • j. 13:56 on 2009. 01. 21. Permalink

      Ez eléggé gázul hangzik…Én most szerettem volna kipróbálni az új admin generátort, de picit elment tőle a kedvem. :)

    • Sulik Szabolcs 18:05 on 2009. 01. 25. Permalink

      Mindettől függetlenül próbáld ki. Ez csupán az én véleményem.

      Az igazán érdekes az lenne, ha az új generátor osztályokról lenne valami írás. Lehet, hogy csak én nem találtam ilyet.

      Emellett a “nagyon jó” dokumentáció úgy van felépítve (legalábbis egyre inkább úgy néz ki), hogy ők megcsinálják a rendszer összetevőit (értsd: generator, validator, factory osztályok, …) és te használd őket. Túl mélyen sehol sem mennek bele, mit is lehet belőle igazán kihozni.

      Pl. az új routing rendszert bemutató első előadáson utalt Fabien arra, hogyan lehet a routing egy részét aldomainként használni. Erről kb ennyi jelent meg, sem a könyvben, sem a cookbookban nem írnak semmit valamiféle advanced felhasználásról.

    • j. 10:31 on 2009. 01. 26. Permalink

      Köszi!
      Arról nincs valahol doksi, hogy az admin generátorokat hogyan lehet kibővíteni saját osztályokkal? Pl. ha nekem nem jó az admin generátoros képfeltöltés, akkor azt hogyan tudom egyedi megoldásokkal kiváltani? Vagy bármi mást – tehát létrehozok egy konfig fájlt ami alapján az admin generátor működik, de van saját kódom is amit tetszőleges dolgokra írok…lehet ilyet? :D Én per pillanat azt látom járható útnak, hogy a Symfony által generált osztályokat (amiket a cache-ba létrehoz) átírom a saját számíze szerint :)

    • Sulik Szabolcs 23:46 on 2009. 01. 26. Permalink

      Így gyorsan belenézve a kódba az új generator nagyon hasonló a régi megoldáshoz, csak az új form rendszerre épül és amit lehet, azt áthelyezi a generator templateből (és config fileból) az adott module/lib alatti xyzGeneratorConfiguration osztály felelősségébe (pager beszerzés, egyes actionhöz tartozó engedélyek, filter form, form, …).

      Ami neked kell azt a megfelelő form osztályban lehet elérni. A widget legyen sfWidgetFormInputFile (vagy leszármazottja), validator sfValidatorFile (vagy leszármazottja). Magát a logikát pedig a form::doSave() metódusban kell kifejteni.

      Komolyabban még nem használtam az új admin generatort, ez csak egy kis játszadozás vele.

    • j. 16:31 on 2009. 01. 27. Permalink

      Akkor rám is ez vár, játszodozok :D

    • j. 10:43 on 2009. 02. 02. Permalink

      Ezt találtam hétvégén:

      http://sandbox-ws.com/how-to-embed-forms-in-symfony-12-admin-generator

      Semmi különös, de hasznos lehet másoknak is!

  • Szabolcs Sulik 22:03 on 2008. 12. 01. Permalink | Válasz
    Tags: jobeet, , symfony,   

    Symfony újdonságok: 1.2, Jobeet 

    Aki nem követné figyelemmel a symfony blogot: ma megjelent az symfony 1.2. Ahhoz képest, hogy elsősorban az admin generátor újraírást tűzték ki célul, sok mindennel jelentkezik az új kiadás. Az egyik legfontosabb a teljesen újraírt Routing Framework (mennyi framework a keretrendszerben :) ), amire erősen épít az új admin generator is. A formokat kicsit tovább pofozták, jól szétszedték a teszteléshez való komponenseket, valamint bekerült a Doctrine is a repertoárba (miután szept. 1-től náluk dolgozik a főfejlesztője csúnya lett volna ha nem). Személy szerint ez annyira nem dob fel, alapvetően ugyanazt tudja, mint a Propel, max kicsit másképp. Alapjaiban egyformák. Arra figyelj, hogy most már mindkettő PDO alapú. Ez tök jó, addig amíg nem akarja a rendszerben valami a modelt serializalni, mert azt bizony PDO-s dolgokkal nem lehet.

    Apropó routing. Ha van tapasztalatod az új rendszerrel, vagy a régivel :) kommentbe szivesen vennék néhány választ, miért zabál az sfPatternRouting::generate() annyi ramot? Nem sima oldaltöltésnél vehető észre, de ha mondjuk generálsz 5-10 ezer egyedi urlt (pl nagyobb mennyiségű levélküldés), akkor már nagyon kijön.

    Jobeet. Érdemes megtanulni ezt a nevet. Az új Askeet, ami valjuk be mára eléggé elavult. Ami nagyon pozitív benne, hogy jóval több akar lenni (és valszeg lesz is), mint összedobált kóddarabok összessége. Személetet próbál átadni (némi? symfony körítéssel), ami érdekessé teheti azok számára is, akik nem tudnak/akarnak/kívánnak symfony-val foglalkozni.

    Ha kedvem, időm engedi, megnézem az új routing renszert és admin generátort. Talán abból is kisül egy rövidebb írás. ;)

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
Megjegyzések elrejtése/mutatása
t
go to top
l
go to login
h
show/hide help
esc
mégse