ugrás a tartalomhoz

A Symfony keretrendszer telepítése és bemutatása

aston · 2007. Okt. 21. (V), 20.09
A Symfony keretrendszer telepítése és bemutatása
A keretrendszer, amivel már másfél éve dolgozom, gondoltam megér annyit, hogy írjak róla egy kis összefoglalót. Bár nincs túl jelentős fejlesztői előéletem, de kipróbáltam egy-két frameworköt. Ezenkívül a Symfony Project hónapról-hónapra növekszik, a közösség bővül, hetente újabb és újabb blogok foglalkoznak vele, egyre többen választják, vannak vele megelégedve, velem együtt.

Áttekintés

Mit is tud?

  • Object-Relational Mapping (Propel)
  • MVC minta szerinti felépítés
  • Bővítmények
  • Egyszerű sablon és segéd rendszer
  • Gyorsítótárazás
  • Szép URL-ek
  • Többnyelvűség és I18N támogatás
  • Egyszerű konfigurálási lehetőség YAML-el
  • Adminisztrációs felület kódgenerálása és közös feladatok automatizálása
  • stb.

Támogatás

Kik választották

  • A Yahoo! már választotta, több projectjéhez is (Yahoo! Bookmarks [napi 40 millió kattintás])
  • Del.icio.us, a népszerű szolgáltatás következő verziója

Hogy miért választotta a Yahoo! a Symfonyt?

  • Great documentation – In-Depth Online Book + API Documentation + Wiki
  • Active development – Consistent improvements in design: flexibility + speed
  • Active community – Large community with plenty of free support
  • Flexibility – Overall design + configuration system + plugins
  • Use of best-of-breed components rather than reinventing the wheel

Magyar fejlesztők

Telepítés

A telepítési útmutató néhol elég részletes, elnézést annak akinek nem mond újat, de az alább leírtak kezdők számára is végigvihetőek.

Előkövetelmények

A következő példa szűz Windows XP Service Pack 2 rendszerre mutatja be a telepítést (garanciát vállalok: végigcsináltam), mivel legtöbbünknek ez áll rendelkezésre otthon. Rengeteg telepítési útmutató keletkezett már eddig a legtöbbet használt operációs rendszerekre, Apache-ra és IIS-re is.

Bár a Symfony adatbáziskezelő és kiszolgáló független, a példában Apache-ot és MySQL-t használok, mivel legtöbben ezt használják és a telepítése nulláról is gyorsan megvan az XAMPP programmal. Next-next-finish (opcionálisan service-ként is telepíthetjük), és máris van PHP5-ünk, Apache-unk és MySQL-ünk is, kezdődhet a móka (ha a böngészőbe beírt "localhost"-ra egy nagy XAMPP felirat jelenik meg, akkor tudhatjuk, minden jól ment idáig).

Ami fontos, a Symfony nem fut PHP4-en. A PHP5 az egyetlen teljesítendő kritérium azoknak, akik rendelkeznek már adatbázissal és webkiszolgálóval, mégis ajánlom a XAMPP telepítését ha követni szeretnék az alább leírtakat.

Telepítés

Tegyük be a Windows környezeti változók közé a PATH-ba a C:\xampp\php-t, majd indítsuk újra a számítógépet, hogy érvényesüljön, és innentől a php.exe-t és a PEAR-t mindenhonnan használni tudjuk. Akik lusták azoknak a set path=C:\xampp\php parancs is megfelel, de ők is rakják be a Windowson keresztül a PATH-ba, hogy ne kelljen ezt mindig beírni.

Az XAMMP telepítése után hozzunk elő egy Windows parancssort (futtatás -> "cmd") és telepítsük a Symfonyt a PEAR segítségével (1,908,095 bájtot fog letölteni):

pear channel-discover pear.symfony-project.com //hozzáadjuk a listához a forrást
pear install symfony/symfony
Ezután:

symfony -V
Ha a megjelenő üzenet: symfony version 1.0.8, akkor minden rendben történt, a Symfony telepítés kész.

Beállítás

Project könyvtár létrehozása
Ez a legnehezebb része ;) Lépjünk be kívánt könyvtárba (nekem C:\www lesz), ahol projectjeinket akarjuk tárolni, és:

mkdir testproject
Innentől minden Symfony utasítást ebből a könyvtárból fogok kiadni.
A webkiszolgáló beállítása
A webszerverünket kicsit konfigurálnunk kell, mert a Symfony könyvtárszerkezete nem a gyökérbe teszi az elülső vezérlőnket (amin keresztül az összes kérés kiszolgálásra kerül). Ez egyrészt lehetőséget ad nekünk arra, hogy a kódunkat ne egy nyílvános felületre, hanem a kiszolgáló egy olyan részére tegyük, amihez nincsen külső hozzáférés – védve ezáltal magunkat a törésektől –, mindemellett a Symfony mag nekünk a PEAR könyvtárba került, így bizonyos állományokat csak egy álnéven keresztül tudunk elérni. Ha projectünket kompaktálni akarjuk, akkor a symfony freeze parancs az összes Symfony állományt bemásolja nekünk a project könyvtárunkba.

A webkiszolgáló konfigurációs állománya a C:\xampp\apache\conf\httpd.conf, ennek végére szúrjuk be a következő bejegyzést:

<Directory "C:\php5\pear\data\symfony\web\sf">
    Allow from All
</Directory>

<VirtualHost *:80>
    DocumentRoot "C:\www\testproject\web"
    DirectoryIndex index.php
    Alias /sf "C:\php5\pear\data\symfony\web\sf"

    <Directory "C:\www\testproject\web">
        AllowOverride All
        Order allow,deny
        Allow from All
    </Directory>
</VirtualHost>
Ebből az első direktíva engedélyezi nekünk a létrehozandó Alias könyvtár hozzáférését, a következőben pedig beállítjuk a szerver könyvtárát – innentől ez lesz a project könyvtárunk –, az Aliast és a hozzáférést.

Fontos még megjegyezni, hogy a mod_rewrite modul bekapcsolása ajánlott, ha szeretnénk szép URL-eket. A httpd.confban keressük meg a következőt:

#LoadModule rewrite_module modules/mod_rewrite.so
és vegyük ki a sor elejéről a # karaktert.

Mentsük el a konfigurációs fájlt, az XAMPP kezelőfelületen pedig indítsuk újra az Apache-ot.

