Názory k článku Přehled a vývoj PHP frameworků
-
Jiří Knesl (neregistrovaný)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. :) -
anonymníO budoucnosti PHP autor nenapsal ani slovo, jak necekane...
Unicode v PHP zpusobe az o 300% nizsi vykon funkci pro praci s retezci, proto jsem pevne presvedcen o tom, ze stejne vetsina lidi ponecha jeho defaultni rezim, ktery v PHP 6 je DISABLED. Na unicode nikdo neceka, mame totiz mbstring coz je extension pro praci s Multibyte stringy. Co se tyce PHP6 - je to naprosty propadak, namespaces jsou implementovany nejhure ze vsech jazyku, stare nedostatky jako nekonzistence parametru mezi string funkcemi a jine koncepcni vady zustavaji ze starych verzi + se pridavaji koncepcni vady nove. Predpokladam nastup Ruby nebo Java za par let, az kazdy zjisti jaky shit PHP 6 je. -
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ží. -
Václav Stoupa (neregistrovaný)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 ;-) -
mm (neregistrovaný)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 -
Mirek Soukup (neregistrovaný)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í. -
Zdenek (neregistrovaný)Tisice programatoru s RoR asi taky brzy narazi ;-)
http://latrine.dgx.cz/ruby-on-rails-dekuji-nechci -
Rejpal (neregistrovaný)
"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"
Možná není "vyšší", ale spíš "širší", totiž úplnější. Každý seriózně použitelný reflexivní systém nějak "zapouzdření" porušuje, a plně objektový programovací systém tedy již z definice nemůže nikdy poskytnout úplné "zapouzdření" všeho, protože jinak by nemohl měnit sám sebe (přidat metodu do systému by musela nějaká "vyšší moc", ale to popírá požadavek, že systém tvoří pouze objekty, co si navzájem předávají zprávy).
K našemu velkému štěstí "zapouzdření" není (na rozdíl od skrývání informace, extrémně pozdní vazby a předávání zpráv) podmínkou pro objektové programování. Máte mozek vymytý příliš velkým množstvím Kávy a Cé plusrovnáse jedna, které ve světě programovacích paradigmat mají vlastní píseček, jenž bych označil výrazem "jazyky s omezenou podporou objektového návrhu", určitě ne výrazem "objektové jazyky". Doporučuji terapii studiem díla Alana Kaye na Večerní škole Smalltalku.
-
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. -
Rejpal (neregistrovaný)Já jsem si je přečetl. A můj závěr je, že kdyby se tenhle vpravdě směšný argument vzal opravdu vážně, znamenalo by to, že Lisp a Smalltalk jsou k čemukoliv složitějšímu naprosto nepoužitelné jazyky, protože dovolují přesně totéž (pokud jste takováhle třasořitka, určitě nechcete vidět kanonický přenositelný commonlispový tracer, který atomicky nahradí funkci za její trasující wrapper a pak po skončení trasování zase zpátky přiřadí původní funkci). Jenže v nich jsou psané i průmyslové systémy se statisíci řádek. To znamená, že pan Grudl má někde díru v logice.
Osobně bych Smalltalk, Lisp a Ruby přirovnal ke svobodné společnosti. 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? Vždyť žít v tak nebezpečné společnosti musí být strašlivé riziko! Radši se Ruby vyhněte ještě větším obloukem... -
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. -
mm (neregistrovaný)Hahaha, dgx zjevně nemá o objektovém programování moc velké vzdělání :-) To co on vyčítá jako zápor Ruby je ve skutečnosti klad a ukazuje na to, že Ruby je skutečně objektový jazyk (narozdíl od rádoby-objektového PHP). Také je Ruby inspirováno Smalltalkem, který má nejdokonalejší implementaci objektového programování vůbec (no možná Self je na tom lépe, ale ten se nerozšířil). Btw. tohle říkám jako člověk, který Ruby moc nemusí, já radši Python :-)
-
Jakub Kulhan (neregistrovaný)
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! :)
-
mm (neregistrovaný)Tady nejde o žádnou hádku ve stylu "můj jazyk je objektovější než tvůj", tady jde o to, že pan David Grudl (dgx) tvrdí naprostý nesmysl (a sice že to co je možné v Ruby jde proti zásadám OOP - to v žádném případě není pravda, ba právě naopak, pan Grudl tedy lže). 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.
Zkrátka pan Grudl má silně omezený a zkreslený pohled získaný z jazyků, které mají jen omezený objektově orientovaný model (Java, C++, PHP, ...). Prostě kecá o něčem, čemu nerozumí a plácá díky tomu nesmysly. Nejdřív by si měl něco přečíst třeba právě o Smalltalku, než takovou blbost napíše. -
Jakub Kulhan (neregistrovaný)
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?
-
Václav Stoupa (neregistrovaný)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. -
Michaelson (neregistrovaný)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...
-
Kingsize Dick (neregistrovaný)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.
-
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í. -
Messa (neregistrovaný)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. -
danaketh (neregistrovaný)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... -
Václav Stoupa (neregistrovaný)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. -
danaketh (neregistrovaný)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 :) -
Messa (neregistrovaný)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. -
paja (neregistrovaný)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%. -
danaketh (neregistrovaný)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). -
papouch (neregistrovaný)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 -
anonymníZdravim, prave delam na diplomove praci ktera se zabyva srovnanim PHP frameworku. Probiha testovani 10ti frameworku, ktere nevypisuje jen "hello world", ale snazi se dat mu zabrat (vypisy clenu, uzivatelu prislusneho clena a editace uzivatele).
V rychlosti si nejlepe vedou frameworky Qcodo, Code Igniter, Kohana, Jelix. Kousek za nima je prado nasledovane CakePHP. Fuse, Akelos a Zend maji prumerne casy nad sekundu. Vyrazne se to zlepsuje se zapnutim eacceleratoru, kde se i zend dostane na cca 70ms.
Co se tyka pametove narocnosti, tak nejmin pameti vyuziva opet Kohana, code igniter a jelix (neco kolem 1,3MB). Zend, akelos, prado naopak nejvice (5,5 - 6,6 MB).
Takze pokud nehledate komfort a poradnou vybavu, tak doporucuji Kohanu, code igniter, popripade Jelix (jedna chybicka ze je francouzsky :/ ). Framework s nejlepsim pomerem vykon/vybava je asi CakePHP. -
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 -
lopuch (neregistrovaný)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. -
danaketh (neregistrovaný)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 :) -
Jiří Knesl (neregistrovaný)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. -
Jiří Knesl (neregistrovaný)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.) -
shamot (neregistrovaný)Momentalne s timom vyvijame pomerne velke mnozstvo web aplikacii na vlastnom frameworku zalozenom na PHP. Objektove moznosti PHP su azda jeho najvacsim nedostatkom. Aplikacie prevadzkujeme na vlastnych serveroch a mozme si teda nasadit aj Python aj Perl, zaujimalo by ma teda aky mate nazor na jazyk v ktorom by sa najlepsie (rychlost, spolahlivost a moznosti) vyvijali web aplikacie.
-
Jiří Knesl (neregistrovaný)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. -
mm (neregistrovaný)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).
-
Jiří Knesl (neregistrovaný)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. -
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...
-
ims (neregistrovaný)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. -
Václav Stoupa (neregistrovaný)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
-
Mastodont (neregistrovaný)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 -
mm (neregistrovaný)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. -
Jarda Ponc (neregistrovaný)Kdo Davida neznáte, pusťte si jeho přednášku http://www.avc-cvut.cz/avc.php?id=5258
Tam zjistíte, že nejen že není "Pan programátor", ale dokonce ani "programátor". Spíš jen takový šášula. Svůj výstup vylepšuje zábavnou výslovností některých anglických termínů a celkový dojem je opravdu zlý :) -
David Grudl (neregistrovaný)Č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ď?) -
Radek Tondra (neregistrovaný)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! -
David Grudl (neregistrovaný)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. -
mka (neregistrovaný)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) -
paja (neregistrovaný)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
