Zend Framework: Úvod do frameworku
Chcete vytvárať bezpečné a moderné aplikácie? Nechcete viac programovať, čo už existuje a funguje? Prečítajte si nasledovný seriál a naučte sa modernému programovaniu pomocou ZEND frameworku.
Seriál: Začínáme se Zend Framework (3 díly)
- Zend Framework: Úvod do frameworku 6. 8. 2012
- Zend Framework: Hello world 20. 8. 2012
- Zend framework: základné súbory a komponenty 3. 9. 2012
Nálepky:
Úvod
Pri tvorbe internetovej aplikácie sa často programátor rozhoduje, či požadované častí vytvorí celé od začiatku alebo použije štandardizovaný framework. PHP frameworkov je v tejto dobe veľmi veľa. Existujú platené, ale aj voľné šíriteľné, niektoré často skončia na vytrvalosti vývojárov ešte pred vydaním prvej stabilnej verzie. V roku 2006 zverejnila firma Zend Technologies Inc prvú verziu s označením Pre Alpha Version 0.1.1. Dokonca obsahovala niektoré komponenty, ktoré ešte dnes tvoria jadro Zend Frameworku. Prvá produktivná verzia 1.0 vyšla v 2007 a verzia 1.5 v marci 2008, súčasná verzia je 1.11. Zároveň vývojári pracujú aj na verzii 2.0, ktorá bude prepracovaná a bude sa vo veľa veciach líšiť od verzií 1.x.
Zend Framework je Open Source framework a poskytuje veľa predností ako silnú priemyselnú podporu firmou Zend, partnerov ako Microsoft, Google, Dojo, IBM, vynikajúcu dokumentáciu vo viacerých svetových jazykoch a hlavné neustále vznikajú nové komponenty a opravujú sa chyby.
Hlavné výhody Zend Frameworku
- Dobrá dokumentácia – od začiatku je Zend dodávaný s referenčnou príručkou. Žiaden komponent nie je zahrnutý do distribúcie, kým neexistuje kapitola k nemu v referenčnej príručke.
- Licencovanie – Zend framework je distribuovaný pod novou BSD licenciou. Ak chcete prispievať, stačí podpísať licenčnú zmluvu a tým potvrdíte, že príspevok neporušuje práva tretej osoby.
- Komunita – Existuje veľa diskusných skupín, kde vývojári z celého sveta riešia problémy a máloktorý ostane nevyriešený.
- Web 2.0 – Zend Framework umožňuje od začiatku nasadenie najmodernejších internetových technológií. Veľmi úzko integrovaný je Dojo Toolkit, ale aj ďalšie, napr.: YouTube, Google, Flickr…
- Flexibilita – Nemusíte používať kompletný balík. Vyberáte si, ktoré časti sa použijú a je možné pridaním vlastných tried získať kompletný produkt odpovedajúci vašim predstavám.
Čo potrebujete?
Aby ste mohli využívať Zend Framework, je potrebné mať na počítači nainštalovaný webový server (napríklad Apache), PHP 5.2.4 alebo novšie a nejakú databázu (SQLite alebo MySQL).
V Apache treba mať aktivovaný modul mod_rewrite, ktorý slúži na prepísanie klasickej URL na skratený tvar URL optimalizovaný pre vyhľadávač.To znamená, že miesto http://nasprojekt/?controller=nieco&action=courobit&id=555 bude použitá adresa http://nasprojekt/nieco/courobit/555.
Pre PHP musí byť aktivované minimálne rozšírenia: ctype, pcre, Reflection, session a SPL. Sú využívané všetkými dôležitými komponentmi. Väčšinou sú tieto rozšírenia v PHP už aktivované. Niektoré komponenty vyžadujú aktivovať ďalšie rozšírenia PHP. Zoznam všetkých potrebných rozšírení pre jednotlivé komponenty nájdete na stránke http://framework.zend.com/manual/en/requirements.introduction.html.
Pre jednoduchú inštaláciu webservera APACHE s PHP a MySQL spĺňajúcim potrebné požiadavky môžete použiť napríklad XAMPP http://www.apachefriends.org/en/xampp-windows.html
Inštalácia Zend Frameworku pre Windows
Aktuálnu verziu môžete stiahnuť z internetovej stránky http://framework.zend.com/download/latest. Na výber je z viacerých možnosti. Kompletná verzia obsahuje Zend Framework, demo ukážky a Dojo toolkit. Minimálna verzia obsahuje iba Zend framework. Po kliknutí na požadovanú verziu ste presmerovaní na stránku s registráciou. Má to výhodu, že budete dostávať najnovšie informácie. Minimálny aj plný balík sa dá stiahnuť na spomínanej stránke aj bez registrácie.
Aby ste nemuseli vytvárať všetky potrebné priečinky ručne, slúži na vytvorenie tejto štruktúry aj s knižnicami súbor zf.bat. Nachádza sa stiahnutom archíve v priečinku bin. Pre použitie treba urobiť nasledovné kroky. Po stiahnutí si archív rozbaľte do ľubovoľného priečinka (napr: c:zend). Editujte súbor c:xamppphpphp.ini s upravte cestu include_path nasledovne a potom reštartujte apache:
; Windows: "path1;path2" include_path = ".;c:zendlibrary"
Ešte treba pridať do systémových premenných cestu k súboru zf.bat. Kliknite pravým tlačítkom na Tento počitač > Vlastnosti > Rozšírené systémové nastavenia a v záložke Spresnenie kliknite na tlačidlo Premenné prostredia. V časti Systémové premenné doplňte do Path cestu k priečinku, v ktorom sa nachádza zf.bat ( C:zendbin) a skontrolujte, či sa v ceste nachádza C:xamppphp. Ak nie tak ho tiež dopĺňte, jednotlive cesty sa odeľujú ;. Teraz už pomocou príkazového riadku jednoducho vytvoríte projekt. O tom, že všetko funguje, sa presvedčíte zadaním príkazu zf – vypíšu sa možnosti príkazu.
Vytvorenie nového projektu pomocou príkazového riadku
Pomocou príkazového riadka prejdite do priečinka, ktorý je dostupný z webservera.(Napr: C:xampphtdocs)
cd C:xampphtdocs zf create project zend.test
Vznikne nový priečinok zend.test. Ak je všetko v poriadku, po otvorení URL v prehliadači http://localhost/zend.test/public sa zobrazí stránka s vaším novým projektom.
Aby ste nepristupovali k svojmu projektu cez adresu http://localhost/zend.test/public je vhodné si vytvoriť virtualhost a projekt otvárať pomocou URL http://zend.test.
Vytvoríte ho odkomentovaním nasledovných riadkov v súbore c:xamppapacheconfhttpd.conf:
# Virtual hosts Include "conf/extra/httpd-vhosts.conf"
Do súboru C:xamppapacheconfextrahttpd-vhosts.conf doplňte cestu do vášho priečinka public v projekte zend.test. A reštartujte Apache.
NameVirtualHost *:80
<VirtualHost *:80>
DocumentRoot "C:xampphtdocszend.testpublic”
ServerName zend.test
ErrorLog "logs/zend.local-error.log"
CustomLog "logs/zend.local-access.log" combined
</VirtualHost>
Nakoniec treba ešte upraviť súbor c:windowssystem32driversetchosts. Doplňte doňho nasledujúci riadok:
127.0.0.1 zend.test
Základné pravidla programovania v Zend
Všetky pravidla pre programovanie v Zend frameworku nájdete na adrese framework.zend.com/manual/en/coding-standard.html. Snažil som sa vybrať tie najdôležitejšie.
- Súbory môžu v svojich názvoch obsahovať len alfanumerické znaky, podtrhovník _ a pomlčku -.
- Názvy premených musia obsahovať len alfanumerické znaky. A sú udávané v “camelCase” formáte,
- Názvy konštant musia obsahovať len alfanumerické znaky a znak podtrhovníka _.
- Názvy tried môžu obsahovať iba alfanumerické znaky. A názov by mal zodpovedať umiestneniu triedy v adresarovej štrukture. Napríklad
Zend_Form_Element_Textnajdete vZend/Form/Element/Text.php. Je povolená len jedna trieda v každom súbore PHP. - Pri metodach (funkciach) triedy sa vždy udáva ich viditeľnosť a to pomocou private, public alebo protected.
- Súbory , ktorý obsahujú len PHP kód, nesmie byť použitá ukončovacia značka ?>. Vôbec nie je požadovaná.
- Argumenty funkcie by mali byť po čiarke oddelené jednou medzerou.
Odkazy, ktoré sa môžu zísť
- http://framework.zend.com – Oficiálna stránka
- http://framework.zend.com/manual/en – Referenčná príručka
- http://framework.zend.com/about/faq – Najčastejšie otázky a odpovede
- http://forum.zendframework.cz – České forum
‚Prečítajte si nasledovný seriál a naučte sa modernému programovaniu pomocou ZEND frameworku.‘
nezda sa mi ze ZF zabespecuje moderne programovanie… pokial chcete naozaj kvalitne OOP, php 5.3 (5.4) a nie nejaky ztary a robusny framework tak by som urcite nevolil ZF…
Ahoj všem,
je tu někdo fundovaný, kdo má praktické zkušenosti s ZF, Nette a Django a mohl by vypíchnout výhody/nevýhosy výše zmíněných?
Rad bych se naučil nějaký fw a umím python (php jen trochu) tak si rád nechám poradit.
Dík
Ked vies Python, kasli na PHP frameworky a chod do Djanga alebo Tornada.
aj pod PHPkom sa daju najst celkomn pekne FW http://laravel.com/docs
Myslis si ze python je lepsi/ rychlejsi na weby ako php ktore je na to asi lepsie pripravene?
Python je mocnejsi jazyk ako PHP. Za vsetky spomeniem napr. operator yeld. Netvrdim, ze s PHP sa neda vyriesit nejaky problem, ale ak niekto ovlada mocnejsi jazyk, pride mi to zvlastne downgradovat.
O PHP sa tvrdi, ze je rychlejsie ako Python alebo Ruby, na druhu stranu sa ale aj tvrdi, ze PHP nevyskalujes tak jednoducho ako tie dva jazyky. Kazdopadne (ako mi raz povedal nas admin), az raz budes mat na stranke 100000 unikatov, budes riesit uplne ine problemy ako volba jazyka.
tak to je chytry clovek a mel pravdu
Já mám zkušenosti s Nette, Symfony a Djangem.
Nette mám rád na menší projekty. Jsem v něm asi nejrychleji schopný udělat menší webík (ale možná je to tím že s ním mám nejvíc zkušeností).
Symfony je robustní FW, který bych volil pro velký projekt kdyby musel být psán v PHP.
Django je v současnosti můj favorit. Nejvíc se mi líbí na něm líbí integrované ORM, které mi opravdu sedí. Oproti Doctrine s jehož konfigurací a integrací do frameworků jsem vždy bojoval a nakonec ho raději nechal plavat.
mam skusenosti v php len so symfony2 a nette, ale ak ti mam poradit, pozri sa na dokumentaciu k doctrine/propel/dibi/whatever a potom na django orm a myslim ze budes mat jasno :-)
Vyhody? Python neni PHP. Ad frameworky: Django/Flask/Pyramid/Bottle.…?
Jestli fundovany, to nevim, ale v ZF programuji pres 4 roky, v Nette pres 1.5 roku – bohuzel. Nette je sileny paskvil, humus. Takze jestli nekdo chce pouzivat PHP framework, tak at jde do ZF. Sice je ZF docela moloch, ale zase se nemusi clovek starat o chybejici zakladni veci. A hlavne, existuje dokumentace i plno lidi, ktery ZF umi a poradi. U Nette je to cira zoufalost, v podstate se nic nezlepsilo od body Nette 0.9. Bohuzel existuke plno lidi i firem, ktery Nette paskvil prosazuji a chvali :(
Můžeš být konkrétní, co se paskvilnosti Nette týče?
Zdravím,
pokud umíš python, určitě bych volil Django. Budeš moci používat jazyk, který je mocnější než PHP, jak už tu bylo zmíněno a tím pádem alespoň dle mého názoru bude čistší a přehlednější kód.
Jinak v práci používáme ZF na své projekty používám nette. Na ZF se mi líbí hlavně to že je poměrně transparentně napsaný, program v ZF se dá dobře krokovat a pořád je nějak tak znát co se vlastně děje. Další plus bych viděl v tom, že je připravený na testování pomocí phpUnit. Jako mínus bych viděl defaultní absenci šablonovacího systému – view pak tvoří klasický špageti kód (samozřejmě je možnost použít nějaký šablonovací systém, což se třeba u nás v práci nestalo). Osobně mi také nesedí konvence CamelCaps zkombinované s podtržítky – dle mého relikt PHP4, kdy parametry tříd nebyly protected. Docela šílená je pak práce s formuláři. Navíc celý ZF je značný moloch.
Nette je obecně magičtější, používá poměrně hodně callbacků a tak program při krokování může dost nelogicky přeskakovat. Jako hlavní výhody bych viděl Laděnku – knihovnu pro zobrazování pěkných chyb :), šablonovací systém latte, inteligentní robotLoader, díky kterému můžeš mít třídy pojmenované a zanořené v soubrové struktuře jak ti vyhovuje. I díky latte je práce s formuláři mnohem pohodlnější než v ZF. Vyhovuje mi také pojetí signálů. Nette také spoustu věcí defaultně cachuje (šablony, výstup z robotloaderu, do budoucna také routy) což může apliakci značně zyrchlit. Jako nevýhody bych viděl např. to že se při testování samotného FW nepužívají standardní nástroje jako phpUnit a vůbec absence podpory pro jednotkové testování v samotném FW, již zmiňovaná magičnost a také to že FW se z každou vydanou verzí zásadně mění což jej značně znevýhodňuje ve firemním prostředí.
Ufff, snad jsem vyjmenoval nejpodstatnější radosti a strasti ZF a Nette. Připomínám, že se jedná o můj subjektivní pohled na věc a cílem není vyvolat flamewar. Navíc, až už se nebudu muset programováním živit, naučím se Python, Django a se sklenkou velmi staré whiskey budu vzpomíat na to jak jsem kdysi používal jazyk, jehož autoři se neshodli na konvenci, pořadí parametrů a zavedli funkce jako extract :)
Co si představuješ pod pojmem „podpora pro jednotkové testování“?
Já osobně třeba velmi často používám třídu Zend_Test_DbAdapter.
To pak ale nepíšete jednotkový test ale spíš test integrační ne? Resp. se to dá použít tak maximálně na jednotkový test nějaké mezi-třídy, která odděluje Vaší aplikaci od databázového engine. Jinak byste nic takového při psaní jednotkových testů neměl potřebovat :-)
a když testuju metodu třídy která v konstruktoru žere nějaký data a sem takovej truhlík že práskam zdroj těch dat?
Nejsem si jistý zda zcela rozumím. Takovým typickým příkladem, který ve firmě testuji je nějaká metoda modelu, která zavolá nějaký SQL dotaz s určitými parametry, na vrácené záznamy ještě něco pověsí a celou tu sadu dat vrátí. Z pohledu jednotkového (alespoň dle mého názoru) testování pak řeším několik případů:
1) Jestli je sada vrácených záznamů správná -tj. jestli byly na sadu dat vrácených z DB správně navěšeny ony dodatečné informace
2) Jestli byl do DB poslán správný dotaz.
K obojímu používám Zend_Test_DbAdapter, který mě odstíní od reálné DB. Pak je splněna definice jednotkového testu (nepoužívá filesystem, db, síťové spojení atd., je dostatečně rychlý)
@jos: definuj slovo zdroj:-) data mají vždycky nějaký zdroj, že jo. V testu vždycky nějaká data musíš připravit, jde o to jak se to udělá. Připravovat fake strukturu DB je IMHO zbytečné (a pokud se fakt připojuju k DB tak i děsně pomalé).
@Clary: Nejsem si jistý, jestli jsem takhle na rychlo pochopil význam třídy Zend_Test_DbAdapter, nicméně to na mě udělalo dojem, že si někam do paměti vytváří jakousi „strukturu databáze v paměti“ se kterou pak operuje. Není to zbytečné? V testu připravím data (zpravidla nějaké pole či tak něco), předám je nějakému poskytovateli, který je ve vhodnou chvíli vráti zpět skrze nějakou fake-závislost (FakeModel či něco podobného). A ano, pak testuju jestli se odeslal správný dotaz a že se mi ta data vrátila v očekávané podobě. Ale říkám, možná jsem to špatně pochopil…:-)
Přesně to dělá Zend_Test_DbAdapter – poskytuje stejné rozhraní jako má jakýkoliv Zend_Db_Adapter, ale data jsou uložena ve formě asociovaného pole pouze v zásobníku, ze kterého se pullne při každém dotazu volanéhoho nad tímto adaptérem. Někdy ani není potřeba jej nějakými daty plnit a pouze se testuje dotaz přes
$adapter->getProfiler()->getLastQueryProfile()->…
Prostě takový fake objekt, který je už Zendem poskytován standardně :)
… a na jediný rozšířený jazyk, který nemá ani datový typ řetězec. :-)
To co PHP nazývá řetězci jsou ve skutečnosti jen binární bloky – pole bajtů. Dokonce se s tím tak i pracuje.
Proc zacinat s dalsim serialem o ZF1, kdyz je venku ZF2 RC1?
A určitě všichni začnou hned používat dvojkovou Pokud bude zájem (na straně čtenářů i autora), není problém navázat dvojkovou verzí.
Lenze ZF2 je od zakladu prekopany, da sa samozrejme naviazat ale naco to je dobre?
Hlavne, ked je predpoklad, ze ZF 1.x bude podporovany do 2014.
http://framework.zend.com/about/zf2-faq
To je sice pravda, ale pokud se nekdo chce seznamit se ZF nebo v nem zacit psat aplikace, je podle mne cire silenstvi psat ted neco v ZF 1.x, ikdyz bude podporovane do 2014, kdyz se rovnou muze zacit ucit ZF2. Prijde mi to jako hloupost, ted se naucit neco, co je uz ted pohrbene… :D Ale to je v podstate i PHP :-)
to, ze je php slycham uz snad 5 let… NENI a kdo vi kdy bude, urcite nejmene dalsi dekadu v pohode prezije.
php je pro hooodne velkou mnozinu projektu good enough – nic vic nic min.
A co řada projektů, které jsou z ZF napsané? O ty se někdo musí starat, firmy na to budou ještě dlouho potřebovat (a shánět) lidi.
Nemám teď sice v plánu měnit zažitý framework, ale říkám si, že si nemůžu nechat ujít flame war v diskuzi pod článkem… a tady nic není. Jak je tohle vůbec možné? XD
Musíte počkat na článek, ve kterém bude popsáno jak se se Zendem pracuje. V takhle obecném úvodu se není ani čemu zasmát.
99 % stránok využije zo samotného Zend Frameworku maximálne 30-40 %. Načo dávať obrovský nákladný vlak tam, kde stačí jeden kamión? Tým chcem povedať, že je zbytočné nahadzovať cca 20 MB framework na 99 % stránok, pretože ho nikdy plne nevyužijú. Pre mnohé stránky je vhodnejšie použiť oveľa menšie frameworky, ktoré sú zvyčajne oveľa rýchlejšie. Pri programovaní s pomocou Zend Frameworku sa často stáva, že nejaká vymoženosť tohto Frameworku robí „zbytočnú prácu“ (zbytočnú myslím to, že dá sa to spraviť aj jednoduchšie, pretože programátor nevyžaduje od tejto vymoženosti, aby všetko robila čo dokáže, ale len určité čiastky z toho čo dokáže). Potom sa to rieši tak, že príslušná knižnica sa v Zend Frameworku vypne a naprogramuje si ju programátor sám, aby to bolo rýchlejšie. Lenže potom ZF stráca svoju výhodu a tou by mala byť univerzálnosť, pretože pri ňom si takmer nič nemusí programátor doprogramovávať. Programovanie s pomocou ZF má teda síce aj silné stránky, ale vzhľadom na svoju objemnosť aj slabé stránky. Navyše je na naučenie jeden z najťažších frameworkov. Ale to je skôr subjektívny dojem, pretože nie každý by so mnou súhlasil.
Pre jednoduché stránky by som odporučil:
– CodeIgniter
– CakePHP
Pre zložitejšie:
– Yii framework
– Symfony
V každom prípade ZF by som skôr neodporučil ako odporučil.
Zend Framework jako celek má 25mb, pokud si vybereš jenom to co potřebuješ (View Controller Form Acl Application Db Layout) tak se v pohodě vejdeš na 2.5mb
V dnešní době kdy má hosting kapacitu 500mb na jednu stránku, nevidím důvod proč šetřit na frameworku, jsem prostě líný člověk a jsem rád, když už mám nástroje, které mohu v pohodě použít.
Jenže tady nejde o velikost kódu, jako o množství příkazů, které se musí při každém požadavku načíst a vykonat. Pokud na to potřebuji celých 2.5 MB, to už je pěkných pár desítek tisíc řádků kódu! Pokud by každý řádek měl v kódu smysl, tak neřeknu, ale mnohdy je většina kódu zbytečná. Samozřejmě, pokud píšeš aplikaci pro deset souběžně pracujících uživatelů a máš na to celý server, tak není problém.
Tak tak, dokud to cosi bude pouzivat 5 lidi, tak to resit netreba, ale az to budou tisicovky, tak uz se zacne projevovat kazdy zbytecny kus kodu.
Navic obecne u frameworku sem dycky narazil na to, ze OK, neco takovyho potrebuju, jenze fous jinak.
delam drupal, ktery osobne povazuju spis za framework nez CMS. spousta lidi o nem rika, ze to je line a pomale bumbrlik, ma tam hooky, spousty souboru, includu apod. tahne si veci ktere nepotrebuji. pokud budeme na klasickem hostingu tak maji v podstate pravdu – kazdy prekladovy string je dotaz do DB (napr.). Jeden web mi s rostouci navstevnosti zacal vytezovat server tak jsem zacal resit optimalizaci:
1) je tam vetsina provozu anonymni? => varnish, snizeni poctu requestu na apache na cca 15%
2) APC jako opcode, zrychleni pageload na cca 40% puvodniho (eaccelerator nebo xcache delaji +/- stejne dobrou sluzbu)
3) memcached demon => snizeni sql provozu nekam na 20% puvodniho (z jistych specifickych duvodu nemuzu pouzit APC cache ackoliv je o dost rychlejsi)
4) pokud tam ma byt zpracovano vyhledavani tak to frknout na solr.
pri dnesnich cenach RAM se daji fakt delat zazraky.
jasne je to konkretne drupal, ale stejne to podle me musi fungovat u jakehokoliv FW – opcode, memcache/mongo/cokoliv, reverzni proxy… pokud moje aplikace umi s temahle vecma mluvit tak nepotrebuju resit jestli includuju knihovnu s 5 radky nebo 500 radky. neberu v potaz extremni praseciny v kodu, ale kod napsany dle zvyklosti dobreho FW podle me pobezi rychle at z toho vyleze firemni prezentace nebo evidence objednavek. mimochodem i do toho Drupalu si v nekterych projektech casti zendu taham proste protoze mi poskytuji luxus pohodli v nekterych tech castech ktere resi (myslim ze to bylo treba oauth, nejaky soap apod.)
Souhlas, pokud je ale aplikace určena na klasický webhosting, mám většinou smůlu, protože tyto vychytávky tam většinou nemají :( Chtěl jsem před nějakou dobou třeba zkusit NoSQL a zjistil jsem, že pokud to nedám na vlastní server, nemá to uplatnění.
to je pravda, ale dneska se da solidni VPS poridit za 200,- mesicne+dph. I bez varnishe kdyz pouziju memcached + opcode APC tak mi spadl load serveru nekam na 20% puvodniho pred zapnutim tohoto. Nastesti existuji i VPS kde to neni na „sloty“ ale cpu, ram i disk se zvetsuji samostatne takze mi k relativne slabemu CPU a malo mista na disku(ktere malokdy potrebuju) poskytnou relativne levnou rychlou RAM. (maily resim zasadne na gmailu)
asi tak nejak, neskaluje sa poctom volanych funkcii ale architekturou.
CodeIgniter neznám. Zato CakePHP ano. Můžeš mi vysvětlit v čem je lepší? Já ho nesnáším.
Video tutoriál ti povie viac:
http://www.zajtra.sk/serial/6/codeigniter-videotutorial
Jako člen české ZF komunity, který používá denně Zend Framework již 5 let, musím říct, že je trochu pozdě začínat čtenářům přibližovat ZF 1, který je z dnešního pohledu současného vývoje v PHP přeci jen trochu deprecated a tutoriálů se po netu válí hromada. Některé novinky z dvojky jsou sice backportovány do poslední verze 1.12 ale dvojková verze je skutečně překopaná od základu a přestože je venku RC2, tak se kód stále mění pod rukama, půlka testů vám failne a tak nemá zatím moc smysl psát nějaké návody či tutoriály. (Ačkoliv to jako komunita děláme, akorát z toho nejsme občas moc nadšení :)
Pokud si chcete popovídat o ZF s komunitou, přiďte na příští ZF meetup
http://srazy.info/prvni-zf-meetup-praha/
http://www.zendframework.cz/
suhlas, nema zmysel zacinat s tutorialom pre 1.* verziu
co sa tyka 2.0, vidim na webe rc1, predpokladal som skor, ze v ramci rc sa budu veci ladit, nie menit pod rukami :) fail polovice testov v rc sa mi k zendu dajako nehodi, beta nepoviem …
Ono je to složité, když na nový je ještě brzy a ten starý má pomalu začít mizet. Rozsáhlejších textů v češtině jsem opravdu moc nenašel, což je důvod proč začínáme tenhle seriál (paradoxně ve slovenštině, ale to je jedno).
Na sraz bude lepší upozornit, až bude vypsán nějaký termín. Rádi zveřejníme.
Denne so ZF pracujem vyhovuje presne mojim požiadavkám. Áno je pravda že sa učí tažšie keď je na to človek sám, avšak flexibilita ktorú poskytuje je geniálna.
Jedinú nevýhodu ZF1 vidím v tom že má všade napchaté require_once, ja to riešim tak, že z frameworku vytiahnem iba požadované triedy a preženiem ich buildom do phar-u.
Tento tutoriál ma potešil, hádam sa dozviem aj niečo nové.
Kedysi som spravil maly benchmark zamerany prave na
require_oncev kazdej Zend triede. Netestoval som vsak s oppcache ako niekto spominal v komentaroch.prave kvuli absenci opcache je ten benchmark v podstate nicnevypovidajici.
Oplati sa zacinat s nejakym frameworkom ked mam len minimalne zaklady PHP?
Urcite ano, ja som sa zaklady OOP naucil tak, ze som zacal experimentovat prave so Zend FW. Poznam ludi, ktori sa naucili Ruby, tak ze zacali pracovat v Railsoch.
„I cesta dlouhá tisíc mil začíná prvním krůčkem“ – čínské přísloví
Ničeho se neobávejte. Prostě se budete učit na frameworku i to PHP. A co? Když to bude pro někoho zábava, pojede mahoru ve znalostech rychleji než namydlený blesk.
Par nazoru se ptalo, kterym frameworkem zacit.
Setkavam se s tim, ze programatori v PHP neumi pouzivat SQL. Ulozene procedury a view jsou pro ne spanelska vesnice.
Misto napsani procedury ci view v SQL, ktera jim data pripravi do presne podoby kterou potrebuji, zacnou vytvaret slozite objekty. Vysledkem pak je, ze misto zavolani jednoho dotazu, aplikace vyrobi desitky dotazu do databaze.
Neni az tak slozite, naucit se SQL. Osobne pouzivam PostgreSQL s plpgsql (nejvyvinutejsi SQL zdarma). Muzete velkou cast aplikacni logiky prenest az do databaze. Odmenou vam bude rychlejsi aplikace. A i z hlediska testovani a udrzitelnosti je dobre mit rozhrani, kde z jedne strany je databaze, ktera dava data v odladitelnem a definovatelnem formatu a z druhe strany PHP framework, kde se postarate o jejich zobrazeni.
Poznamka: Vse co se da naprogramovat v PHP, lze naprogramovat i v plpgsql. Dosel jsem az tak daleko, ze mi obcas volani dodazu do databaze vraci serializovane asociativni pole (miluji asociativni pole jak jsou udelany v PHP. V jinych jazycich to je opruz). V PHP pak staci unserializovat.
Jeste se tu obevila v diskuzi zminka o cache. Drive jsem pouzival eaccelerator. Ten uz je ale temer nekompilovatelny v novejsich distribucich. Takze jsem zacal pouzivat APC (interface pro cache resi nezavislost). Malo kdo to pouziva takto: krome cache sriptu, umoznuji ulozit si perzistentni data. Teoreticky priklad: na kazde zobrazene strance generujete strom zbozi. Jeho vypocet zabere nejake dotazy do databaze a nejaky vypocetni cas. Pritom strom zbozi meni svou strukturu s frekvenci mesicu. Proc ho pocitat pokazde znovu, kdyz muze byt ulozen v cache.
Setkávám se s lidmi, kteří umějí SQL, možná i stored procedures nebo views, ale neumějí používat databáze. Neumějí navrhnout strukturu tabulek, nevědí co se děje v pozadí.
Používat stored procedures, views, atd. je kontraproduktivní, pokud se nechcete vázat na jednu databázi. Řešit logiku a program na úrovni databáze nemusí být vždy nejlepší. Ale může.
Ohledně frameworku. Je dobré začít s čistě psaným frameworkem, která má ideálně čisté MVC. Tedy nikoli Nette a další prasečiny.
Pokud někdo začíná, měl by se naučit na krásu čistoty architektury frameworku a efektivnost, kterou to přináší.
Jazyk, ve kterém je to psané není až tak podstatný, je fuk jestli PHP, Python, Ruby, Java, nebo něco jiného.
Pokud se naučíte špatně, budete se špatně přeučovat.
„Používat stored procedures, views, atd. je kontraproduktivní, pokud se nechcete vázat na jednu databázi.“
Tento argument na viazanie sa na databázu som počul už mnoho krát a príde mi dosť mimo…
Nestretol som sa ešte s tým, že by projekt „pendloval“ z jedného typu databázy na druhú. Samozrejme môže k tomu dôjsť pokial sú v úvode projektu chybne vybrané technológie. Pri koľkých projektoch sa vám to stáva?
Takovému SAPu se to třeba stalo.
K migrování mezi databázemi může dojít nejenom chybně vybranými technologiemi. Ale může to být i záměr nebo podstata fungování projektu.
Mimochodem, právě řada webových redakšních systémů má v základu možnosti pracovat na několika databázových strojů – považoval byste to za chybu? Doufám, že ne.
Mě hlavně přijde mimo akcentovat (tedy nejsem proti tomu v rozumné míře) views a stored procedures, protože vyšší jazyky používané v projektu mají většinou lepší prostředky a lepší vývojové nástroje než mají databázové stroje.
Jistě, že se dá v každém programovacím jazyce, který má čistě teoreticky úplnou vyjadřovací schopnost napsat cokoli. To si můžete snadno vyzkoušet na takových jazycích jako je třeba Brainfuck. Také můžete vyjádřit názor, že lze psát programy v Brainfucku namísto blbého PHP, Pyhotnu apod. – a je jenom leností lidí, že to nedělají. To je zajisté pravda, ale není to efektivní.
Programovací prostředky většiny databázových strojů jsou poměrně dřevěné a neobratné. Programovací jazyk běžného typu je často 100 × lepším a flexibilnějším řešením.
Kromě toho vlastní programovací jazyk má člověk pod kontrolou, móresy výrobců databázových strojů nikoli.
Databázové stroje mají dělat to na co jsou stvořeny. Tedy pracovat s permanentními daty a zaměřit se na maximální rychlost a efektivitu. Pokud views a stored procedures přispějí k tomuto cíli (a sem tam ano), pak ok.
Ale aplikační logika je mimo databázový stroj.
U view jde o to, ze spojujete nekolik tabulek. Psat nekolikanasobne joiny do mnoha mist v programu je dost neudrzitelne. Bohuzel, prilis casto narazim na projekty, ktere joiny nahrazuji postupnym volanim dotazu.
Treba takovy trigger, je velmi mocny nastroj. Je to mimo jine takova hraz proti chybam v programu. To bez procedury v SQL neudelate.
Pokud aplikacni logika meni data v tabulkach, pouziva transakce, tak prenesenim teto logiky do SQL nekolikrat aplikaci zrychlite. A jakykoliv sebelepsi a 100x flexibilnejsi programovaci jazyk vas nezbavi SQL dotazu. Jo, zbavi vas SQL, ale jen tak, ze ukol za vas rozlozi do 100x narocnejsiho reseni, kdy za vas vygeneruje desitky SQL dotazu. Takze misto procedury na 30 radku mate program na 20 radku, jen o rad pomalejsi.
Mate pravdu, ze je velmi tezke zajistit prenositelnost aplikace mezi jednotlivymi SQL. Treba autoincrement u MySQL v.s. sequence u PostgreSQL se dost tezko prenasi. Ani first 10 u firebirdu vs limit 10 u ostatnich SQL neni jednoduche preklenout. Ted potrebuju vyrobit nejaky syncml server. Ktery bude pouzivat data ze stavajiciho CRM. Nasel jsem nejaky nad MySQL. Predelat ho do PostgreSQl je silenost. Protoze pouzivaji neco, co jim generuje SQL dotazy (tedy framework nad SQL). Jak by bylo krasne, kdyby pouzivali view. To bych jim mohl podstrcit virtualni tabulku, ktera by brala data ze stavajici databaze a tvarila se jako format ktery oni vyzaduji. Vcetne update rules.
Ohledne SAPu – delal jsem v nem naposledy pred 10-ti lety. Byl nainstalovany nad Oracle. Nejvykonejsi databazi na svete pouzival jako filesystem. Snad se od te doby pohli.
Nechtel jsem tady vyvolavat zadny flame. Jen chci rict, ze frameworky pouzivaji databaze. A to je jejich vykonovy limit.
A ze stoji za to naucit se SQL. Pokud tedy vas projekt uklada data do databaze.
1) Mezi psaním SQL do programu a zasláním SQL dotazu do databáze mohou být v projektu ještě další vrstvy.
Tedy to co se píše v programu nemusí být to co doleze do databázového stroje.
2) Já nejsem proti view, proti triggerům, procedurám, atd.
Stejně tak vím, že mnoho lidí neovládá ani to SQL, ani základy databázové teorie. Dokonce velké mezery v tom mají i školitelé MySQL propagovaní mimo jiné přes root/zdroják. A pokud slepý vede slepého …
3)Není pravda že procedury a přenesení na SQL vše zrychlí. Někdy zrychlí, někdy zpomalí, někdy to zůstane stejné. Záleží na okolnostech počínaje od struktury tabulek a dalších databázových objektů, ukládaných dat, konkrétních operací, stejně jako zátěži databáze, dalších paralelních operacích na ní vykonávané, nastavení režimu databázového stroje a mnoha dalších věcech.
4) Výkonový limit frameworků není dán výkonovým limitem databáze. Mezi frameworkem a datbází mohou být další vrstvy a framework může používat mnoho strategií na zvýšení výkonu.
5) Stojí za to naučit se SQL, to podepisuji.
Potřeba přejít na jinou DB je naprosto reálná. Co když původně malý systém 10x – 100x vyroste a původní DB přestane postačovat?
Myslíte, že si pomůžete, když přejdete na „vyšší“ databázi? Aplikace napsaná pro MySQL může být na Oracle klidně pomalejší – pokud chcete využít funkce jiné databáze, tak to obvykle znamená ještě docela dost práce – jednoduchá migrace vám spíš nepomůže. Navíc, když nějaký systém 10x-100x vyroste, tak je obyčejně tak zabastlený, že většinou stačí „uklidit“ – zopakovat optimalizaci, případně udělat databázovou optimalizaci, pokud nikdy nebyla realizovaná – a systém může docela dobře dál běžet i na původních databázích.
Nezbytnou migraci jsem zatím viděl párkrát – a to úprk z 602 SQL serveru a Accessu – což tam už je to pochopitelné – nicméně takovou změnu aplikace provedete 1x za 10 let – 1x za průměrnou životnost aplikace – a podle mé zkušenosti se tato změna provede nikoliv tím, že se použije ORM – ale spíše, že se aplikace napíše dobře modulárně.
Hodně ještě záleží na typu aplikací – u generických aplikací, kde se dobře kešuje a kde je minimum datově náročných operací typu mediawiki, drupal, atd nemá cenu řešit výkon na db úrovni za cenu navázání na jednu db – má smysl se soustředit na správu a využití cache. U ostatních typů aplikací – evidenční nebo procesní systémy je tomu přesně naopak – snáze se přemigruje jednoduše a čistě napsaná aplikace napsaná pro jednu db než aplikace, která se snaží být univerzální – a z toho důvodu může být zbytečně složitá.