Példaalkalmazás

Project létrehozása

Lépjünk be a project könyvtárunkba (C:\www\testproject) és:

symfony init-project testproject
Ha beírjuk a böngészőbe a "localhost"-ot, és egy barna üdvözlő képernyő fogad minket, hogy "Congratulations! You have successfully created your symfony project.", akkor tudhatjuk, idáig sínen vagyunk.

Magyarázat a gyökérkönyvtárban létrejövő könyvtárakhoz:
  • app/ – itt lesznek az alkalmazásaink, amik egymástól elkülönített programok, közös konfigurációval és objektum osztályokkal
  • batch/ – ide lehet tenni a kötegelt utasítássorozatokat, mint például az adatbázis feltöltése példa adatokkal stb.
  • cache/ – ehhez a könyvtárhoz nem fogunk nyúlni, ide a Symfony generálja a gyorstár állományait, amiket a symfony cc paranccsal tudunk teljesen kiüríteni
  • config/ – minden alkalmazásra vonatkozó konfigurációs állományok
  • data/ – minden adat jellegű közös információ
  • doc/ – esetleges dokumentációk helye (hehe)
  • lib/ – közös osztálykönyvtárak
  • log/ – a Symfony ide fog nekünk naplózni
  • plugins/ – Symfony bővítmények, amiket különálló egységként lehet telepíteni, és a funkcionalitást eléri minden alkalmazás, ahol az engedélyezve van
  • test/ – teszt állományok
  • web/ – ez a könyvtár tartalmaz minden közös erőforrást, amit a webszervernek tudnia kell külön is kiszolgálni – itt van az elülső vezérlőnk (index.php), amin keresztül a Symfony fut, feldolgozásra kerül a kérés, lefutnak a különböző a különböző rétegek és végül, ami létrehozza a választ – ezenkívül ide kell rakni a CSS, JavaScript, kép fájlokat és feltöltött állományokat. Van még egy weblabor_dev.php is, az elülső vezérlőnk fejlesztői oldala, ami bővebb információkkal szolgál nekünk, fejlesztőknek. Lesz róla még szó.

Alkalmazás létrehozása

Most, hogy megvan a projectünk, hozzunk létre egy alkalmazást:

symfony init-app weblabor
Az apps/weblabor/ könyvtáron belül létrejövő könyvtárak:
  • config/ – alkalmazás specifikus konfigurációs állományok
  • i18n/ – lokalizáció és globalizációs információk
  • lib/ – alkalmazás specifikus osztálykönyvtárak
  • modules/ – modulok
  • templates/ – sablonok

Modul létrehozása

Na, most, hogy már van projectünk, van alkalmazásunk, csináljunk egy modult:

symfony init-module weblabor testmodul
Az apps/weblabor/modules/testmodul könyvtár tartalma:
  • actions/ – a vezérlő réteg, amely elvégzi nekünk a háttérmunkát, előállítja az adatokat (összehalássza az ORM-mel az adatbázisból), ezeket hívják actions-nek, innentől műveletnek hívom – ha bejön egy kérés, a keretrendszer érzékeli, hogy melyik modul és annak melyik művelete lett meghívva, majd átadja a vezérlést az actions/actions.class.php állományban található osztálynak, amelynek az a függvénye kerül meghívásra, ami a vezérlőt implementálja.
  • config/ – modul specifikus konfiguráció
  • lib/ – modul specifikus osztálykönyvtárak
  • templates/ – az egyes műveletekhez rendelt sablonok

Nyissuk meg a modulunk actions.class.php állományát. Itt van egy osztály:
class testmodulActions extends sfActions
és van neki egy nyílvános tagfüggvénye:
public function executeIndex()
Mint látjuk, ez a művelet nem csinál mást, mint átirányít minket a default modul module műveletére ($this->forward('default', 'module');). A tagfüggvény elnevezése mindig az executeNév() mintát követi, ahol a Név a művelet neve.

Ismerkedés a működéssel

Csináljunk egy új tagfüggvényt:

public function executeTest()
{
    //adatbázisból adatokat töltünk
    //minden mást csinálunk
    //stb.
    $this->test_data = array('egy', 'ketto', 'harom');
}
Na, ez akkor most reprezentál nekünk egy műveletet, amit elméletileg meg is tekinthetünk. Örülünk neki, nézzük hát meg, írjuk be a böngészőbe: http://localhost/testmodul/test.

Hoppá, nem látunk semmit, csak egy 500-as hibát, miszerint valami hiba történt a kiszolgáló oldalon. Hát ebből így nem tudunk megállapítani sokmindent, de legalább a látogatók nem láttak PHP hibaüzeneteket, meg összesett weboldalt (mint nagyjából mindent, ezt az oldalt is testre tudjuk szabni a konfigurációs állományokon keresztül).

Akkor most írjuk be a következőt: http://localhost/weblabor_dev.php/testmodul/test. Most meghívjuk elülső vezérlőként a weblabor_dev.php-t az index.php helyett. Láthatunk egy szép kis hibaoldalt egy üzenettel: "The template "/testSuccess.php" does not exist in:". Jajj, tényleg, elfeledkeztünk arról, hogy a műveletnek nem csak logikája van, hanem kell hozzá azért megjelenítés is.

Na, ha már itt vagyunk, nézzük végig ezt a hibaoldalt, mit is kapunk ezen a felületen. Kezdjük alulról most, ha már lesz tapasztalatunk, akkor az oldal tetején látható üzenetből is tudjuk mit kell tenni, de most nézzük végig. Az aláhúzott ...-okat érdemes kipróbálni, megtekinthetjük a globális változókat, a kérés, illetve a válasz konfigurációját és az egyéb Symfony beállításokat.

A listából a 15.-et nézzük meg. Látható hogy az sfFrontWebController dispatch() függvénye kerül meghívásra a weblabor_dev.php fáljban. Ez idáig nem meglepetés, ha megnéztük mit tartalmaz a fájl, de innentől nyomonkövethetjük, hogy milyen állományok milyen osztályainak milyen függvényei kerülnek meghívásra, és pontosan hol.

14.-ben az sfController osztály – miután a keretrendszer megállapította a kérésből, hogy mit is szeretnénk – továbbít minket arra a modul/vezérlő párosra, amit tényleg szerettünk volna, majd szűrők jönnek.

