Názory k článku
Přehled a vývoj PHP frameworků

Ocenil bych, kdyby autor uvedl taky obšírnější odpovědi na 2 první otázky v úvodu článku. Tedy co to jsou php frameworky a k čemu slouží. Z článku jsem pochopil že to jsou knihovny, což sice říká vše, ale neříká to taky nic.

Dobrý den,

PHP framework můžete vnímat jako ucelenou sadu knihoven, které pokrývají určitou skupinu aplikací, které můžete v daném frameworku vytvářet. Velice jednoduše řečeno, framework je skupina knihoven a kód, který je propojuje.

Výhodou frameworku oproti tomu, kdy si programátor jen stáhne knihovny z internetu, je jednotná struktura příkazů, harmonický vývoj všech komponent tak, aby do sebe stále zapadaly (u neprovázaných knihoven na kompatibilitu programátoři zpravidla kašlou).

Další výhodou bezesporu je, že lidé přicházející do diskuzí a píšící autorům, že ten a ten framework se pro danou činnost nehodí, autoři mohou zárověň měnit celou řadu knihoven naráz, takže i ten vývoj je pak účelnější a programuje se jen to, co je nutné.

Mě se osvědčil na weby, kde hodně pracuji s různými seznamy a daty CakePHP, na galerie, blogy, rychlé navržení webu Code Igniter, na intranety se jeví jako dobrá volba QCodo.

Nehledě na to, že řadu frameworků vyvíjejí velice kvalitní programátoři (třeba i placení za to, že budou přímo vyvíjet framework), takže vznikají propracované řešení používající OOP v PHP 5 na vysoké úrovni, s použitím návrhových vzorů. Takový framework může i méně zkušeného programátora vést a nutit ho, aby psal čitelnější a udržovatelnější kód. Samozřejmě toto platí jen omezenou měrou, protože kdo píše jako prase, bude jako prase psát ve všem. :)

Velmi hezky napsáno :-)
Ale jo... pravdu díš... já již zjistil.

Nevím, jak u php frameworků, ale třeba rails frameworku pro ruby se na netu válí spousta pěkných instruktážních videí.

Viz třeba http://media.rubyonrails.org/video/rails_take2_with_sound.mov - pokud trochu zvládáte angličtinu, tak opravdu doporučuju. Ze shlédnutí toho videa si můžete udělat představu, k čemu takový framework slouží.

Protože je to můj první článek pro Root, tak jsem zapomněl pro něj napsat perex. Ten psala redakce a není tak úplně přesný se zaměřením článku. Článek jsem nechtěl koncipovat jako vysvětlení toho, co je to framework a jak se používá, ale spíš jako stručný přehled PHP frameworků a zhodnocení pozice PHP vůči dalším dynamickým jazykům na webu. Zároveň uvést názor, kam by se mělo v budocnu ubírat, aby své pozice neztratilo.

Za redakci se omlouvám a děkuju Jirkovi Kneslovi za dodatečné vysvětlení toho, co je to framework v komentáři.

Pred nekolika tydny jsem udelal krucek zpatky k php, hledal jsem neco na rychlej vyvoj a volba padla na code igniter ( http://codeigniter.com ), neni to spatna vec.
Jinak co se tyka tady uvedenych framevorku...treba takovymu cakePHP ani poradne nefunguji stranky, coz rozhodne neni dobra vizitka ;-)

Code Igniter byl dobrý MVC framework, ale dosti jednoduchý (někdo to může brát jako výhodu, jiný zas jako nevýhodu - neposkytuje toho tolik co CakePHP, takový komfort). Nicméně je vyvíjen komerční firmou a ta na vývoj relativně kašle (tedy né přímo kašle, ale prioritou je u ní její komerční CMS, až pak Code Igniter). Proto vznikl komunitní fork Kohaha, který je čistší, využívá plně výhod PHP 5 (je tedy oproti Code Igniteru PHP5-only), řeší věci které v Code Igniteru nebyly dobře dořešené a je velmi aktivně vyvíjen. Jinak koncepčně je s Code Igniterem prakticky shodný, portovat moduly z Code Igniteru na Kohanu není problém.

to vypada velice zajimave, diky za tip, kouknu! prave spolecnost vyvijejici codeigniter ten komercne (opravdu komercne? musim kouknout...) vyvijeny CMS prepsala, takze je postaven na CI v tuto chvili...

jednoduchost (a prehlednost) CI mi plne vyhovuje, ovsem je to opravdu silne subjektivni, nemam s jinymi PHP frameworky zkusenost

Vdaka za rady.
Urcite lepsie to pojde s frameworkom ako ciste PHP :)

Příliš nechápu to stálé vzývání Nette. Přitom z toho "frameworku" zatím vypadlo jen pár drobečků, ale přesto všichni Češi už vědí, že to je světový produkt bez konkurence. A čekají.

