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.

Korábban, még RC1 környékén megpróbálkoztam az új admin generatorral, de olyan függőségek feloldását kérte tőle, amit 1. nem értettem, 2. semmi értelme nem volt (kapcsolt tábláknál a másik táblának is csináljam meg az admin generatorát ???). Arra mindenesetre jó volt, hogy legalább dokumentáció alapján láttam, hogyan is akar ez működni (ha máshogy nem is sikerült :)). Ennek most hasznát is vettem, csak mintha a doksi is hiányos lenne.

Szóval. Az új generator nagyban épít az új routing alrendszerre, nevezetesen az sfObjectRouteCollection-re. Leírás szerint egy routing collection bejegyzést létre kell hozni a generátor modul létrehozása előtt, de ezt igazából a task szépen megcsinálja. Amit nem csinál meg, az a formok létrehozása. Ami nem probléma, ha már legeneráltuk őket, én nem tettem, feltételeztem némi intelligenciát. Ez az én hibám volt. Szóval symfony 1.2 alatt admin generator előtt, de már model generálás után: (aki propelt használ, annak természetesen propel előtaggal)

symfony doctrine:build-forms
symfony doctrine:build-filters

Minderre azért van szükség, mert az új generátor az sfForm alrendszerre épül. Hogy minek akkor ez a build-filters? Azért, mert két típusú formra lesz szüksége a generátornak a modulban:

  1. build-forms: maguk a modelt szerkesztő formok (jól ismert helyen, a lib/forms/ alatt találhatók)
  2. build-filters: a lista oldalon található szűrő form, amely egy speciális űrlap, ami a beállított mezők alapján egy megfelelő Criteria/Doctrine_Query objektumot képes előállítani (lib/filters/ alatt kell keresni)

Ha ez megvan, akkor egész jó úton haladunk.

A problémám eddig pusztán az, hogy a generátor dokumentáció alapján nekem nem kell csinálnom semmit, csak létrehozni az alkalmazást és generálni az admin modult. Az itt leírt lépéseket nem említi, és azt sem, hogy nekem egy doctrine:build-all parancsot ki kell adnom az egész művelet előtt. Erről ennyit.

Az alábbi modellel simán elbánik🙂 :

User:
  tableName: user
  columns:
    id:
      type: integer(4)
      primary: true
      autoincrement: true
    name: string(250)
    created_at:
      type: timestamp(25)
      notnull: true

Csakhogy én nem ezzel kezdtem, és ebből lett a gubanc meg a kissé keserű szájíz. Itt az én eredeti sémám:

User:
  tableName: user
  columns:
    nick:
      type: string(200)
      primary: true
    name: string(250)
    created_at:
      type: timestamp(25)
      notnull: true

Ugye látható a különbség. Én úgy gondoltam, hogy a user nickje egyedi, ezért akár lehetne az elsődleges kulcs is. Ez a séma több sebből vérzik a generátor tekintetében. Én pusztán annyit akartam kipróbálni, hogy előre felvitt teszt adatokkal tud-e működni a rekord szerkesztése. A válasz sajnos egyszerű: nem. Azt mondja, hogy nem talál hozzá megfelelő routingot. Hogy is van ez? Íme a hozzá tartozó routing:

user:
  class: sfDoctrineRouteCollection
  options:
    model:               User
    module:              user
    prefix_path:         user
    column:              nick
    with_wildcard_routes: true

Ez jónak néz ki. Akkor mi okozza a problémát? Röviden az sfObjectRouteCollection hibás  feltételezése. Minden collectionnek beállít egy alapértelmezett requirements-et a megadott oszlophoz:

$this->options['requirements'] = array_merge(
  array($this->options['column'] => 'd+'), 
  $this->options['requirements']
);

Nyilvánvalóan ez az esetünkben nem igaz. Mit lehet így tenni? Meg kell adni a saját requirements sort a mezőnkhöz.

user:
  class: sfDoctrineRouteCollection
  options:
    model:               User
    module:              user
    prefix_path:         user
    column:              nick
    with_wildcard_routes: true
  requirements:
    nick: 'w+'

Ezzel már működik is a szerkesztés. Ez a “hiba” másnak is feltűnt. A probléma igazából az, hogy ez a routing collection részéről egy felesleges feltételezés, ami ráadásul nincs is benne a dokumentációban. Plusz a doksi routing fejezete még mindig az 1.1 leírását tartalmazza. Sajnos a symfony 1.2 dokumentációja le van maradva a rendszertől, és ez nem hiszem, hogy jót fog tenni a rendszernek hosszú távon. Annak idején pontosan a hihetetlenül pontos és részletes dokumentáció volt, ami megfogott a symfony-ban. Bármit olvastam, azt kipróbáltam és működött. Ez most úgy néz ki, hogy már nem igaz. Ami nekem, illetve a régebbi motorosoknak valszeg nem olyan nagy probléma, viszont a új fejlesztők életét eléggé megkeseríŧheti.

Kategória: php, symfony
Címke: , , ,
Közvetlen link a könyvjelzőhöz.

7 hozzászólás a(z) Symfony 1.2 admin generator játék bejegyzéshez

  1. j. szerint:

    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.🙂

  2. Sulik Szabolcs szerint:

    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.

  3. j. szerint:

    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?😀 É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🙂

  4. Sulik Szabolcs szerint:

    Í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.

  5. j. szerint:

    Akkor rám is ez vár, játszodozok😀

  6. j. szerint:

    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!

  7. Visszajelzés: Symfony 1.2 admin generator « blerou szerszámosládája

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s