A szűrők olyan függvények, amelyek minden kérés előtt lefutnak, ezáltal nem kell minden vezérlőben és minden sablonban megtennünk bizonyos dolgokat. Ilyen például, ha Google Analyticsszel mérni szeretnénk a weboldalunk látogatottságát. Egy szűrőben elhelyezzük azt a logikát, ami lekezeli nekünk a kivételeket (például a saját kattintgatásainkat nem akarjuk, hogy mérje), ezenkívül biztos hogy mindig ott lesz az Analytics JavaScriptje. A szűrők, mint oly sok más téma, sajnos nem fér bele ebbe a bemutatóba.

Utánuk a renderelés következik, ahol a vezérlőtől kapott paraméterekkel "megtelik" a sablon fájl, majd ez elhelyezésre kerül az alkalmazás sablonjában és tadamm, kerül visszaküldésre a böngészőbe.

Namost, hogy kijavítsuk a hibát, hozzunk létre a apps/weblabor/modules/testmodul/templates könyvtárban egy testSuccess.php állományt. Ennek a formája mindig névSuccess.php.

Írjuk bele:

<h1>Hello-bello</h1>
<ul>
    <?php foreach ($test_data as $element): ?>
        <li><?php echo $element; ?></li>
    <?php endforeach; ?>
</ul>
Próbáljuk ki, hogy most működik-e: http://localhost/weblabor_dev.php/testmodul/test. Mint látszik, amit a vezérlő rétegben az akció logikájában megadtunk a művelet osztályának attributúmaként ($this->test_data = ...), azt most itt a sablonban közvetlenül elérjük ($test_data).

Ezenkívül figyeljünk fel a jobb felső sarokban lévő Web Developer eszközre. Itt részleteket tekinthetünk meg a kiszolgálással kapcsolatban (nekem pl. 2819.1 KB, Time 242 ms).

Segédek

A segédek a sablonozást segítik. Olyan előre legyártott HTML elemekről van itt szó, amiket nem akarunk mindannyiszor begépelni, hanem csak paraméterezni egy függvényt.

Egészítsük ki a kódunkat:

<h1>Hello-bello</h1>
<ul>
    <?php foreach ($test_data as $element): ?>
        <li><?php echo $element; ?></li>
    <?php endforeach; ?>
</ul>
<?php echo form_tag('test'); ?>
    <?php echo input_tag('test_txt'); ?><br/>
    <?php echo textarea_tag('test_txt2'); ?>
</form>
Ha megtekintjük az oldalt, a forrásban láthatjuk, lett egy űrlapunk, egy beviteli mezőnk és egy szövegdobozunk. A segédekről bővebben olvashattok (mint minden másról) a könyvben.

Egy kis adatbázis és egy kis admin generátor

Hívjuk meg a http://localhost/phpmyadmin/ címet, ahol megjelenik nekünk a phpMyAdmin. Csináljunk egy adatbázist "testproject" néven. Zárjuk be, többet erre nem lesz szükség.

Nyissuk meg a config/database.yml állományt és kommentezzük ki, ami ott van, majd a "dbname" helyére írjunk "testproject"-et:

all:
    propel:
        class:    sfPropelDatabase
        param:
            dsn:  mysql://root:@localhost/testproject
Ezzel megmondtuk a Symfonynak hogy hol van az adatbázisunk. Itt lehet saját adatbáziskezelőt is megadni, de nekünk jó a Symfonys MySQL, egyébként tudnánk így MSSQL-t, Oracle-t is használni. Ezen is látszik, a Symfony alapvetően úgy lett tervezve, hogy könnyedén testre lehessen szabni.

Nyissuk meg a config/propel.ini állományt és a megfelelő sort helyettesítsük a következővel:

propel.database.url        = mysql://root:@localhost/testproject
Ez a Propelnek, a beépített ORM eszköznek a beállítása. Ő fog gondoskodni arról, hogy nekünk csak definiálni kelljen az adatbázis modellt és ő mindent elintéz helyettünk. A fejlesztők dolgoznak egy alternatív ORM eszköz, a PHPDoctrine beépítésén.

Nyissuk meg a config/schema.yml állományt és definiáljunk a YAML leíró nyelv segítségével egy adatbázis táblát:

propel:
    ask_user:
        _attributes: {phpName: User, idMethod: native}
        id:          {type: integer, required: true, primaryKey: true, autoIncrement: true}
        nickname:    {type: varchar(50), required: true, index: true}
        first_name:  varchar(100)
        last_name:   varchar(100)
        created_at:  ~
A példánkban egy darab táblát nézünk meg, de ez a leírás támogatja a külső kulcsot és a megszorításokat is.
A YAML-ben az egymás alatt lévő elemeket szóközzel kell behúzni, és azonos szinten lévő elemek előtt azonos számú szóköz van. Tabulátort nem tartalmazhat a YAML fájl! A created_at mezőt a rendszer automatikusan felismeri és időbélyeg típusúra állítja.

Akkor most jöjjön a generálás:

symfony propel-build-all
Ez a művelet "all" néven a következő utasításokat végzi el, amiket egyenként is megadhattunk volna:

symfony propel-build-model //a sémánk alapján a model fájlok generálása
symfony propel-build-sql //a séma alapján az SQL relációk létrehozása
symfony propel-insert-sql //a legenerált SQL scriptet lefuttatja az adatbázisunkon
A megváltozott modell állományok miatt törölnünk kell a gyorsítótárat:

symfony cc
Ezzel a paranccsal minden létező gyorsítótárat kiürítünk. Specifikusan is meg lehetett volna mondani, hogy melyik alkalmazás, vagy azon belül melyik modul gyorstárát töröljük, de ez tutira töröl mindent.

A modell generálás ezzel kész. A lib/ könyvtárban lettek elhelyezve a generált állományaink, ezeket érdemes böngészni egy kicsit ha kezdők vagyunk Propelben. A lib/model/om-ben vannak a legenerált fájlok, tartalmazzák az SQL leképezést, és könnyen használható felületet biztosítanak a modell elemek módosítására, lekérdezésére, mint a BaseUser.php, ami megfelelteti nekünk a SQL táblát PHP változóknak és állandóknak, megvalósítja a beillesztést, a törlést és a módosítást. Ezek a fügvények a modell objektumunk tagfüggvényei lesznek.

A BaseUserPeer.php-ban statikus függvények vannak, amiket bárhonnan meghívhatunk, és egy objektum gyűjteményt vagy sima értéket adnak vissza.

