Názory k článku Velký test PHP frameworků
-
ne (neregistrovaný)je žádný framework. Už vidím, jak při zrušení podpory nebo vývoje toho kterýho frameworku překopáváte celou mnoho megovou aplikaci zpět do čistýho třídního PHP. Pak to můžete jít leda zabalit a ohlásit bankrot. Navíc to pak asi už ani neumíte, to čistý PHP :)
Podobně je to při programování, když se používá extrémně moc externích komponent, v případě uzavřených příp. velkých (jejichž výskyt v aplikaci se hodně špatně překopává) je to ještě řádově větší risk. -
lol (neregistrovaný)+1
minule som prvy krat robil aplikaciu vo frameworku (code igniter), kedze to bol specialna poziadavka ze to v tom ma byt spravene. Nebolo to zle, ale v konecnom dosledku som citanim dokumentacie a hladanim veci ktore t dokaze zabil viac casu nez by som to programoval ako namieru situ aplikaciu. Pri programovani bez frameworku navyse niekto kto uz pogramoval nezacina od nuly a vzdy vie pouzit vela veci z predchadzajucich projektov do tych buducich. Vlastny kod je pre kazdeho codera najprehladnejsi. -
Za tech par let co pisu mam vytvorenou spoustu funkci, ktere znam a snadno pouziju. Ve sve dobe jsem pouzival 2 frameworky a ta efektivnost mi neprisla o tolik vyssi. Nevyhodou muze byt opravdu to, kdyz do FW potrebuju dostat nejakou funkcionalitu odjinud, z jinych kodu. A miloval jsem, kdyz jsem mel predelavat neco, co bylo napsano v nejakem uplne jinem FW :-) -
Ono dost zalezi, jak kdo pise. To plati pro FW i bez nej. Kdyz mam u kazde funkce okomentovano, co dela, co do ni leze a co vyleza, stejne tak v kodu. Pak se clovek zorientuje i ve FW, ktery az tak nezna. Ale to uz se dostavame nekam jinam.
Ale porad bych rekl, ze vetsi mnozstvi lidi pise bes jakehokoli FW. Ale statistiku jsem nike necetl -
PaD (neregistrovaný)Dostal jsem po nekom na upravu projekt, ktery psal od nuly? Pokud ne, tak doporucuju zkusit nejaky, kde jadro je napsane v dobe PHP3 a nebo jeste drive... (I takove se dnes jeste na webu vyskytuji) Takovy projekt, ktery nahodou zafungoval a kolem zbastleneho jadra se pridavaly dalsi a dalsi funkce... Zlaty framework, kde to je oddelene a clovek i po nejakem case vi, co kde je...
-
Seti (neregistrovaný)On je problém v tom, že to jsou projekty staré třeba i 8, 10 let, na kterých se vystřídala řada lidí, není to práce jednoho člověka. Ovšem! pokud by se pracovalo s FW a dodržoval nějaký coding style, byla by situace určitě přehlednější :) Ale máte pravdu, že po některých lidech číst kód je jako luštit záhadu pyramid :D
-
myneur (neregistrovaný)No nevim, co vás přimělo k zvolení nadpisu "Velký test PHP frameworků", když jsou testovány pouze dva PHP frameworky, přestože jich je megatuna a navíc jenom rychlost na velice jednoduchém příkladě, přestože aspektů jak vybrat správný framework je gigatuna.
Pod nadpisem "Jednoduché porovnání rychlosti dvou PHP frameworků" dejme tomu.
Nadpis by měl odpovídat tomu, o čem je článek a ne se mermomocí snažit nalákat čtenáře, kteří, jako já, přijdou, a zjistí, že se zde nic nového nedozví, tak stejně odejdou, a ještě jsou z toho smutní.. -
PaD (neregistrovaný)A nemělo by to být naznacene na zacatku? Neco jako "Tohle je serial, palnovane frameworky jsou ... popripade tam pridame nejake dalsi, podle ohlasu ctenaru. Takhle nevim, co od toho muzu cekat... a nebo to precist az vyjdou vsechny dily a pokud tam bude framework ktery znam a zjistim, jak moc se lisi pohled autora na dany framework od pohledu meho...
A co kdyz nektere frameworky jsou udelane tak, ze lze lehce pouzit nekolik externich sablonovacich systemu? Takovy framework nelze dle dane metodiky vubec hodnotit, ale vyhoda je ta, ze se clovek nemusi ucit neco neveho, ale pouzije to, co jiz zna... To je vyhoda nejen pro programoatora, ale i pro grafika... zvlaste, kdyz se grafik vybira v samostatnem vyberovem rizeni. -
Ondrej Ivanic (neregistrovaný)Presne tak, a preto som si do Zend Frameworku dopisal view helper ktory z modelu ocakava pole DOMDocumentFragment a podla parametrov urobi transformaciu.
Zatial je to ale pekne na ..., lebo sa trapim s markup-om. Vacisinou je vystup z Zend_Db_Select ktory som upravil na nieco taketo:
[result id="..."]
[row][field]...[/field]...[/row]
...
[/result]
Co sa mi velmi nepozdava ale na teraz je to pouzitelne. Dalsi problem mam s generovanim ID ktore by som chcel robit tak ze ked zmenim SQL tak sa zmeni aj to ID a transformacia bude neuspesna. zatial sa generuje z nazvov tabuliek -
.=. (neregistrovaný)Dekuji autorovi, na tema php frameworky je to rozhodne kvalitni clanek. Sam v php delam (firemne CI, jinak vlastni) a vzdy mne rozcilovalo jak je php komunita vseobecne povazovana za bandu copypasteru, potazmo pitomcu, ale jak tak koukam na prispevky v diskusi, kdy nekteri ani nepoznaji ze clanek je na vicero casti, protoze rozsahove si o to proste rika (zadna nastavena kase), nebo by chteli benchmarkovat dobu inicializace FW na masivnim poctu zaznamu (jsem jedinny koho zajima lehkost/rychlost inicializace samotneho FW a velky pocet zaznamu povazuje za zkresleni DB vrstvou ?).
-
Karel (neregistrovaný)Jak vám řekne kdejaká kniha o komunikaci: "někteří ani nepoznají, že článek je na vícero částí" je velmi silná kritika autora. A přidám se k vám: pokud se jedná o seriál, má to být v úvodu napsáno. V opačném případě autor své dílo vydává za něco, čím není - za ucelený článek, který provede "Velký test PHP frameworků". Pár slovy v závěru to nespraví, protože tam se moho čtenářů vůbec nedostane a s pocitem podvedených jdou pryč.
-
BFU (neregistrovaný)Nedelej ze sebe hlupaka a nechtej po nas, co si muzes snadno najit:
http://en.wikipedia.org/wiki/Model-view-controller
Jinak, pokud bys nekdy delal na nejakem velkem webovem projektu, pochopil bys, ze uz samotne oddeleni business logiky od zobrazovani dat je dostatecna vyhoda. -
calavera.info (neregistrovaný)Nejlepsi vec na tomto clanku je vyber tematu. Kazdy, kdo se mota okolo pocitacu potrebuje cas od casu vyrobit nejaky web (od ceho jsou kamaradi, ze). Clovek by rekl, ze to je ukol trivialni, ale jakmile se jednou ponori do bazin php kodu, malokdy se vrati nepoznamenan. Bylo by uzasne mit encyklopedii php frameworku, aby se clovek neztratil jeste nez zacne.
Genialni na php je, ze se v nem da skvele prasit. Problem s php je ten, ze se v nem neskutecne prasi. Typicka zivotni cesta vyspeleho php programatora je: bastlic v php - prechod na java nebo jine a pochopeni zakladu softwaroveho inzenyrstvi - zjisteni, ze kdyz je ukazneny, muze to same delat v php s mensimi naroky na zdroje a jednoduseji a tudiz selektivni navrat k php. Problem s php frameworky je ten, ze jejich tvurci pochazeji vetsinou ze stadia 1.
Typicke je to napriklad pro termin MVC. Kazdy si s nim vymyva hubu, ale malokdo tusi, k cemu je to vlastne dobre a jak to udelat spravne. Nedavno mi kamarad pro jeden projekt doporucil Silverstripe. Pry MVC framework s knihovnou pro ORM a vubec vsechno, co je potreba. Kdyz jsem se na to podival, zjistil jsem, ze model je soucasti kontroleru a view umi zobrazit pouze potomky nejake pripravene tridy. Kluci asi hodne hulili, kdyz si o MVC cetli, jestli si o nem vubec cetli. O ORM a ostatnim uz se radsi nezminuju. Separace logiky, dat a zobrazeni nesmi byt pouze "jako", musi znamenat realne oddeleni, tedy teoreticky moznost mixovat M, V a C z ruznych frameworku dohromady. Jediny framework zmineny v clanku, o kterem vim, ze to dovoluje, je Zend Framework (ale dost jich neznam moc podrobne).
Takhle je to s vetsinou php frameworku a jsou to problemy podle meho daleko dulezitejsi, nez rychlost renderovani stranky. Upgradovat server neni nic moc, ale sehnat dobreho programatora, ktery by byl ochotny se pustit do prace s knihovnou, ktera vypada jako parodie na navrhove vzory, to je nemozne - ja uz to taky v zivote neudelam. -
rypacek (neregistrovaný)jak moudra slova... opravdu dobrych frameworku je i dnes jako safranu, ale i tak k tomu php mam odpor... typ "mixed" a vubec ze vsechno je defacto string, to se mi opravdu hnusi. navic funkce, ktere vraci mixed a nebo jeste lepe boolean a zaroven int - to je k popukani s takovou vybavickou psat aplikaci.
nedavno jsem potkal nejaky framework, ktery implementoval vselijake vecicky - aby php nehazelo "note" ale primo exception. k tomu me napadlo, ze by vlastne vubec nebylo marne implementovat zakladni objekty - Object, Integer, String ... atd ... i kdyz je mi jasne, ze 99% "programatoru" php by to neprijalo, a mam dojem, ze dokonce takovych 80% by vubec nechapalo, o co jde.
ostatne, kdo si chce zaprogramovat a nezesilet, dela radeji v Jave nebo .NETu... nebo zkratka v cemkoliv jinem nez v php -
Martin (neregistrovaný)No rekneme si to na rovinu. Delat webovy projekt v Jave nebo .NET muze pouze uplny kokot. A pak jeste par klikacu z Unicornu a podobnych zmrdoznich firem, kteri prosli 14dennim skolenim a mysli si, ze kdyz umi vyplnit Timesheet, tak ze umi i programovat.
Mimochodem nejlepsi PHP framework je Symfony, pak CakePHP, pak mozna Zend, ale to je vice knihovna nez framework. -
Martin (neregistrovaný)No rekneme si to na rovinu. Delat webovy projekt v Jave nebo .NET muze pouze uplny kokot. A pak jeste par klikacu z Unicornu a podobnych zmrdoznich firem, kteri prosli 14dennim skolenim a mysli si, ze kdyz umi vyplnit Timesheet, tak ze umi i programovat.
Mimochodem nejlepsi PHP framework je Symfony, pak CakePHP, pak mozna Zend, ale to je vice knihovna nez framework. -
rypacek (neregistrovaný)proc tak ostra slova? java a .net maji oproti php hned nekolik vyhod - ty samozrejme ale nekdo nemusi ocenit, a nekdo je muze povazovat za nevyhodu, rozhodne bych hned netvrdil, ze ibm, sun, microsoft a jine spolecnosti jsou tupe, protoze nepouzivaji php!
tedy:
- java i .net jsou striktne typove a objektove jazyky ! (zlepsuje citelnost kodu a usnadnuje vyvoj)... jiste, v php lze psat ciste - to ano, ale lze psat i naprosto nesmyslne! a jelikoz je tolik skvelych "programatoru" php, je evidentni, kam asi speje vetsina prebranych php projektu po nekom jinem... a jak sem jiz zminoval, funkce, ktere vraci int a zaroven boolean sou vrcholem stupidity. je hezke, ze mame operator "===" ale ani to mi nejak neospravedlnuje, kdo s takovym zverstvem prisel! a o objektovosti php se neda mluvit ani dnes - sice je to proti php4 zlate, ale ke "standartni" pouzitelnosti to nema nejblize...
- java i .net mohou pouzivat / pouzivaji threading - ... treba udelat request, poslat uzivateli zpravu o tom, ze se neco deje... a zaroven spustit nejaky dalsi thread, ktery operaci vykona... v php bud udelat api pro ajax - coz ale pri urcitem nastaveni stejne nezabrani tomu, ze server nebude dale s uzivatelem reagovat (jeden uzivatel = jeden thread), a nebo si proste uzivatel pocka u prazdne stranky s "loading..."
- java i .net bezi (mohou a nemusi) jako servlety - takze nejake spolecne udaje, dejme tomu treba polozky z menu a par dalsich udaju se mohou drzet v pameti serveru - namisto neustaleho zahazovani a znovu-nacitani... on ani ten caching ktery lze udelat v php neni zadarmo - deserializace boli nejen cpu ale i seekovani disku, na ktery se ulozi nejaky soubor se serializovanymi daty... -
Martin (neregistrovaný)Nekritizuji Javu ani .NET, pouze jejich pouziti pro webove projekty. To je cesta do pekel.
Stejne jako je cesta do pekel pouzit PHP na vyvoj databazoveho enginu nebo hry.
Proste kazdy jazyk se hodi na neco. Dobra je take kombinace PHP na fronted, Java nebo C++ na backend (tim nemyslim na model v MVC ale napr. na vyhledavani, viz Lucene). -
- a mne sa obcas paci, ze true a false je aj 1 a 0, ved je to preddefinovana PHP konstanta.
- aj v PHP to ide, akurat to nie je v kope zaciatocnickych manualov a na php.net to nie je dobre domumentovane.
- aj v PHP ide cachovat data v RAMke, ale .... v kope zaciatocnickych manualov a na php.net to nie je dobre dokumentovane.
Zjavne ste venoval studiu javy a .netu viac casu, ako PHP ;-) -
awe_cz (neregistrovaný)Tohle se neda brat ani vazne - skutecne tim chces rict, ze prasarna bez typovych kontrol je idealni cesta? LOL, hodne stesti.
S vyplody panu z U***** a C***** mam docela hodne zkusenosti, je to hruza, ale pochybuju, ze by to v PHP dopadlo lepe - spis naopak. Problem neni v technologii (.NET/Java), ale, jako obvykle, v lidech. -
rypacek (neregistrovaný)ale perl je... legenda. php je splacanina. nechci tvrdit, ze "java je nejlepsi na svete" nebo neco podobneho. kazdy jazyk, i php, ma sve vyhody. ma zkusenost je ale takova, ze php ma spise vic nedostatku nez vychytavek.
ostatne - nejsem vubec fandou jazyku, v kterych je milion ruznych operatoru - i kdyz i to phpcko ma pravidla, je mnohdy obtizne cist zdrojak po nekom, ktery se vsemi temi operatory ukaji. -
calavera.info (neregistrovaný)To je zlo, tyhle internetove diskuze. Muj prispevek ma velmi jednoduchy ucel. Prosim autora, aby do hodnoceni frameworku zaradil pasaz o kvalite kodu a architektury. Kdyz uz se s tim tak dela neni to moc prace navic a pro me je to zasadni informace. Vetsina meho textu je jen omacka, kterou ukazuju, co presne chci vedet a doufal jsem, ze alespon na rootu se kvuli tomu nestrhne flamewar.
Kdo ma ktery jazyk rad nebo nenavidi je mi uprimne jedno, navic ten clanek o tom neni. Navrhove vzory jsou obecne, jsou jasne a jednoznacne dane a je mozno jednoduse konstatovat, jak moc se jim ta ktera architektura blizi. -
Velice se mi líbí grafické schéma SQL tabulky "Obr. 1. Schéma testovacích tabulek".
Co je to za program?
Hledám nějaký SW nástroj (nejlépe OpenSource), který by takhle zobrazoval tabulku i s klíči, vazbami a měl import/export do SQL jazyka.
Víte o něčem? To by mi opravdu pomohlo. Kdysi jsme na škole podobný SW měli, ale byl celkem drahý a já ho potřebuji jen občas...
Právě něco vyvíjím a SQL tabulku už mám na A1 výkresu, což není zrovna ideální :). -
Nainstalováno a funguje :), už jsem si naimportoval jednu SQL databázi :).
Nejlepší věci jsou holt zadarmo :).
Díky moc, tohle jsem přesně hledal a různé Googlení "freware ..." nepomáhalo.
Asi budu číst Roota častěji, jsem myslel, že tu jsou jen věci ohledně OS Linux. Nenapadlo mě, že narazím na takový skvělý článek o PHP s tolika "udělátkami". -
Používáte někdo eAccelerator (http://sourceforge.net/projects/eaccelerator/), který je uveden v článku?
Jak vidím, je zatím v beta stádiu.
Má cenu ho nasazovat do ostrého provozu? -
Tak to je dobré. Rád bych ho nasadil.
Mám jeden přesměrovací script, kde uživatel čeká v průměru 2s, než ho to hodí jinam a bojím se, že to někdo mezitím nevydrží (může to trvat i déle).
To kešovaní kompilovaného stavy by mohlo hodně času ubrat. Když jsem viděl, kolik to ubralo v článku (90 procent), tak si říkám, že to za vyzkoušení stojí. -
Kdyz uz tady vsichni chvali tu Javu/.NET (moc to osobne neznam, ale tusim), tak mne neni jasna jedna vec. Proc je vyvoj v techto uzasnych technologiich tak priserne drahy?!
Ale jako vazne. Chapu ze ten skvely programator bude mit vyssi hodinovou sazbu nez "PHP lamer", ale to bude tak 2-3x vic asi tezko. A podle toho cim vsichni argumentuji, tak ale musi 10x usetrit diky tem uzasnym technologiim a cistemu prehlednemu kodu. Takze vysledek by mel byt levnejsi. To jsem vsak ale jeste nevidel. -
Napríklad preto, že sa v Jave, alebo .Net-e robia projekty aj 10x väčšie. Nieje problém MVC aplikácia, pracujúca nad niekoľko TB databázou (tým pádom žiadne mySQL, ale poriadna DB, povedzme Oracle), s niekoľko 100-vkami view-ov (ktoré sa často krát ešte zdieľajú) a BL, ktorá zabezpečuje mechanizmus hodne zložitý len na popísanie v analýze. Takže práca na takom projekte je náročná už len kvôli rozsahu. Ak by sa použil jazyk a technológia, ktorá je neprehľadná sama o sebe, tak to nie je šanca dokončiť, keďže nutne musíš pracovať v team-e, a to nie 5 človekovom, ale povedzme rádovo 10-ky ľudí.
-
Ja jsem se ale neptal proc je chleba drazsi nez rohlik ;)
Ptal jsem se proc rohlik upecenej v Jave je drazsi nez kdyz se pece v PHP.
Ale pokud jsi chcel rict, ze Java je pouzitelna az tam, kde PHP skonci, tak pak se to da brat jako zajimava odpoved.. nicmene ne na otazku na kterou jsem se ptal :)
Samozrejme mluvime o stejnych projektech. A pokud si myslis ze projekt velikosti X se neda v PHP resit, tak pak mluvme o projektu Y kde Y<X -
JJ, v podstate som xcel presne toto povedať. Za programovanie v Jave ma platí zamestnávateľ. Napriek tomu, že skúsenosti s Javou mám väčšie ako s PHP, svoje súkromné, alebo malé projekty nerobím a ani nehodlám robiť v Jave. Práve preto, že je to s delom na vrabce, a to hlavne narážam na to, ako veľmi by to bolo neefektívne.
BTW, prečo berú programátori v Jave viac ako PHP-čkari? Nemôžem sa vyjadriť nestranne, takže dúfam, že je jasné tá irónia z nasledujúceho konštatovania: Podľa mňa preto, že Javisti musia vedieť aj programovať, nielen bastliť selecty v PHP.
Peace :) -
... (neregistrovaný)Jave developeri neumi vubec programovat, ale naopak umi velmi dobre modelovat a navrhovat architekturu enterprise projektu. Museji umet co nejlepe zvolit potrebne komponenty a pospojovat je dohromady, algoritmy jsou vyreseny o nekolik vrstev nize.
PHP drtiva vetsina lidi neovlada, teto vetsine rikejme script kiddies, bastlici "selecty". Ti, ktery PHP ovladaji maji objektovy pristup ke vsemu, vcetne XHTML.
Umim-li Java/PHP/C/C++ a dalsi jazyky na pokrocile urovni, mohu si vybrat kterym se chci momentalne zivit, zvolil jsem si kombinaci vseho a tomu se teprve rika umet programovat =) ...Zatimco slabsi jedinci zakrneli u lepeni komponent dohromady a dal se evidentne nikdy nedostanou. -
- Programovať: Na túto tému už bolo hodne diskusii aj tu na root.cz. Skalný C-kari, čo kódujú moduly do jadra nepovažujú Javistov za programátorov, ale OOP lego skladačov. Netrúfam si hodnotiť, hoci robím aj do jedného aj druhého, čo je skutočné programovanie, pretože oboje je o niečom inom. Iné problémy, iný rozsah a preto sa uplatňuje aj iný prístup.
Domnievam sa, že ten, kto vie naozaj programovať, nepostráda jednú podstatnú vlastnosť - schopnosť sa učiť a teda nerobí mu podstatný problém naučiť sa viac ako jeden jediný najsamlepší jazyk. Takže ak naozaj vie princíp, dokáže sa naučiť ako Javu a OOP, tak C, alebo PHP, alebo PHP5 OOP, takisto ako SQL, PL/SQL či HTML&CSS&JS.
K tej tretej časti: ak viem naozaj Javu/PHP/C/C++, tak rozoznám minimálne OOP jazyk od funkcionálneho, procedurálneho a nebudem v každom programovať tak, ako je to v ňom prirodzené, aby keď niekto po mne chytí do ruky kód nemusel najprv blejt... A keď mi daný jazyk neumožňuje dostatočne riešiť úlohu, použijem vhodnejší.
Neuznávam ako nejsprávnejší prístup "ja v mojom jazyku vyriešim všetko.... ja aj v C viem písať objektovo". To je na dlhú debatu, ja to považujem za prasenie kódu, nie za umenie.
Naopak, súhlasím s tými slabšími jedincami. Kopa "kóderov" prečíta knihu php a mySQL a razom je z neho softwarový inžinier, a všetkým Oraclistov posiela do ..., sú to len GUI klikači (lebo niekde videl Oracle Forms....) a všetkých Javistov a .NET-ťákov považuje za lepičov komponent.
Kopa naopak kúpi niečo o jave, nainstaluje NetBeans-y, alebo SharpDeveloper, zbuchne nejake O o = new O(); o.metoda(); a už je majster OOP, a PHP sa mu bridí... -
Podivné na tom je práce ten dopyt/ponuka. Ak je Java taká jednoduchá, také Lego, tak je mi divné, že ju nevie každý absolvent IT smeru...
Domnievam sa, že schopných programátorov v PHP (to sa ním necítim byť, do PHP kafrem amatérsky) je tak isto málo ako schopných Java programátorov. Rozdiel je len v tom, že veľké projekty robia (dostanú robiť) väčšie firmy, ktoré kladú určité nároky na svojich ľudí, takže tam sa skôr uplatnia ľudia, ktorí majú tendenciu odborne rásť. Naopak mnohé maličké projekty sú tak veľmi nízkorozpočtové, že sa firme oplatí zamestnať rýchlokvasených PHP-čkarov (najlepšie študentov), ktorý niečo zbúchajú, bez toho aby do týchto ľudí čokoľvek investovali. Tým sa zvyšuje číslo projektov v PHP, ale aj klesá cena "programátora". -
calavera.info (neregistrovaný)Viz muj predchozi prispevek. Pokud chces udelat par statickych stranek, nebo maximalne nejaky rubriky clanku, je to super. Pokud se pustis hloubeji, je to vyvojarske peklo. Navic zere neskutecne mnoho pameti. Nejdriv jsem si myslel, ze jen ta cms admin stranka, ale nedavno prestal fungovat jeden typ stranky - byl dosazen memmory limit 48 MB - na to se da rict jenom wtf.
-
mw (neregistrovaný)Z pohladu vysledku (velmi spokojny zakaznik, malo prace, minimum kodu, skoro nulova administracia, novy na zelenej luke) mi vychadzaju tieto 3 scenare:
1. ciste PHP+PEAR tvoriace XML s niektorou DB ako backend, Flex ako frontend
2. Ruby on the rails + DB
3. Sybase SQL Anywhere free web edition (novinka) so zapnutym web services + Flex frontend
performance nech riesi zelezo.
ČLÁNKY DO MAILU