Doporučuji přestat čekat a opustit potápějící se loď PHP. Už je nejvyšší čas. Z PHP se stal jazyk který nesměřuje nikam a má základní koncepční nedostatky. Příval lam do vysokých pater vývoje to jen zhoršuje. Jakmile člověk začne trochu víc drtit OOP, naráží na jeden bug za druhým. Zdálo se, že se to zlepší s příchodem Zend frameworku, ale oba vývojové týmy spolu nekomunikují a musí vznikat obezličky, které v dalších verzích přestávají fungovat, anebo mění své chování. PHP 6 je jen dovršení katastrofy!

Uvědomte si, že zatímco vy čekáte na Nette, tisíce akčních programátorů spouštějí své první projekty v RoR nebo Djangu! Až se začnete učit Nette, oni budou produktivně chrlit pokročilé projekty. Až si s příchodem PHP 6 uvědomíte svou chybu, bude pozdě na nějaké dohánění.

Tisice programatoru s RoR asi taky brzy narazi ;-)

http://latrine.dgx.cz/ruby-on-rails-dekuji-nechci

Co takhle si namitky pana Grudla precist? :-) Nejsem odbornik na Ruby a nepropaguju navrat k PHP, ale to, co je v tom clanku napsao, mi staci k tomu, abych se Ruby opravdu velkym obloukem vyhnul.

Klad? Jako ze muzete prerazit metodu existujici tridy misto abyste musel tu tridu rozsirit? Pokud naprosto evidentni poruseni zasady zapouzdreni povazujete za vyssi objektovost, tak prosim... Udrzet pri neohlidanich takovych veci nejaky velky projekt po kupe musi byt opravdu zabava.

Jazyky, ktere vy nazyvate "jazyky s omezenou podporou objektového návrhu" jsou jazyky, jejichz tvurci si dali vedle sebe na vahy pozitiva a negativa, ktere prinasi monkeypatching (mimochodem, nedokazu si predstavit vystiznejsi termin) a rozhodli se ho nepovolit. A to proto, ze problemu, ktere bez toho nelze vyresit (jsou-li nejake) je minimum a jejich reseni bez monkeypatchingu neni nijak drasticke. A naopak problemy, ktere tim lze privodit, muzou byt dost bolestive.

Jistě, můžete kdykoli vzít sekeru a jít sousedovi useknout hlavu, a nikdo Vám v tom nezabrání. Proč tedy nejsou sekery zakázané a mezi lidmi nejsou mříže, aby si neublížili?

Protoze sekyra je veskrze prakticky nastroj potrebny a pouzivany k mnoha ruznym cinnostem. Monkeypatching, na druhe strane, je princip, bez ktereho se lze bez problemu obejit.

Tomu říkám hádka:

"Můj jazyk je objektovější než tvůj."

"Ne, můj je více objektový. Můj totiž umí tohle, tohle, tohle a tohle. A ten tvůj neumím tamto a tohleto."

"Ale to takhle vůbec nemůžeš říkat. Na tom tvém je zase špatné, že tohle, tohle a tohle. A to ten můj to dělá mnohem líp."

...

Nezdá se vám to trochu střelené? :)

Nezlobte se na mě, ale tohleto hledání "svatého grálu" jazyků s podporou OOP je úplně stejné jako hledání toho nejlepšího jazyka vůbec. Nikdo není a nikdo nemůže být vítězem. Každý jazyk má svá pro a proti, každý byl vyvinut za jiným účelem, každý si prošel jiným vývojem.

Je dobré upozornit na chyby. Říct, že tohle se mi na tom nelíbí. Každý má svou hlavu, a tudíž co člověk to názor. A tudíž každý může s názorem jiného souhlasit, či nesouhlasit, může jiný názor podpořit, nebo zavrhnout. A jelikož jsme každý jiný, tak si každý jazyk (názor, cokoli...) najde své zastánce i odpůrce. Ale proto je tu těch jazyků (názorů, čehokoli...) tolik, ne? Pokud nejde o exaktní obor, kdo může rozhodnout, co je správné a co špatné? Kdo?

Tyto žabo-myší války o hledání té jedině správné "pravdy", mě vždy pobaví. Jen tak dál hoši :)

P.S. Reagoval jsem na tebe, ale platí to všeobecně pro všechny diskutující.

P.P.S. Tak do mě a nešetřte mě! Já si to zasloužím! :)

Taky jsem nepsal nic o tom, je-li dgxův názor správný či špatný. Podle mě se tady spíše opravdu jedná o válku, který že ten jazyk je opravdu nejobjektovější na světě. Což dokazuješ i ty.

"Všechny jazyky s kompletním objektovým modelem (Smalltalk, Lisp, ...) to umožňují, protože je to k plně objektovému modelu zkrátka a jednoduše potřeba, je to bráno jako kladná vlastnost, nikoliv zápor."