Ezeket az állományokat, funkciókat kiegészíthetjük saját lekérdezésekkel illetve saját függvényekkel, erre vannak a lib/model/-ben a User.php és a UserPeer.php fájlok. Ha meg akarjuk változtatni az adatbázis sémánkat és újra legeneráltatjuk, csak a Base fájlok lesznek felülírva, az általunk kezelt kiegészítő állományok nem.

Próbáljuk most ki az így elkészített modellünket. Készítsünk gyorsan egy modult, amely megvalósítja nekünk a CRUD (Create, Read, Update, Delete) funkciókat, hogy tudjuk kezelni a táblában a sorainkat.

symfony propel-init-admin weblabor user User
Ezennel készen is van. Próbáljuk ki: http://localhost/user. Láthatjuk, hogy van egy "user list" feliratunk és egy "Create" gombunk. Használjuk hát a create funkciót, a megjelenő űrlapon látható, hogy amit a sémában "required:true"-nak adtunk meg az, ki van emelve, az id az nem látszik, mivel az elsődleges kulcs és ráadásul auto_increment, a created at pedig automatikusan egy dátum-idő mező a mellette lévő dátum kiválasztó eszközzel.

Adjunk hozzá a táblánkhoz egy pár sort, használva a "save and add" funkciót:
  1. sanyi – Sándor – Nagy – 2007-10-21 16:08
  2. geza – Géza – Kiss – 2007-10-21 16:09
  3. arpi – Árpád – Fogarasi – 2007-10-21 16:10

A "list" gombbal listázzuk őket ki. A listában az "ID" gombra kattintva tudjuk az egyes elemeket szerkeszteni.

Kis modell változtatás és admin generátor beállítás

Tegyük fel, akarunk egy olyan nézetet, ahol az egyén teljes neve szerepel. Ugye ez egy származtatott tulajdonság, az objektum tulajdonsága, ezért a lib/model/User.php-ban a helye. Nyissuk hát meg az állományt és írjuk bele a következőket:

class User extends BaseUser
{
    public function getFullName()
    {
        return $this->getFirstName() . ' ' . $this->getLastName();
    }
}
Ezáltal bárhol, ahol van egy User objektumom, ott annak lesz egy getFullName() tagfüggvénye. Varázsoljuk most ezt bele az admin listánkba. Nyissuk meg a apps/weblabor/modules/user/config/generator.yml-t, és írjuk bele a következőket:

generator:
    class:                 sfPropelAdminGenerator
    param:
        model_class:       User
        theme:             default
        list:
            display:       [_fullname, created_at]
            max_per_page:  2
            filters:       [nickname, created_at]
Töröljük ki a gyorsárat, hogy a következő kérésnél a keretrendszer a natív PHP kódot újragenerálja nekünk.

symfony cc
Hozzuk létre a apps/weblabor/modules/user/templates/_fullname.php állományt, ezeket hívják részlet sablonoknak, amelyek a modulhoz tartoznak, de bárhova beilleszthetők (include_partion('modul/művelet') függvény, de van még ezenkívül összetevő modul is, ezekről most nem ejtünk szót).

Legyen a tartalma:

<?php echo $user->getFullName(); ?>
Az admin generátor végigmegy a kilistázott elemeken és meghívja azt a sablont, amit hozzárendeltünk a "field" mezőben megadottakhoz. A sablonban paraméterként megkapja az aktuális objektumot, így annak tagfüggvényét meghívjuk, és azt íratjuk ki.

Próbáljuk ki, most hogy néz ki a listánk: http://localhost/user. Láthajtuk hogy megoldottuk a feladatot és ráadásul van saját lapozó fülünk is, mivel beállítottuk az admin generátornak hogy egy oldalra két elemet rakjon. Ezenkívül "filter"-t is konfiguráltunk, ez jobb oldalt látszik, próbáljuk is ki. Az admin generátor nem egy csoda, nem egy szuper szoftver, viszont rengeteg olyan dolgot tud ami egy weboldal adminisztrációs felületének tervezésekor előjön. A készítők koncepciója, hogy nem kell mindig újra feltalálni a kereket vagy a spanyol viaszt, amit valaki jól megírt, azt használjuk. Emellett szép struktúrált a kód, bármikor hozzáfejleszthetünk az admin generátor belső logikájához, és, ami megvan az jól dokumentált.

Akit jobban érdekel az admin generátor, annak érdemes megnéznie a "Hogy csináljunk blogot fél óra alatt" videót, ami bár elég régi, – még a 0.63-as verzióval készült – jól demonstrálja az admin generátor erejét, testreszabhatóságát. A teljes funkcionalitás puskája itt: http://www.symfony-project.com/blog//2006/04/25/admin-generator-cheat-sheet .

Modell manipulálás generátor nélkül + AJAX példa

Lássuk, hogy működik belülről a Propel és a Symfony, amit elrejt előlünk a generátor. Kicsit olyan érzésem van most, mint amiket Visual Studio .NET előadásokon szoktak mondani, "lehet ezt kódból is" (nyilván a példa súlya nem egyenértékű).

Tegyük fel, hogy szeretnénk egy oldalt, amin a felhasználóinkat lehet keresni. Tegyük fel, úgy döntünk, hogy egy kereső mező és egy gomb segítségével AJAX segítségével lekérjük az adott FirstName-mel rendelkező felhasználókat, és ezt belerakjuk egy divbe ágyazott táblázatba.

Vegyünk fel az adatbázisba a generátoros modulunkkal még egy pár embert, hogy tudjunk tesztelni. Hozzunk létre egy műveletet a testmodulban, ami paraméterként kap egy karakterláncot, végrehajt egy adatbázis lekérdezést a FirstName-re, és eltárol egy User objektum gyűjteményt.

    public function executeGetusersbyfirstname()
    {
        //paraméter lekérdezése
        $first_name = $this->getRequestParameter('first_name');

        //új kritéria objektum
        $c = new Criteria();
  
        //hozzáadjuk a 'first_name' = name feltételt
        $c->add(UserPeer::FIRST_NAME, $first_name);

        //lekérjük a kritériumnak megfelelő objektumokat
        $users = UserPeer::doSelect($c);

        //átrakjuk a sablon hatáskörébe
        $this->users = $users;
    }
Készítsünk ehhez egy sablont (getusersbyfirstnameSuccess.php):