"..., které mají jen omezený objektově orientovaný model (Java, C++, PHP, ...)."

Mimochodem, co že je to ten kompletní (plný) a omezený objektový model? Opravdu by mě zajímalo, jak jsou tyto pojmy podle vás definovány.

A ještě něco, když se tu všichni baví o té zapouzdřenosti. To jsem opravdu žil v blahé nevědomosti, oč vlastně jde? To je opravdu zapouzdřeností míněno, že, jak metodu definuji, již ji nemohu změnit? To opravdu neznamená to, že každý objekt odkrývá jen svůj interface (tím nemyslím to javovské klíčové slovo, ale veřejné metody (funkce, zprávy, čudlíky na černé krabičce, říkejte si tomu, jak chcete) sloužící ke komunikaci s objektem) a nic víc?

Myslím že dgx není jediný, kdo si to myslí. Viz třeba článek a diskuze http://avdi.org/devblog/2008/02/23/why-monkeypatching-is-destroying-ruby/

Myslím ale, že tenhle článek není o tom, abychom se tu hádali o Ruby on Rails.

protože je to k plně objektovému modelu zkrátka a jednoduše potřeba

Problem je vase definice slova "potreba". V praxi to neni potreba vubec, resp. neprinasi to vice pozitiv nez potencialnich negativ. Potreba je to jen proto, aby mysl objektovych ultra-puristu zajasala. A to je pro me trochu malo.

A Vy mate skusenosti z projektov pisanych v Smalltalku alebo Lispe (CLOS heavy), ze si dovolite toto tvrdit? Ak ano, tak mi povedzte na ake konkretne (nie potencionalne) negativa ste narazili. Ak nie, tak sa nad sebou poriadne zamyslite, pretoze kecate o niecom o com nic neviete... akonahle si aspon zbezne nastudujete napr. MOP, tak sa mozeme dalej bavit...

Mě se nejvíc líbí, že tyhle tahanice o objektový jazyk vedou lidé, kteří nedokáží na poprvé bezchybně nakreslit základní schéma deset let starého modelu MVC.

MVC neni stary 10, ale 30 let :-) ...kdyz uz jsme u toho kritizovani znalosti o MVC :-)

Navic "schema MVC" je dost relativni pojem. Jsou samozrejme pojeti, ktera jsou uplne mimo, ale variant rozkresleni vztahu MVC je urcite vice. (mimochodem, ktere schema mate konkretne na mysli?)

Naprosto souhlasim s panem Soukup.

To je jenom aurou dgxe. Ne ze bych ho chtel nejak podcenovat, ale aby jedinec napsal framework alespon castecne pouzitelny a primerene bugovy jako je symfony, cakephp, zend za kterymi stoji desitky lidi (a velke spolecnosti) mi prijde dost jako utopie. Ale chapu, je to cech a na prednaskach je spise pro zabavu.

Ja jsem myslel, ze o tohle se dgx ani nesnazi. Mel jsem pocit, ze Nette ma byt jen jakasi mezivrstva, ktera, z PHP udela trosku rozumny jazyk.

Nesouhlasím s nápadem:
"Další způsob, kterým by PHP mohlo nabídnout něco navíc oproti ostatním jazykům, by bylo zabudování Zend Frameworku přímo do PHP. Jednak by se zvětšila rychlost aplikací postavených na tomto frameworku, a také by byla zaručena 100% dostupnost frameworku bez zvláštní instalace."

Kdyby to šlo dělat takhle, tak by se v Zend Frameworku nemusela vůbec dělat abstrakce databázové vrstvy, protože v PHP je přeci zabudované PDO.
Externí knihovny můžu lehce updatovat třeba každý den, zatímco ty zabudované brzy zatuhnou
a zakrní, protože updatovat samotné PHP v produkčním prostředí už taková selanka není.

Existuje vůbec u nás někdo kdo by nabízel webhosting na pythonu? Prošel jsem stránky nejrůznějších webhosterů a všude je jen PHP (anebo .NET u lepších služeb). Nezkoumal jste to někdo? Nemáte někdo přehled?

V Česku znám tyto:

http://www.klenot.cz
http://g-hosting.cz

Protože PHPkářů je jak much a stačí jim FTP a Apache s mod_php5 (za příplatek dokonce i 1-3 databáze v MySQL!). Zatímco jiné frameworky mají poněkud jiný životní cyklus, kterému by se dotyčný webhosting a jeho personál musel přizpůsobit (zaškolit). Pokud čtenář dělá aspoň do toho PHP pak asi ví, jaký je podíl webhostingů, které se opravdu vyznají v tom co dělají. Tím chci říct, že podpora těchto technologií u webhostingů je prostě opravdu trochu problém a IMHO je to důvod, proč PHP vůbec ještě existuje :-)

Jinak já osobně doporučuji spíš vlastní server (virtuální, dedikovaný či rovnou svůj vlastní) - tam nikoho neomezuješ, nikdo neomezuje tebe (po softwarové stránce) a můžeš si tam spouštět co chceš, mít domén kolik chceš a i další služby jak je libo.

Nesouhlasím s tvrzením, že nemá smysl psát si vlastní framework. Pokud má člověk dost času, tak to rozhodně význam má, jelikož je to krásná možnost, jak dále rozvíjet své znalosti a schopnosti. Nicméně na druhou stranu uznávám, že vyvíjet dnes nový framework za účelem jeho dalšího šíření asi nemá valný význam. Jako studijní projekt je to ale myslím dobrý nápad. Otestujete si tím, zda máte takové znalosti, abyste dokázal něco takového stvořit :)

Jinak postrádám zmínku o Perlu, který se také hojně využívá, především u robustnějších aplikací, kde by použití čistého PHP bylo neefektivní nebo příliš složité. Osobně si zatím stačím s PHP, Perlem a Pythonem. Ruby mi k srdci nepřirostlo ale ještě mám v plánu se mu podívat na zoubek - nezatracovat něco bez podrobnějšího prozkoumání - tím se řídím.

S Javou jsem se nezkamarádil i přes množství pokusů a u .NET mi vadí nutnost si pořídit Windows (naštěstí mám jeden stroj s WinXP k dispozici), jinak se mi současná verze 3.5 docela líbí (je to jedna z mála věcí, které se MS povedly).

To je zase sloh :) Myslím, že pozice PHP rozhodně není neochvějná, byť jej používá poměrně široké spektrum webů. S PHP6 jsem se zatím neseznámil, takže nemohu soudit jestli to bude katastrofa nebo ne, nicméně tohle se prohlašovalo o každé nové verzi a nakonec se žádný úpadek a odliv programátorů nekonal. Bohužel, jednoduchost PHP je jedna z příčin, proč je internet plný mizerných PHP aplikací od začínajících progamátorů. A pak si hledejte něco, co je vážně k užitku...

Na téma "Proč psát nebo nepsat vlastní framework" se chystám na našem blogu brzy napsat článek. Zhruba bych to shrnul tak, že pokud píšete vlastní framework, tak rozhodně neusnadňujete práci dalším kolegům, kteří se ho budou muset naučit. Zpravidla bude bez dokumentace. Ano, jeho vývojem, se naučíte hodně o fungování jazyka.

Lepší je ale podle mě nějaký stávající framework prozkoumat ze zdrojáků do hloubky a když mě napadne lepší řešení tak ho prostě komunitě navrhnout. Nebo samozřejmě stávající framework dále rozšiřovat. To pomůže všem lidem, kteří ten nástroj používají a zpětně také mě.

Statisticky to můžete vzít tak, že tisíce programátorů jsou entity, které ovlivňují entropii nějakého systému a čím více a čím schopněji ho budou ovlivňovat, tím se ten systém bude stávat "bug free" a použitelnější. Proto pokud máte PHP rádi a chcete ho zachovat před ostatními jazyky, není lepší cesty než se snažit všechny dobré nápady, které máte zapojit do již hotových TOP nástrojů a tím je vylepšovat.

Pravda. Bylo to myšleno tak, že psát "pro sebe" není na škodu. Ovšem psát nový framework na produkční weby, na kterých pracuje více lidí je dnes skutečně zbytečné. Já si dokumentaci pečlivě tvořím, protože jsem hlava zapomnětlivá a když se pak na něco podívám třeba po měsíci, tak nevím k čemu jsem to vlastně implementoval. Takže raději komentuji a přidávám odkazy na dokumentaci.

Snažím se, snažím... :) Jen kolikrát není čas nebo člověka napadne něco, co už někdo dělá :) Takže se zapojuji spíš do bug reportu a případného navrhování oprav pro dané bugy. Invence mi moc nejde :)

Když se ten framework napíše dobře, s vhodnou mírou a vkusem, pak získáte pro svou práci ten nejlepší nástroj. Pokud pracujete v týmu, pak asi nejlepší bude vyvíjet ten framework v tom týmu (jedním slovem: organizovaně). Prostě to nesmí být obluda, ale "jen" věc, která poskytuje těch pár vlastností, které každý webdeveloper od frameworku očekává a tak nějak podvědomně ví, jak by měly fungovat (pokud je to dostatečně zkušený webdeveloper). Bohužel framework nejde začít psát hned po dočtení "Programování pro zelenáče", chce to nějaké zkušenosti s problémy, které je potřeba řešit a nejlépe i s již existujícími frameworky.