<table>
    <?php foreach ($users as $user): ?>
        <tr>
            <td>
                <?php echo $user->getFirstName(); ?>
            </td>
            <td>
                <?php echo $user->getLastName(); ?>
            </td>
            <td>
                <?php echo $user->getCreatedAt(); ?>
            </td>
        </tr>
    <?php endforeach; ?>
</table>
Most, hogy megvan, ezt jelenítsük meg egy másik műveletben, a testmodul searchuser műveletében, ehhez vezérlő rétegbeli utasításokra nem lesz szükség, mivel csak kirakjuk a gombot és a beviteli mezőt:

    public function executeSearchuser()
    {
        
    }
Majd a sablon:

<?php use_helper('Javascript'); ?>
<div id="eredmeny" style="height:500px;"></div>
<?php echo input_tag('first_name'); ?>
<?php echo link_to_remote('Keress', array(
    'update'   => 'eredmeny',
    'url'      => 'testmodul/getusersbyfirstname',
    'with'     => "'first_name = ' + $('first_name') . value",
    'loading'  => "Element.show('indicator')",
    'complete' => "Element.hide('indicator')",
)); ?>
<p id="indicator" style="display:none">
    <img src="http://www.symfony-project.com/demo/images/indicator.gif" alt="Indicator" />
    Kereses folyamatban...
</p>
Teszteljük hát itt: http://localhost/testmodul/searchuser.

Végszó:

Láthattuk hát dióhéjban, mit tud a Symfony. A rendszer most ünnepli második születésnapját, és ketten kezdték el a fejlesztését. Rengeteg mindent tud még, amiről itt nem esett bővebben szó, többek között, bármilyen sorrend nélkül:
  • URL rewrite konfiguráció
  • Saját osztálykönyvtár beillesztése
  • Összetevő modulok
  • Szűrők
  • Gyorsítótár
  • I18N
  • Alkalmazás és modul szintű saját konfigurációs adatok megadása
  • Saját segéd írása
  • Beépített, konfigurálható jogosultság kezelés
  • Konfigurálható és bővíthető hitelesítő rendszer
  • Bővítmények, melyekkel gyorsan összerakható egy teljes portál: sfSimpleCMS, sfSimpleBlog, sfGuard, sfMediaLibrary, sfSimpleForum; ezeket gyorsan fel lehet telepíteni, konfigurálni, és folyamatosan fejlesztik őket

Ezekről teljes leírás található a könyvben, vagy a Symfony Project wikiben.

Remélem ez a bemutató sokatok érdeklődését felkeltette, és valamennyire képet ad a Symfonyról, és arról, hogy an induljatok el a felfedezésére.

Fabien Potencier, a project egyik vezetője mondta – mikor bejelentették, hogy a keretrendszerről megjelent könyvet online publikálják, ingyenesen letölthetővé teszik teljes egészében – hogy "That's how we see open source.". Ebből kiindulva írtam ma ezt a cikket, ha tetszett és értelmét látjátok, írhatok még többet is, részletesebbet is, és talán, ha egyszer elegen leszünk, beindíthatjuk közösen a symfony.hu weboldalt, hogy mi is hozzátegyünk valamit ehhez az egyre gyarapodó keretrendszerhez.
 
1

:)

juhasztibi · 2007. Okt. 31. (Sze), 10.33
Örülök, hogy végre valaki cikkbe öntötte a gondolatait erről a keretrendszerről. Nem tudom, hogy mennyire ismert ez a rendszer a fejlesztők között de már több helyről hallottam pozitív gondolatokat vele kapcsolatban. Remélem a magyar fejlesztői portál hamarosan elindul, sok szerencsét hozzá és köszi a cikket!

T.
2

köszönet

aston · 2007. Okt. 31. (Sze), 12.05
Köszönöm mindenkinek a segítséget aki egy kicsit is hozzátett ehhez a cikkhez.
Ha valakit érdekel a project amit csináltam a cikk írása közben, akkor belinkelem.
4

Linkeld be

Török Gábor · 2007. Okt. 31. (Sze), 14.52
Szerintem mindenkit érdekel aki elolvassa ezt a cikket, linkeld be bátran (:
3

hiánypótló

winston · 2007. Okt. 31. (Sze), 14.34
örülök a cikknek, főleg a nemrég volt cake cikk/post után hiánypótlónak érzem (már-már cikksorozat érzése támad az embernek :)), és az utolsó gondolatokra reflektálva: ha valóban volna kedved, én a részemről biztos szívesen látnék további cikket/cikkeket a témában.

üdv,
w.
5

szuper kedvcsináló

Pal_ur · 2007. Okt. 31. (Sze), 17.24
Nagyon jól érthető összefoglaló, ha szabad, lenne egy kérésem, ami nagyban segítené (nekem legalábbis) a tanulást. Jó lenne, ha minden kódrészlethez pontosan oda lehetne írni, hogy melyik útvonalon, milyen fájlba kerül. (Mondjuk én pl. az utolsó 4 kódrészletnél veszítettem el a fonalat :( )

Egyébként gratula, érthető, világos, és azért merült fel bennem a kérdés, mert éppen a kipróbálásnál tartok... :)
6

a projeck forrása

aston · 2007. Okt. 31. (Sze), 21.54
Tehát akkor a teljes project:
csak a project fájlok : http://symfony.hu/docs/testproject.zip
és annak akinek nem sikerült felrakni a symfony-t, itt van a fagyasztott verzió, amihez már csak webkiszolgáló kell és működik is ( 2,5 Mbyte ) : http://symfony.hu/docs/testproject-symfony108.zip

Pal_ur: az utolsó részt úgy állítottam össze, hogy kicsit bonyolultabb legyen és ha az előzőeket végigcsináltad és megértetted, akkor mennie kell.

Tényleg ha valaki végigcsinálta, kérem jelezze, hogy minden rendben ment-e.
9

sorrend

mdesign · 2007. Nov. 6. (K), 10.25
Szia!

Nálam csak akkor jött be a "Symfony Project Created" oldal, ha már a
symfony init-app weblabor
parancsot is lefuttattam. Egészen addig a testproject/web/ alatt nem léteztek az index.php és weblabor_dev.php fájlok.

Üdv Karesz
7

propel