Smysl open-source vidím v tom, že si za jistých podmínek můžu vzít co chci a dělat s tím téměř cokoliv. Ne v tom začít něco někomu vnucovat, proti tomuhle jsou OS projekty dokonce i dost imunní :-) Navrhovat komunitě je zajímavý nápad, schválně by mě zajímalo, kolikrát se vám už podařilo tu komunitu naklonit vaším směrem. Let's flame: bug free a použitelnost není o tom, že na tom dělá tisíc programátorů, ale o tom, že se to dělá pořádně - což se v praxi většinou vylučuje.

Z ekonomickeho hlediska je casto psani frameworku nadbytecne. Psani frameworku je prace, kterou vam nikdo nezaplati. Konkurence, ktera si stahne hotove reseni, si usetri tisice hodin prace, cimz ziska konkurencni vyhodu.

Trosku me zarazi, ze podle autora Perl (a JavaScript) na webu neexistuje, nebo je zcela okrajovy, ci alespon pouzivany mnohem mene, nez napr. Ruby... Jak jste na neco takoveho prisel?

Tady je napr. urcite srovnani prac. nabidek pro dynam. jazyky v USA: http://www.presicient.com/langjobs/usajobs.html
Dominuji JavaScript a Perl, hluboko za nimi je PHP, Python je skoro irelevantni a Ruby vyslovena kuriozita.
Tady je jiny zdroj: http://www.indeed.com/jobtrends?q=perl%2Cpython%2Cphp%2Cruby&l=

U Perlu nemusi jit vzdy o web, ale pochybuji, ze o nej nejde aspon z 50%.

JavaScript se ale snad nepoužívá přímo ke generování stránky jako takové. Alespoň jsem to nikde neviděl. Slouží jen jako doplněk k omezené manipulaci s již vygenerovanou stránkou. Na spuštění JS IMHO musíte nejprve mít nějakou hotovou HTML stránku, do které se vloží, kdežto ostatní jazyky jsou to HTML schopné generovat samostatně.

Jistou výjimkou by se dal nazvat AJAX ale ten vlastně jen umožňuje v už načtené stránce pracovat s externími scripty jiných jazyků a tak její zásadně obsah měnit bez nutnosti reloadu celé stránky. Pořád to ale není jazyk, který by byl vhodný nebo možná spíš schopný generovat celou stránku bez cizí pomoci.

Kromě toho jsou oba (JS i AJAX) závislí na browseru a každý browser s nimi pracuje jinak, zatímco Perl, Python, PHP, ASP... mají interpreter, který ke kódu přistupuje vždy stejně (podle verze).

server side javascript existuje (treba v iPlanet serveru nebo v pluginu do IIS pro Extensis Portfolio), ale masove se nepouziva

jinak javascript je skriptovaci jazyka jako kazdy jiny, takze na spusteni samostatneho skriptu neni html stranka ani webserver nutne potreba, lze z prikazove radky - pak neni k dispozici DOM (document.neco atp), ale zase se da pracovat treba s filesystemem

Az na to ze JavaScript je o necem trochu jinem, nez ty ostatni jazyky :-)

Pošlete mi, prosím, na sebe kontakt. Tohle téma by nás určitě zajímalo, ať už na nějakém setkání, nebo formou článku na našem blogu.

Díky
kontakt stv(na)seznam.cz

Hezky den,

i nas by ty benchmarky zajimaly. Muzete ten kontakt poslat i me na adresu v tvaru krestni@prijmeni.cz ?
Dalsi kontakt viz http://jyxo.cz/d/cont

diky,
Michal Illich, Jyxo

Zduraznil bych, ze jednim ze zakladnich veci, jak vybirat framework je dokumentace, tutorialy a use case. Neco jako Nette/dibi je sice pekna vec, ale kdyz se podivate na dokumentaci Zend Frameworku, Symfony, Cake tak je to jasne. Prace pujde od ruky nekolikanasobne rycheji nez kdyz se budete hrabat v nette a zjistovat, co a jak.
To same plati o podpore pri reseni bugu apod. Takze nette muze zvolit na komercni projekt jen uplny blazen, nebo zamestnavatel/zakaznik pana Grudla.

Vyzkoušel jsem dibi a připadá mi hodně intuitivní a jednoduchá. K jejímu nasazení mi stačilo jen přečtení jednoho článku na webu pana Grudla. A žádný bug jsem nezaznamenal. Nette jsem nezkoušel, protože cizí frameworky obecně nepoužívám. Když pak dojde k chybě, tak je potřeba se dopátrávat kde k ní došlo, za jakého důvodu a řešení nakonec třeba poptávat na diskusi daného frameworku, což zabere dost času. Hrabat se v cizím kódu, kde si přesně nejsem jist co k čemu slouží si netroufám. A dokumentace mlčí...