oker1 · 2007. Nov. 4. (V), 00.29
Örülök a cikknek, nagyon jó a symfony, én egyenesen imádom.
Fantasztikus a doksi, szép a forrás, közösség is aktív, és folyamatosan fejlődik.
Az egyetlen komoly gyengesége szerintem a Propel, ami nyílván kényszermegoldás volt a kezdeteknél, mert nem volt más, de ez is meg fog változni, a Doctrine nagyon beindult (Summer of Code), az 1.1-ben pedig már pluginba kerül a Propel, így könnyen cserélhető lesz.
Annyira nem rossz a Propel sem, kisebb projektekhez bőven elég, de mi egy nagy rendszert fejlesztünk nagyon komplex adatbázissal, így hamar kijöttek a gyengeségei.
8

Doctrine

Hodicska Gergely · 2007. Nov. 4. (V), 02.44
A Propel az sajnos tényleg inkább korlát néha, mintsem segítség. Viszont a Doctrine már most is teljesen jól használható, az sfDoctrine pluginnal pedig gond nélkül lehet már most is használni a symfonyval. Ráadásul lényegesen gyorsabb is, mint a Propel köszönhetően annak, hogy Creole helyett PDO-t használ adatbázis absztrakciós rétegnek (elvileg majd a Propel 2 is már PDO-t fog használni). A Doctrine-ban a DQL elég jól használható, bár eleinte eléggé szokatlan volt a filozófiája.


Üdv,
Felhő
17

egyre jobb

mezitlab · 2007. Nov. 22. (Cs), 10.31
Egy evvel ezelott attertem drupalra, mert akkor azt tartottam forras szinten a leghasznalhatobbnak. Junius ota dolgozom symfony-val es nagyon megkedveltem. Nem talaltam meg ilyen atgondolt es jol hasznalhato keretrendszert. Orom ezzel a rendszerrel dolgozni!

Az utobbi fel evben sokat allasinterjuztam es a legtobb cegnel (akihez szivesen mentem volna dolgozni) mar symfony-t hasznalnak (kiveve azok, akik evek ota sajat nagy rendszeruk fejlesztik).
A propel-t tartom a legnagyobb gyengesegenek. Nem a sebessege, hanem a hasznalhatosaga es a dokumentacioja tekinteteben. A dokumentacio egesz jo, csak mire megtalalom amit keresek, arra oreg este lesz.
Remelem a doctrine feloldja a propel okozta frusztraciot.
10

Egy érdekes adat

Balogh Tibor · 2007. Nov. 6. (K), 16.29
Csak átfutottam a cikket, de a következő bekezdés érdekes:
Ezenkívül figyeljünk fel a jobb felső sarokban lévő Web Developer eszközre. Itt részleteket tekinthetünk meg a kiszolgálással kapcsolatban (nekem pl. 2819.1 KB, Time 242 ms).

Azaz az egyszerű "Hello bello!" oldalból másodpercenként ~4-et tud előállítani. Természetesen ez függ a gépedtől is, de nem hiszem, hogy egy PII300 gépen futott volna a dolog.
11

igen

aston · 2007. Nov. 6. (K), 16.48
PIII1200-on futott, most kipróbáltam többször is, ~150-160-as átlaggal futott le. Persze ez debug mód tehát itt lényegesen lassabb. Lemértem, debug mód nélkül ~80-90 ms alatt futott le.
12

Így már szebb az eredmény

Balogh Tibor · 2007. Nov. 6. (K), 17.17
Bár nem tudjuk, hogy volt-e valamilyen gyorsítótárazó PHP modul, um. APC, eAccelerator, Zend Optimizer. Ezek jelentősen, egy nagyságrenddel meg tudják dobni a futási eredményt. Jó lenne tudni, ezek létét/nem létét az összehasonlítás végtett.

Egyébként szerintem a kiszolgálható oldalak száma többet mond, vagy jobban megjegyezhető: ~80-90ms ~13-11 p/s.
13

na így ?

aston · 2007. Nov. 6. (K), 17.55
Ezt egy majdnem szűz XP-re telepítettem úgy ahogy leírtam. Egy XAMPP programot töltöttem le, ha jól tudom abban nincsen semmilyen gyorsítótár alapból. Tehát akkor most tartunk 13-11 p/s-nél, kíváncsi lennék gyorsítóval mennyi ...
14

Kösz a tájékoztatást!

Balogh Tibor · 2007. Nov. 7. (Sze), 12.07
Összehasonlítás végett fontos csak. Én is úgy emlékszem, hogy a XAMPP tartalmazza az APC és eAccelerator modulokat, de nincsenek betöltve. De lehet, hogy tévedek.
15

pluginok néha hibásak

virág · 2007. Nov. 7. (Sze), 16.59
A Symfony nagyon jó szerintem, legalábbis én szeretem.

Egy hibájára azonban szeretnék kitérni, illetve ez nem is hiba, hanem talán átgondolatlanság és időhiány a fejlesztők részéről - nincs idejük ellenőrizni mindent és lehetne még csiszolni a pluginok csatolásán. A hivatalos oldalon lévő pluginok gyakran okozhatnak fejfájást! A cikkben is említett "sfSimpleBlog" például nekem eléggé nagy galibát okozott, de említhetnék több plugint is amelyeket eddig teszteltem. Szóval ezekkel óvatosan, mert lehet velük baj, főleg az adatbázis részben. A telepítési útmutatókat mindig érdemes átolvasni, bár néha ez sem segít - persze ez mindenre igaz nem csak a Symfonyra.
16

nekem nem megy

juhasztibi · 2007. Nov. 15. (Cs), 21.55
Nekem nem megy a plugin telepítés ubuntu alatt, nem tudom mit csinálhatok rosszúl, vagy talán valami nincs jól beálíltva? Ha valaki tud segítsen, köszönöm!

Ezt kapom amikor próbálkozom:

juhasztibi@tibi:/var/www/sym$ php symfony plugin-install http://plugins.symfony-project.com/sfSimpleCMSPlugin
>> dir+      /var/www/sym/plugins/.channels/.alias

Warning: file_put_contents(/var/www/sym/plugins/.channels/pear.symfony-project.com.reg): failed to open stream: No such file or directory in /usr/share/php5/symfony/data/tasks/sfPakePlugins.php on line 225

Warning: file_put_contents(/var/www/sym/plugins/.channels/.alias/symfony.txt): failed to open stream: No such file or directory in /usr/share/php5/symfony/data/tasks/sfPakePlugins.php on line 226
>> dir+      /var/www/sym/plugins/.registry/.channel.pear.symfony-project.com

Warning: file_put_contents(/var/www/sym/plugins/.registry/.channel.pear.symfony-project.com/symfony.reg): failed to open stream: No such file or directory in /usr/share/php5/symfony/data/tasks/sfPakePlugins.php on line 242
>> plugin    installing plugin "http://plugi...-project.com/sfSimpleCMSPlugin"
>> pear      downloading sfSimpleCMSPlugin-0.7.2.tgz ...
>> pear      Starting to download sfSimpleCMSPlugin-0.7.2.tgz (75,788
>> pear      bytes)
>> pear      ..
>> pear      ..
>> pear      ..
>> pear      ..
>> pear      ..
>> pear      ..
>> pear      ..
>> pear      ...done: 75,788 bytes
>> pear      Fatal error: Cannot use object of type PEAR_Error as array in
>> pear      /usr/share/php/PEAR/Downloader.php on line 1240
T.
23

senki?

juhasztibi · 2007. Nov. 28. (Sze), 20.20
Senki nem tud valami tanácsot adni? A PEAR-el lehet valami gond?

Köszi,
T.
18

view rész

sayusi · 2007. Nov. 24. (Szo), 11.19
   1. <h1>Hello-bello</h1>  
<ul>  
<?php foreach ($test_data as $element): ?>  
<li><?php echo $element; ?></li>  
<?php endforeach; ?>  
</ul>  
<?php echo <span style="font-weight: bold;">form_tag('test')</span>; ?>  
<?php echo input_tag('test_txt'); ?><br/>  
<?php echo textarea_tag('test_txt2'); ?>  
</form>  
Nem olvastam végig, de ezzel a keretrendszerrel is a fenti kód a bajom. A Zend Framework esetében is itt kezdtem el nyaffogni, de nagyon. Pont azért akarok használni egy keretrendszert, hogy a html taknyolás bölcs és nemes feladatát is levegye a vállamról. A fenti szerint itt sem nagyon sikerült.

Hogy miért bajom ez?
- hogyan tudok normálisan js-t generálni?
- a megjelenített lap mit tud saját magáról (milyen hotkeyek vannak - vannak-e a hotkeyekben ütközések, a tag-ek id -ben vannak-e ütközések, melyikhez nem adtam meg id -t vagy melyikhez nem adtam js függvényt) ha developer módban fut akkor milyen ellenőrzéseket tud végrehajtani saját magával kapcsolatban (generálási idő)
- debug módban a sorvégekre tegyen vagy ne tegyen újsor jelet (hogy a html olvasható legyen)
- most több nem jut eszembe :)

Ennek ellenére használom a ZF -t és kezd kialakulni benne egy olyan rész ami ebben segít nekem (én csináltam) illetve ott kb. 2 hete jelent meg a Zend_Layout ami talán megoldást kínál erre is (nem próbáltam még).
19

Nincs ezzel baj

Joó Ádám · 2007. Nov. 25. (V), 17.58
Én speciel nem szeretem, mikor egy rendszer helyettem próbál meg gondolkodni.
  • Nem tudom, mire gondolsz pontosan, de a JS generálás egyszerűsítésére ugyanúgy lehet segédeket írni, mint, ahogy a HTML elemekéhez. Ha pedig architektúrális megfontolásokra, akkor az én megoldásom egyszerűen egy másik nézet.
  • Ne feledkezz el róla, hogy nem csak a HTML van a világon, az MVC lényege épp az, hogy a rendszer bármilyen nézetet képes produkálni. A gyorsbillentyűk, azonosítók ütközése pedig egyszerű konvenciókkal elkerülhető (én az id="azonosító" helyett az id="vezérlő_művelet_azonosító" formát használom).
  • Elég egy egyszerű bővítmény, amit kommentezgetsz a rendszerindítóban (egyébként ez is nézet-specifikus, PDF-nél példának okáért nem sok értelme van).

A Zend_Layout a kétlépéses nézet mintát valósítja meg, egyszerűen beilleszti a generált kimenetet egy „külső” sablonba. Emellett van hozzá pár segéd is, ami megkönnyíti pl. a <head> tartalmának módosítását a műveleteken és a műveletekhez tartozó nézeteken belülről (igen, tehát a nézet-specifikus dolgok különállóak).
Mellesleg egy-egy bővítménnyel, művelet- és nézetsegéddel én már régóta használom így a ZF-et, tehát a Zend_Layout megjelentéig sem okozott a dolog túl nagy problémát.
20

1.1

oker1 · 2007. Nov. 26. (H), 20.12
az 1.1-ben mar erosen valtozni fog a formkezeles

http://www.aide-de-camp.org/talk/7/international-php-conference-2007
21

nálam vmiért nem akar menni...

andrewboy81 · 2007. Nov. 27. (K), 15.07
Sziasztok!

Én is szeretném kiprobálni ezt a symfony-t, de nálam vmiért nem megy a
telepítés.
Amikor kiadom a:
pear channel-discover pear.symfony-project.com
parancsot, akkor a következö üzenetet adja:
Registry directory is not writeable by the current user

Namost ez egy windos xp sp2 ahol nincsenek felhasználók, csak én mint root.

Szóval nem tudok ezzel a helyzettel mit kezdeni, ha tud valaki kérem segítsen.

Köszi
22

Kezdetnek

Heilig Szabolcs · 2007. Nov. 28. (Sze), 16.16
Kezdetekben szerintem jobban jársz, ha egy sandbox-ot teszel le magadnak és abban kísérletezel.
24

httpd.conf

sonaba · 2008. Júl. 3. (Cs), 21.07
Bocsi, tudom, hogy nagyon láma vagyok, meg RTFM, meg minden, de nagyon nem értek hozzá, és emiatt nincs kedvem elolvasni temérdek oldalnyi leírást, szóval a kérdés a következő:

Mit kell hozzáírni a httpd.conf-ba illesztendő részhez, ha én nem a localhost alatt szeretném látni a projectemet, hanem a "http://localhost/projectem" alatt ?

Előre is köszi a segítséget.
25

Ez csak a felszín

postm · 2008. Aug. 19. (K), 11.09
Az a baj a cikkel, hogy nagy része csak az eredeti tutorial fordítása és nem mutatja meg a symfony igazi mélységeit.