Kromě toho například Zend je příklad obrovského frameworku, který může být pro někoho odstrašující, protože prokousávat se spoustou dokumentace abych si vybral jen to co skutečně potřebuji nemusí být žádoucí. Naopak Symfony se mi líbí, protože vypadá poměrně jednoduše :)

Dokázal by někdo zhodnotit jak jsou na tom jednotlivé frameworky, co se týká podpory tvorbu vícejazyčných webů?

Jednoduche.

Vsechny frameworky maji vicemene to same. Tedy prekladovy soubor a metodu pro preklad. V pripade Akelosu je v sintags i polozka sablony pro preklad. Akelos ma oproti ostatnim i podporu vicejazycnosti v URL.

Vsechny frameworky pouzivaji pole, csv, gettext, nebo neco podobneho. Zend ma nejvic adapteru. Akelos ma vychytavku, ze kdyz dany klic neexistuje vytvori ho sam a opatri komentarem data vytvoreni v prekladovem souboru.

Takze pokud staci obyc.pole, nejlepsi Akelos.
Pokud potrebujete volit z hodne adapteru, pak volte Zend.

Ostatni frameworky to maji vicemene jednoduse pres pole, nebo obdobu.

Poznamka na okraj: Zend_Translate jde samozrejme ze ZF vyjmout a pouzit v cemkoliv jinem. Napriklad pro CakePHP a Code Igniter jsou na webu stoprocentne snadno vygooglitelne tutorialy, kterymi komponenty ze ZF zaintegrujete dovnitr.

LOL, rails v php:-D Díky za tip. Vypadá to, že jsem skončil s hledáním vhodného php frameworku;)

Nejvyrazneji Rails v php pripomina Akelos (pominu-li PHP on Trax, ktery ma byt primou kopii, ale ktery mi prijde ponekud mrtvy), druhy v poradi v blizkosti je CakePHP.

Nevyhody Akelosu jsou, ze je porad hodne devel a je tam pouzita ohromna tuna knihoven odjinud. (Coz nemusi byt hned chyba - treba symfony pouziva jako ORM Propel a v budoucnu by mel pouzivat phpDoctrine, coz povazuju za velice dobry krok.)

Pokud jedete na PHP a nejste zatim "poznamenani" zadnou dalsi technologii, pak bych vam doporucil nevypoustet ze seznamu technologii Javu.

Obrnte se proti radobyprofesionalum tvrdicim, jak se v jave spatne vyviji, ze je to same XML a nebo ze je to pomale a podivejte se treba na framework Stripes.

Java je skvela ale myslim ze na aplikacie ktore vacsinou robime by bola trochu zbytocna, IMHO kanonom na zajace.

Nemam dobru predstavu o tom ake aplikacie vytvarate, ale kanon pouzite nemusite. Java poskytuje volnost vo vybere pouzitia technologii.
Staci vam teda jednoduchy server napr tomcat+databaza+framework.

Taky jsem si to dlouho myslel :-) Ale fakt je, ze Java se perfektne hodi i na mensi a stredni veci. Nemusit vzdycky pouzit nejaky megaframeowrk...

Doporucil bych zustat u PHP. V pomeru cena/vykon za praci programatora dostanete jako viteze PHP. Programator v PHP platove konci tam, kde programator v Jave zacina. Pritom stejne dobry programator toho v PHP udela vic.

Vyvoj www stranek je dnes jednoznacne nejrychlejsi v PHP, Pythonu a Ruby. V Jave to jde pomaleji, ale zas se hodi na rozsahlejsi aplikace, kde je nutna velka skalovatelnost. Coz samozrejme neznamena, ze PHP nejde skalovat - podivejte na takovou wikipedii a ta je na PHP. Nebo treba Google a Seznam mimo C++ pouzivaji hodne Python.

Pokud chcete kouknout i na Javu, krome Stripes bych doporucil kouknout na Wicket.

Mam v hlave cerva ci by prave Python nebol pre nas vhodnejsi. Osobne mam python velmi rad, ale neviem ako je to s rychlostou Python vs. Apache a podobne, proste ci to slape tak bezproblemovo ako PHP.

Python šlape podstatně rychleji než PHP :-) Na webu najdete srovnání výkonu webových aplikací ve frameworku Ruby on Rails, Django (Python) a Symfony (PHP). Zcela suveréně vítězí Django (Python), s velkým odstupem druhý je Ruby on Rails a naprosto nejhůře s obrovitánským odstupem dopadlo PHP (framework Symfony).

Ono to ale neni tak uplne jazyky samotnymi. Svou roli hraje to, ze pri zpracovani pozadavku se cela aplikace sklada a pak zase rozebira.