Az MVC egész lényegét vágja haza az, aki a cache-ből kiveszi a templatet és elkezd bele SQL-t irogatni.

Pontosan erre szolgálnak a partialok ( nem partion ).

jelölés: _nev

A partialok arra lettek kitalálva, hogy egy alapértelmezett megjelenítést egy általunk preferáltal felül lehessen ütni. Pl adott a user osztály feltöltve minden adattaggal és mi a név helyére teszem azt a nickname-t akarjuk tenni. Ebben az esetben rendelkezésre álló függvényekkel akarunk operálni tehát a lib átíársa nem indokolt.


Következő lépés, amikor az új komponenshez adatbázis művelet is szükséges. - Component

jeloles: #nev

Erre a célra szolgálnak a komponensek. A komponens lényege, hogy hozzá egy action is tartozik. Az actionben lefutnak az adatbázis kezelő rutinok és a template megjeleníti az eredményt.

PeerMethod

Ezzel a két eszközzel egy fapados generált kódot is gyorsan fel lehet javítani, de nem szabad megfeledkezni a teljesítményről. A partial-t akkor van értelme használni, ha a rendelkezésre álló objektum fel van töltve a megfelelő adatokkal. Gyakori, hogy idegen kulcsokon keresztül linkelt tábláknál az idegen kulcs helyére a megnevezés mezőt kell tenni. Ebben az esetben a torzsObject->getCsatoltObject()->getMegnvezes() hivas először adatbázisból feltöltené a megfelelő csatoltObject-et. Ami azt jelenti, hogy egyetlen query helyett rengeteg fut, ami egy kisebb listánál is komoly teljesítmény csökkenéshez vezet.
Erre a célra találták ki a PeerMethod lehetőségét, ahol is a lista által által felhasznált metódust lehet beállítani. A keretrendszer alapból generál belső joinokkal ellátott peer metódusokat, ezek használatával az object lekérdezéskor a megfelelő irányú 1:N kapcsolatokat feloldja és az objektumot a csatolt objektummal együtt kérdezi le. pl TorzsObjectPeer::doSelectJoinCsatoltObject()


Lib

Természetesen bonyolultabb problémák esetén saját peer metódust lehet definiálni, aminek segítségével eléggé messzire lehet eljutni. Ehhez persze már lib szinten kell ügyködni. Ezt is elég jól támogatja a symfony, mint szinte minden osztály alapú programfunkciót. Ugyanis minden osztályból rögtön kettőt generál, az egyik mindig az automatikus tartalommal ellátott a másik pedig az ebből származó üres osztály. Az üres osztályokat a symfony csak inicilaizálja, de sosem generálja felül. Éppen ezért a generált osztályokat hagyjuk békén, és minden változtatást tegyünk az üres osztályokba.

Ha egy általánosan elérhető osztályra van szükségünk megint csak a lib-ben kell turkálni. Tipikus példa lehet egy kosár osztály, ami mind a frontend mind a backend felületen elérhető. Amennyiben nem tároljuk a kosár tartalmakat külön táblában, akkor nem is lesz generált skeleton osztály sem.

Szóval a cikk igencsak felületes, pont ezért sajnálatos, hogy egészen az AJAX-ig repül. Az alapokat átugrottad szerintem.
26

aha

aston · 2008. Aug. 19. (K), 11.25
Az a baj a cikkel, hogy nagy része csak az eredeti tutorial fordítása

Nem tudom miről beszélsz, az eredeti tutorialhoz ennek semmi köze, ha csak annyi nem hogy azt is olvastam anno.
és nem mutatja meg a symfony igazi mélységeit.

Nem is ez volt a cél.

Az MVC egész lényegét vágja haza az, aki a cache-ből kiveszi a templatet és elkezd bele SQL-t irogatni.

Nem tudom hol látsz ilyet a cikkben. Erről a cikkről van szó egyáltalán?

...

Szóval a cikk igencsak felületes, pont ezért sajnálatos, hogy egészen az AJAX-ig repül. Az alapokat átugrottad szerintem.

Igen, pont az volt a lényeg, hogy ne menjek bele a részletekbe, hanem egy általános bemutatást írjak.
27

mea culpa

postm · 2008. Aug. 19. (K), 14.14
Elnézést nem írtam ki teljesen, azt a gondolatot követtem, hogy a symfony alapjainak megértése nélkül az ember könnyen abba a hibába esik, hogy a cache-ből kimásolt kódot kezdi el toldozgatni. Nem esett szó ilyenről a cikkben, viszont a cikk nem is ad elegendő segítséget az elinduláshoz.

És pontosan ez az a pont, ahol nem értünk egyet, hiszen szerintem igenis egy ilyen komplexitású rendszerhez kell némi segítség az elején. Ilyesfajta ízelítő elég kevés szerintem, inkább csak összezavar, mintsem képet ad arról, hogy milyen szintekig lehet fel, illetve lejutni. A symfonyt elsősorban azoknak ajánlanám, akik összetett web alapú alkalmazást akarnak fejleszteni.
28

adott a lehetőség

Hodicska Gergely · 2008. Aug. 19. (K), 18.51
Szívesen várunk egy az alapokat alposabban bemutató cikket.


Üdv,
Felhő
29

en is varom

carstepPCE · 2008. Szep. 15. (H), 11.20
En is varok egy ilyen cikkre :-). At akarok en is terni a cakephp-rol. De lehet irok egyet magamnak.
Igazabol a tobb adatbazis kozotti adatmozgast, szinkronizalast, egyuttes (ket vagy tobb adatbazis kozotti tablak osszevetese) lekerdezest segito adatbazis absztrakcios reteget keresek, persze szigoruan jogosultsag ellenben. :-)

Udv
Sanyi
30

Doctrine

tolmi · 2008. Szep. 16. (K), 09.07
Te a Doctrine-t keresgéled. Ha már mindeki okosabb mint aston, én sem maradhatok ki a sorból :D
31

inkább xsl

postm · 2008. Szep. 23. (K), 13.27
Köszönöm, hogy megadtad a lehetőséget :), de inkább írtam egy Dia UML -> symfony schema konvertáló xsl-t, mintsem egy symfony tutoriallal vesződjek, amiből semmi hasznom nem származik. Pláne nincs értelme taglalni a 1.0.x verziót mikor a 1.1.x radikálisan más. Ettől még az eredeti cikk nem jó és én nem tudom elmagyarázni jobban, ez van...