Python je cca 5* rychlejsi (samozrejme jak na co, ale v kazdem pripade budou aplikace rychlejsi v Pythonu.

Ale rychlost vyvoje je zhruba ekvivalentni, jen ten zdrojak je uhlazenejsi.

V kazdem pripade firma za pythoniho programatora zaplati vic, nez za phpckoveho a na vnejsku se rozdil skoro nepozna, takze se ji to nevyplati. Opet jsou vyjimky - hlavne tam, kde je nutne vymacknout vic z vykonu serveru.

Je zajimave, ze taky nezminujete Perl -- asi nejpouzivanejsi "skriptovaci" jazyk dneska. Nemyslim to jako nejaky flame, vazne me to zajima, proc je pro vas mimo?

Na Perl jsem trochu pozapomněl. Možná proto, že se s ním ve své praxi nesetkávám vůbec a na internetu v článcích o jazycích pro web také příliš ne.

Rozhodně doporučuji Python, konkrétně webový MVC framework Django. To je IMHO to nejlepší, v čem se dají v dnešní době webové aplikace vyvíjet.

Dakujem, presvedcili ste ma, postudujem a otestujem a eventualne nasadim.

Django zdaleka za nejlepsi nepovazuju. Jeho jadro je celkem dobre, ale vse, co je "pod" controllerem, je hruza... Snazili se skoro celou business vrstvu vmacknout do jedine a podle toho to vypada. Domenove objekty nejsou jen domenove objekty (navic je primo v nich informace o SQL tabulkach, coz povazuju taky za hodne blbe design decission), ale taky zaroven servisni tridy a v tech "nejlepsich" pripadech zaoven DAO. Navic tohle zhustovani podporuji i v oficialni dokumentaci...

Mně například tento přístup Djanga vyhovuje, považuji to naopak za dobrou "design decission".

+1
Doporucujem ist radsej do politiky..... Je to jednoduche a výnosné...

OT a navic zakladani flejmu, nic vic, nic mene.

Napriklad Struts se nekolik lidi pokousi prepsat do PHP, existuje nekolik implementaci v PHP.

Urcite je prepsanych i vice frameworku z Javy, me prisly docela ukecane, ale pokud to nekoho zajima vic, radil bych "zagooglit" a ono urcite neco vypadne.

Pokud trochu znate komunitu kolem Stripes ci Stripes samotny, tak vas asi neprekvapi, co reknu: Struts je paskvil. Jak v1, tak v2 :)

Prave Stripesy tu ukecanost srazi na velice nizkou uroven a pritom zachovavaji silu a flexibilitu, o ktere se PHP ci Pythonskym frameworkum muze jen zdat.

Na adrese http://ims.rockretail.com najdete mnozstvo cennych rad o PHP frameworku CakePHP.

Smekam kloubouk pred autorem! Byt programatorem v PHP a vedet, se chysta mod_rails je opravdu obdivuhodne, vzhledem k tomu, ze tato informace probehla webem teprve velmi nedavno.

Co se tyce hostingu Rails v CR, jsou dva, v zahranici je to ale mnohem lepsi. Skoro bych rekl samozrejmosti. Sam mam aplikace v Rails, hostuji na Site5.com a Rails bezi v pohode. Railsova klasika je mongrel resp. mongrelovy cluster hozenej za Apache, jinak se to de facto ani nedela.

BTW v Ruby jsou i jine frameworky nez Rails, osobne se mi hrozne libi napriklad Merb. To jen tak pro doplneni, protoze v tomto kontextu se mluvi temer vyhradne o Rails.

Ackoliv v PHP nepisu a nikdy psat nebudu, opravdu vrcholne me zajima Nette. Dgx je totiz opravdu *pan* programator s genialnimi napady. Viz treba Texy.

Koho Ruby zajímá více, tak právě dnes a zítra probíhá evropská konference o Ruby v Praze. Viz http://www.euruko2008.org/pages/2-program

Texy a geniální nápad? Máte opravdu na mysli ten neuvěřitelný guláš, kde jsou smíchány asi čtyři značkovací jazyky, kde si člověk musí pamatovat, na jakém místě jsou povoleny závorky kulaté, hranaté nebo složené, kde se něco řeší značkou a něco jiného zas odsazením?? ROTFL.

http://texy.info/cs/syntax

Přesně tak.

...ten neuvěřitelný guláš, kde jsou smíchány asi čtyři značkovací jazyky, kde si člověk musí pamatovat...
A proto je Texy! tak oblíbená, proč zapisovat jednoduše, když to de složitě přece.

Co má být na Texy! geniálního? Vždyť je to jen prachobyčejný "Yet Another Lightweight Markup Language", jakých už tu před ním byly desítky (jen namátkou třeba Markdown, Textile, reStructuredText, různé wiki syntaxe, ...). Ničím extra nevyniká, není nijak výjimečný a rozhodně na něm není nic geniálního. Je jen dalším z dlouhé řady.

Btw. pan David Grudl (dgx) není žádný "Pan Programátor". To z něj jen dělají typický čecháčci svým provinčním nacionalismem. Není to špatný programátor (i když občas také uklouzne, viz třeba jeho naprosto zcestný názor na Ruby, který ukázal, že nerozumí objektovému programování), ale takových jako on jsou tisíce.

Co umíte vy? kecat (to umí každý...), pak můžete někoho kritizovat.

A co teprve kdybyste věděli, jak neskutečný balík peněz jsem na Texy vydělal! Hehehe blbečci :-)))

Člověk, který mi tu nadává a vyjadřuje své opovržení, se začne vysmívat tomu, že mi někdo (tedy ty) nadává a vyjadřuje opovržení :-))

Ale na to ti málokdo skočí. Je totiž vidět, že bedlivě sleduješ všechno co dělám, že čteš každý můj článek. A co teprve kdybych tu zveřejnil emaily (což nedělám), ve kterých jsi mě úpěnlivě prosil, abych ti zaslal kód některých knihoven, nebo poradil s programováním. Vážně nemám čas, abych každému pomáhal, což lidé obvykle chápu, bohužel někteří ne a pak si léčí zhrzené ego na diskusích. Mirku, neblbni.

(teď asi budeš vykládát, že jsi mi nikdy ani nepsal, viď?)

Co chces od cloveka ktereho kazdy druhy twitt se tyka alkoholu. Tomu se o nem snad i zda

Nerozumi OOP? LOL, misto kecani si prectete zdrojaky Texy. Pravda, s Davidovym nazorem na Ruby nesouhlasim, ale beru to jako nazor profesionala, ne vykrik nakeho blbecka. A Texy je mnohem sofistikovanejsi nez si myslite!

Tak do těch zdrojáků nahlédneme spolu?

Texy není objektově napsané. Dokonce to není ani klasický parser (stavový automat), který by na základě syntaktické a sémantické analýzy sestavoval objektový strom kódu, který by poté vyhodnotil. Je to jen taková hromada regulárních výrazů, která splácává jeden velký string, nacpaná do "objektového" pouzdra.

Já osobně vidím v kódu základní nepochopení principů OOP, z čehož logicky i pramení odmítnutí Ruby z pozice zatvrzelého procedurálního programátora.

Do těch zdrojáků se může podívat každý a musí dojít ke stejným závěrům!

Je zajímavé, že pouze někdo dokáže inteligentně nesouhlasit (např. Jakub Šťastný), zatímco většina bere nesouhlas s nějakým názorem jako záminku k osobním výpadům a plivání na vše, co dotyčný vytvořil. Už jsem si na to zvykl a nemám ani potřebu na podobné výkřiky reagovat.

Ale Radku, ty jsi mě vážně pobavil :-) Hned první věta: "Texy není objektově napsané." To mě navnadilo číst dál! A nezklamal jsi. Následuje triumfální zjištění "Dokonce to není ani stavový automat". Jako by snad v předchozím textu (nebo kdekoliv jinde) někdo tvrdil, že Texy JE stavový automat. Nikoliv - vždy jsem říkal, že "Texy je sexy," nikoliv "Texy je sexy stavový automat." Navíc ani jako slogan by to nebylo moc úderné.

Přít se s tebou nebudu (to by bylo jako účast na paralympiádě), ale schválně se zkus zamyslet nad myšlenkou, proč Texy není a nemůže být stavový automat. Můžeš se i pokusit napsat ekvivalent Texy jako stavový automat.

Možná by nebylo na škodu si vzpomenout, že regulární výraz nám definuje konečný stavový automat, viz. http://en.wikipedia.org/wiki/Regular_expression
A nevidím rozumný důvod psát celý parser v PHP, když lze pohodlně použít osvědčenou a dobře otestovanou knihovnu, kterou PHP standardně obsahuje. (navíc nalinkovanou z C, takže určitě rychlejší, než interpretovaný PHP kód)

Díky za seznámení s frameworkem ze světa Perlu.

Tak tady je pro doplnění můj oblíbený Jiffty, ať to nevypadá, že Perl má jen Catalyst.

... dokud v phpcku bude moznost delat uplne extremni zverstva a nepriblizi se "normalnimu" programovacimu jazyku, bude to vzdy takovej malej paskvil, kterej se nauci kazdej trouba. za nejvetsi trest pak povazuji takovej kus kodu debugovat - 1000 radku, nedeklarovane promenne s nestalym typem, stdclass - v pulce kodu se v objektu objevi nova vlastnost... a po inicializaci pripojeni s databazi a fetchovani mnoha udaju se to vsecko zahodi, aby se to pri dalsim hitu mohlo udelat znova... X-( tfuj... no, nejsem php guru :D ale za tim co pisu si stojim - dokud clovek nepracuje v phpcku s respektem a v nejakem vzdelanem teamu, bude jenom trpet