Názory k článku
Ruby on Rails 2.0: Evoluce, nikoliv revoluce

will_paginate používám už delší dlouho k velké spokojenosti, pro případné zájemce jsem napsal krátký návod: http://linuch.cz/item/will-paginate-strankovani-v-ruby-on-rails/

Mezi další vyřazené věci patří hlavně různé acts_as_xxx z ActiveRecord, které se změnily na pluginy.

trochu mimo misu, ale vie mi niekto odporucit framework pre php? nasiel som porovnanie
Zend Framework, CakePHP, Symfony Project, Seagull Framework, WACT, Prado, PHP on TRAX, ZooP Framework, eZ Components, CodeIgniter - ale nejaka osobna skusenost a odporucenei by bodli. Dik a hlavne ziadne flamewar plz

Presne to same jsem podstoupil pred par mesici, vyhral jednoznacne CodeIgniter, duvodu bylo mnoho, ale hlavne: Uz mi na tom 4 tydny bezi vyvoj projektu a vsichni zucastneni jsou vic nez spokojeni.

Souhlas, doporucil bych take CI. Krome CI jsem aktivne psal uz jen v CakePHP, ale CI byl pro jako cerstvy vzduch... CI ma sice dost zakladni ORM (AFAIK neumi one-to-many a many-to-many), ale neni problem ho vymenit za jiny (Doctrine, Junction, EZPDO) a CI model pouzit jako servisni vrstvu.

CI vam vic rozvaze ruce, ale porad zajisti zakladni MVC separaci a par dalsich veci (na rozdil od Cake je tam dobre vyresena validace a par dalsich knihoven).

Odporucil by som vam skvely fork CI, Kohana. Vznikol kvoli tomu, ze CI sa distancovalo od komunitneho projektu a vobec nevydaval zmeny a neopravoval chyby.

http://kohanaphp.com/

Kto ma rad vyhody PHP5 tak tu ich s radostou vyuzije. Migracia z CI na Kohanu je velmi jednoducha, kedze zakladny princip je rovnaky. Naozaj stoji za to.


A potom na stredne velke a velke projekty v PHP by som odporucal Agavi. Je to priamy nastupca frameworku Mojavi.

A jak na Kohanu zareagovala komunita kolem CI? Preslo hodne lidi?... protoze CI ma precejen uz nejake to prostredi.

Agavi vypada dobre, ale kdyz uz neco vetsiho, tak Stripes ;-) Ale to jaksi neni PHP...nastesti ;-)

No presli taki vyvojari, ktori do CI prinasali napady, ale neboli vypocuti.
Zatial ma Kohana 2500 stiahnuti, na necely mesiac co existuje stranka tak to neni zle.
Co sa tyka dynamickosti vyvoja tak sleduj TRAC TIMELINE. Kazdy den nejake zmeny, na verzii 2.1 sa pilno pracuje. CI je uz akosi 1 rok bez vyvoja. Su tu dokonca ochotni uzivatelia, ktori ti vedia odpovedat aj na uplne zaciatocnicku otazku. (dovie dokedy im to vydrzi :))

Ked uz nieco v Jave tak by som dal prednost Groovy nadstavbe, dufam, ze coskoro budu na neho nejake frameworky. Predsa Java sama o sebe je kanon. A web tolko toho nepotrebuje.

Sorry. Ten Framework pre Groovy som prestrelil. Existuje uz, a vola sa Grails

Ze java na webu je kanon, to je fama... Taky jsem si to myslel, dokud jsem se sam neodhodlal se na to alespon zbezne mrknout :) Pak jsem zjistil, ze diky podpore JEE v Eclipse je setup servlet kontejneru a napsani prvni aplikace pro zacatecnika mnohem jednodussi, nez nastavovat Apache a PHP... Stahnete tomcat, zaregistrujete ho jako runtime a jedete.
Nikdo vas prece nenuti pouzivat cely Spring stack nebo Strutsy... JEE samo o sobe prece neni nic jineho, nez specifikace servletu, jsp a dalsich technologii, ktere muzete a nemusite pouzit. Nemusite pouzit vubec zadny framework na to, abyste mohl napsat alespon malou modularni a objektovou aplikaci. To se mi na tom libi. Navic nikde jinde jsem nenasel tak principielne genialni vec jako jsou taglibs u JSP -- do nekonecna rozsiritelny sablonovaci system... A to nemluvim treba o principu servlet filtru... "Pluggability" :) Centralne nastatovane error pages mapovane na druhy vyjimek, etc etc...
Nehlede na obrovske mnozstvi knihoven, ktere pro Javu jsou. A pro mnohe jinde alternativu nenajdete -- XSLT 2.0, XSL-FO a dalsi technologie...
Doporucuju vam se na Stripes mrknout. Mnoho javovskych frameworku me drive ci pozdeji odradilo tim, jak neco delaly zbytecne slozite, Stripes se to zatim nepodarilo :) O Stripes se uz pred rokem mluvilo jako o the new Rails.

Dakujem za velmi obsiahli prispevok.

Do Javy som chcel kedysi preniknut, ovladal som (stale ovladam) PHP, ale Java mi prisla dost tazkopadna. Preto som toho nechal. Nepoznal som nejake jednoduche frameworky, okrem Spring, ale ten bol prilis velky na to, aby som sa do toho dostal jednoduchym sposobom.

Na Ruby a podobne derivaty som prechadzat nechcel, pretoze kedze som viac menej odchovany na PHP tak mi jeho syntax prisla zmatocna a nepochopitelna.

Zaujalo ma Groovy ako dynamicka odnos Javy. Kedze je to len nadstavba nad Javu, pouziva tej isty bytecode, cize s JVM nie je problem.

Zda sa, ze mate s tymto bohate skusenosti. Nemohli by ste ma odkazat na nejake kvalitne a hlavne prikladom obsiahle stranky ? Prilis obsiahla teoria na zaciatok mi nevonia a aj ked niekoho chcem nieco naucit, tak mu nebudem hovorit ake je vsetko krasne a co to dokaze, ale ukazem mu priklady a od toho sa odvijam.

Nevydrzite se studiem pockat na zacatek pristiho roku :-) Neco chystam i zde na Rootu, ale driv nez v lednu to nebude.

Vydrzim vydrzim. Kedze mam momentalne nieco rozpracovane, cim zabijem pocitam aj januar. Takze budem upenlivo cakat :)

Ruby (Rails) sa mi trochu zhnusilo, uz len z toho principu, ze je okolo toho velmi velka modna vlna, co sa mi potom prieci prechadzat na to, len kvoli tomu, ze to je popularne.

Vždycky mě zajímá, proč popularita někoho odrazuje :-) Pokud bych to vzal racionálně, tak popularita je naopak přínos, hlavně u open-source produktů. Větší komunita dodává víc kódu, nachází víc bugů, zveřejňuje víc pluginů a dokumentace, poskytuje lepší rady na IRC kanálech.

ja to vnimam uplne identicky... dnes je tu ruby on rails, zajtra bude v mode skunkweb postaveny na pythone :)

Viac ludi, vacsia popularita, viac idiotov na jednej kope, ktori ti dokazu vec znechutit. Asi tolko :)

Me na RoR take odradila z casti popularita (z casti to, ze se mi proste Ruby nelibilo jako jazyk a uz jsem se aktivne zajimal o Python a snazil se z nej udelat svuj "tool of the trade").

Odradilo me to proto, ze ta popularita je z casti zpusobena Web 2.0 hype a tim, ze Railsy byly proste prvni (vicemene). Kdybych mel jistotu, ze ta popularita pochazi 100% z racionalnich pohnutek a ne ze stylu "Railsy jsou ted IN, tak se to naucim, abych byl jako taky ten webdevelopr", nevadilo by me to, jenze u Railsu tu jistotu nejak nemam...

Popravdě je mi úplně jedno, čím je popularita čehokoliv způsobena. Firefox je populární a je kvalitní, Linux je populární a je kvalitní, virtualizace serverů teď začíná být velkým buzzwordem a taky je to skvělý nápad. Stejně tak je PHP velmi populární, ale to nepoužívám, protože mi nevyhovuje. Nebo Apache je extrémně populární, ale taky ho opouštím, protože maličký a mnohem méně známý Nginx mi pro nasazení Rails aplikací vyhovuje mnohem víc.

Neboli pointa - u kvalitního projektu je popularita plus, za tím si stojím. Ale kvalita je pro mě stejně vždycky prvním měřítkem a Railsy používám, protože jsou kvalitní. Ostatně začal jsem je používat v době, kdy v ČR byly neznámým pojmem.

Popravde. Teraz co poviem je len moj osobny nazor.

To co si vymenoval (dovolym si tykat, ak to nevadi) su popularne produkty v odbornesej verejnosti. Uz vidim tych ludi co vykrikuju, ze Linux je najlepsi a pouzivaju nieco ine, lebo s tym nevedia (priklad hypu ukolo Ubuntu, taktiez moj pohlad).
Virtualizacia je super vec. V serverovom segmente velmi vykonna a bezpecna zbran. V deskotpe ju osobne tiez vyuzivam, ale to z toho dovodu, aby som sa mohol ak mam naladu ucit openSUSE, inak mam legalny Windows Vista.

PHP je velmi popularny, ale okolo neho necitim tu hype vlnu, kde kazdy vykrikuje, ze tento jazyk je najlepsi na web atd.

Ono je treba rozlisovat medzi popularnostou v odbornej casti a popularnostou medzi tymi, co sa drzia trendov.
Je mnoho velmi pouzitelnych projektov napisanych v PERL, Pythone, mozno aj PHP, ale zatial som nepostrehol podobne projekty v Ruby (opravte ma ak sa mylim). Ak by mal byt tak neskutocne prelomovy oproti inym jazykom tak by tu tie aplikacie boli.

Samozrejme ho neodsuduzjem, je to dalsi jazyk,ktory sa na nieco hodi a na nieco nie. Len mne zatial nevyhovuje. Urcite ma lepsi objektovy model, ktory by som uvital tiez v PHP.

Taktiez suhlasim s tym, ze Rails su velmi dobrym frameworkom, ktory dava velke moznosti v o vytvoreni pekneho aj hnusneho projektu. Vela inych frameworkov sa nim inspirovalo, co je len dobre. Lenze na moju smolu, ze som okolo Railsov, stretol ludi, ktori velmi vykrikovali, ze preco pouzivam este ten shit PHP. Vsak oni nedokazali ani dobre programovat a analyticky mysliet. Oni ocakavaju, ze ked dostanu do ruk lepsiu zbran, ze dokazu byt namakanejsi. Co si osobne myslim, ze pravda nie je.

Ne, tykání mi opravdu nevadí, naopak :-)

Samozřejmě jsem vyjmenoval jenom produkty mezi odbornou veřejností, protože tam se myslím pohybujeme.

Proč není v Ruby hromada použitelných produktů má vcelku jednoduchý důvod - Ruby je sice zhruba stejně staré jako Python nebo PHP, ale dlouho to byla jenom hračka pár Japonců. Teprve když vznikly Rails, tak se o tom vůbec někdo dozvěděl.

No a co se týče toho posledního, na to mám vcelku jednoduchou odpověď. Nevidím důvod, proč bych měl podobné lidi poslouchat, tak je neposlouchám. Railsy používám, protože jsem je vyzkoušel a vyhovují mi. Křiklouni se dají najít v každé skupině a důvod proč jsem se do téhle debaty zapojil byl můj zájem vědět, proč je lidi poslouchají a nebo proč řeší momentální hype :-)

Lahko sa s tym vysporiadovavas, ze nepocuvas tych radobydeveloperov, no ja s nimi obcas musim pracovat.

Popravde sa priznam, ze som chcel do Ruby trochu bastrngovat ked vyjdu Rails 2.0. No ony su to, ale citim, ze este asi nedosiel ten spravny cas. Cakal som, ze budu naviazane na Ruby 2.0, no este to nejako nedozrelo. Tak zase chvilu pockam :)

Trochu sa aj obavam inej syntaxe nez na aku som zvyknuty. Mohol by si povedat svoj postoj k tej syntaxe ? Kazdopadne ocakavam co najviac nezaujaty, len porovnanim s inymi typmi.

Naštěstí jsem do velké míry svým pánem :-) Lidi, co trousí na fórech a v diskuzích "X sux, používejte Y" taky nesnáším.

Ruby 2.0 je daleko, hlavní novinkou v něm má být nová VM. Jelikož ale v Rails, podobně jako ve všech webových frameworcích, je ve většině případů brzdou databáze, tak zrychlení jazyka velkou výhru nepřinese.

Co se týče syntaxe - nedělalo mi to žádný problém. Někdy je hloupá její přílišná volnost, která při práci více lidí na jednom projektu vyžaduje dát pravidla a dodržovat je. Například při volání funkcí můžou být závorky nebo taky nemusí, bloky se dají uzavírat pomocí end nebo celé mezi složené závorky atd. Pokud bych měl napsat věc, kterou považuju za největší opruz, tak to jsou jednoznačně chybějící operátory ++/-- :-)

Větší problém samozřejmě pro mě byl naučit se typické "jak se dělá to a to". Naštěstí IRC kanál Ruby je plný lidí, kteří zmigrovali z PHP, takže jsem jenom psal "something like xy in PHP".

Dik moc.

Kazdopadne este chvilu potrva nez sa do niecoho podobneho pustim. Od Ruby 2.0 som ocakaval trochu striktnejsiu pracu s kodovanim, ale to co je v navrhu sa mi vobec nepaci.

Prave naopak. Databaza je da sa povedal najrychlejsou castou (pokial je spravne optimalizovana a dobre navrhnuty model), jedina brzda je skriptovaci jazyk a HTTP request. Pokial nie je kanal perzistivne otvoreny tak to je dost problem.
Ruby je samo o sebe strasny moloch co sa tyka interpretovania vlastneho kodu. V tomto ma velmi, ale velmi co dobiehat ine jazyky.

No zda sa, ze by sa to dalo zvladnut, lenze osobne si z financnych dovodov nemozem prechadzat na iny jazyk za behu. Mozno ho raz vyskusam alebo preskocim rovno na Groovy :)

Nu, naše priority jsou trochu jiné :-) Od webového frameworku očekávám, aby mi co nejvíc usnadnil práci a třeba zmíněné kódování je pro mě úplně nedůležitá vlastnost.

TO mas pravdu. Ale tu pomalost, ktoru to bude mat teraz a trochu sa bojim, ze prava s viacerymi kodovaniami v jadre to vazne neurychli, budes klientovi tazko vysvtlovat ;) Uz teraz je to velmi pomale pri vacsich veciach

Ani nebudu muset :-)

a) Ve většině případů nejde o projekty, které by byly až tak heavy-loaded, ale o projekty, které musí být naprogramované nejpozději včera.
b) Serverový HW je neuvěřitelně levná záležitost. Vím, že za tenhle názor by mě spousta lidí sežrala, hlavně ti, kteří museli optimalizovat kód na rychlost/paměť, ale je to zkrátka fakt.
c) Rails mají propracované možnosti cachování až na úroveň jednotlivých fragmentů stránek.
d) Opravdu to není tak zlé :-) Na netu jsou srovnání rychlostí jazyků na algoritmech typu Hanojská věž apod. kde dostává Ruby samozřejmě hrozně na zadek, jenže to není typický příklad jeho použití. A navíc - už teď existují způsoby, jak výkonově náročný kód psát třeba v C a volat přímo z Ruby.
e) Pravděpodobně se to bude zlepšovat: http://en.wikipedia.org/wiki/YARV

No ved prave, aplikacie najneskor vcera dokoncene.

To je podla mna tej problem, hodi sa tak na web kde sa vacsinou SELECTuju data z databazy. Na vacsi system by som sa to bal nasadit. Hlavne ak sa bude pracovat s velkym mnozstvom dat.

Cachovanie nie je vsemocne, samozrejme pomoze. Tuto by som sa trochu ohradil v pouzivani. Videl som vacsi projekt napisany pomocou Railsov a uz len generovanie cistej strany mu trvalo dost dlho, co potom praca s datami z formulara ?

Ono tie testy nie su az tak na zahodenie, ked si zoberies, ze pri generovani nejakej zlozitej stranky, kde sa cyklami dokaze prehadzat tisicka zaznamov je uz poznat. A ak je vykon celej aplikacie pomaly v tomto stadiu pri jednom uzivatelovi, co to urobi pri stovke uzivatelov za hodinu (priemerny portal) ? Toto nie je len o vykone serverov.

Omlouvám se, ale debaty o výkonu mě nebaví - každý ví, že Rails nejsou extra rychlé, já vím, že nejsou tak pomalé, jak píšeš a to mi stačí ;-) Navíc neřeším cizí projekty, o kterých nic nevím a stejně tak se nezabývám stránkou, kde by se v cyklech prohazovalo 1000 záznamů, protože existují uložené procedury a dalších x způsobů, jak to vyřešit lépe :-)

Chapem :)

Len poznamka, nehovorim o cykloch, kde sa overuje WHERE, na to je SQL a ulozne procedury nie su vsemocne, niekde musis povinne prejst cele pole.

ALe to uz su debaty fakt o vykone. Osobne by som na vacsi projekt, ktory ma byt dostupny aj zvonku nenasadil railsy. Na veci typu CRM a pod sa da nad tym uvazovat.

Java mi drive take vadila, ale treba prisnou typovou kontrolu jsem si nakonec docela oblibil... kdyz nic jineho, ulehcuje to vyvojovemu prostredi nabidnout vam kvalitnejsi code completion... A i tak mi pripadne, ze se kod lepe chape, kdyz mate ty typy dane.
Bohate zkusenosti, to bych o sobe netvrdil...jen me to posledni dobou dost chytlo :-) No nejdriv je asi dobre pochytit zakladni principy toho, jak fungujou JEE kontejnery a principy servletu a filtru. Sice starsi ale pro zacatek dobry serial je na Intervalu, psal ho dokonce vas krajan, takze pochopitelny by mel byt: http://interval.cz/clanky/java-servlets-predstavenie-technologie/
Dobre je taky se vzdelat v tom, jak aplikaci strukturovat, pokud dojde na nejakou interakci s datovym zdrojem. Tedy ze nebudete psat SQL dotazy v tele servletu :) Ale ze je fajn mit servisni vrstvu, pokud cekate, ze budete menit datove zdroje, tak mit i Data Access Object factories, ktere vam vrati dany DAO (najednou se rozhodnete, ze to nechcete mit v DB, ale v XML, tak zmenite DAO a zbytek aplikace o zmene data storage nebude vedet vubec nic) a ten se dotazuje bud primo pres JDBC do databaze, nebo pres nejakou perzistentni/ORM vrstvu. Ja osobne jsem si ted u jedne aplikace dovolil DAO nepouzit, JEE architekti by me asi radi nemeli, ale ja jsem to risknul a v servisni vrstve pracuju uz primo s kontextem Apache Cayenne, coz je dle meho nazoru skvela ORM/perzistencni knihovna na praci s databazi (dostali se do Google Summer of Code a pouziva to treba NHL.com). Take proto, ze obsahuje ve Swingu napsany GUI modeller, ve kterem si namodelujete vztahy v DB a on vam vygeneruje domenove tridy -- usetri plno prace.
Mimochodem tyhle vzory se daji stejne tak dobre pouzit v PHP, jen technologie se zmeni.
No a pak zkuste prolitnout tutorialy a priklady na Stripes (http://stripes.mc4j.org/confluence/display/stripes/Home) a nebo nejaky jiny framework podle gusta... Ale Stripes jsou podle meho v soucasne dobe to nejjednodussi a nejprehlednejsi ( a pritom mocne!), co ve svete Javy na webu existuje.

Aj ja som nad typovou kontrolou premyslal prave vcera. Neviem ci to je lenivost mna ako developera, ale neviem zaujat postoj ci je to dobre vec alebo nie pri dynamickych webovych jazykoch.
Ak sa mam pozerat na to zo strany cloveka a nie stroja tak je pre mna "1" a 1 na pohlad to iste. V tomto mam rad pristup PHP, ze ci je cislo ako string alebo integer, tak je to stale cislo. Kedze nemozes ocakavat co ti kto posle. Vystup z SQL, HTML a URL dostanes vzdy ako string, cize musis pretypovavat. Chapem, ze je to bezpecnejsie pretypovavat, ale "som lenivy" a ocakavam, ze nieco podobne za mna spravi framework.

Druha strana je z pohladu stroja. Pre neho je konzistiva dat velmi dolezita ako na "vykon" tak spravny chod.

Cize je to na dlhodobu debatu. Pri kompilovanych jazykoch typovu deklaraciu vitam, pri dynamickych som tomu zatial nedosiel na chut.

Len sa bojim toho, ze ak sa do toho dostanem tak zacnem rozmyslat ako stroj.

Inak aby sme sa vratili k teme, chyba mi na weboch clanky ako pracovat v inych frameworkoch ako Rails. Ci uz je to Django, Agavi alebo spomenuty Stripes ci Grails.

mrknete na ten Stripes, v Quick Start Guide je krasne videt, jak jejich databinding za vas resi prevod cisla z formulare na javovsky double.

A, pan Tisnovsky chysta serial, takze me urcite opravi, pokud jsem neco napsal nepresne :-)

je to v poradku :-) Zatim mam nastrel serialu a asi zacneme jednoduchymi JSPcky. Sice to neni z hlediska MVC apod. moc ciste, ale JSPcka maji vyhodu v tom, ze se daji naucit a predevsim pouzivat velmi rychle - jak jste rikal: stahnout Tomcat, vytvorit ve work adresari nove JSPcko libovolnym textovym editorem a uz to funguje - zadne XML, slozite konfigurace, definice rendereru, preklad servletu atd. Proste docela jednoduche. Ale kam se v serialu dostaneme, jestli ke skutecnym J2EE aplikacim, se uvidi...

Proboha, J2EE snad patří spíš na BDSM.cz... :-D

neboj, J2EE nejsou jen EJB, ktere se fakt - zejmena ve verzi 2 - nepovedly:-) Je to proste soubor knihoven a doporuceni pro implementace, zadnou vedu v tom nemusime hledat.

No, ona bohuzel v tom veda je a to dost velka :)
Netyka se tak ani vlastni beany, jako spis sestavovani J2EE aplikaci s podporou X frameworku, sestaveni... :)
Sice existuji silne nastroje jako Maven, ale bez predchozich znalosti.. no nevim nevim.

Jinak EJB3 jsou schopny podpory anotaci + dependency injection, ale v zakladu se nic moc nemeni.

Pokud zacnete psat serial o JSP a Servletech, tak nevim koho tim dnes oslovite. Uz jen z duvodu toho, ze bud se pouziva JSF (component) ci Struts (command) framework, ktery je dost odstinen od nejakych servletu.
Ja treba navic pouzivam jeste Seam, ktery je jeste castecne odstinen od JSF. Pisi vcelku velkou aplikaci a zatim jsem nemel potrebu jit do JSP ci Servletu, ktere jsou pro me v te chvili nizkourovnovy zpusob (asi jako JDBC vs ORM - Hibernate ci JPA).

iste, ale na php najdete milion lacnych hostingov, na j2ee nic.

Groovy na web vypadá opravdu nadějně, Java bohužel "write less, do more" nesplňuje.

Je teď vývoj Stripes aktivní? Zdá se mi, jako bych o něm delší dobu nic nového neslyšel. Nebylo by špatné, kdyby dořešili věci jako možnost používat pěkná URL apod., což tuším mělo být ve verzi 1.5.

Podle deni v mailing listu vyvoj stripes aktivni je a nekteri pouzivaji current vetev i na ostre aplikace. Dnes se v listu objevila zprava, ze 1.5 by mela byt venku behem par mesicu.

Co se tyka "peknych URL", tak ty je mozne pouzivat i v 1.4.x za pomoci rozsireni Clean URLs (http://remi.mongus.com/stripes-clean/), i kdyz je k tomu potreba trosku vice hackovani (musite odvodit novou tridu pro stripes:errors JSP tag, protoze ta stavajici nebere syntax clean URLs v uvahu a validacni chyby se vam tim padem nikdy nezobrazi -- ale jde jen o zmenu na par radkach). V 1.5 by vsechno tohle melo byt vyreseno interne.

Kazdopadne muzete ti pomoci UrlRewrite servlet filtrem, coz je obdoba mod_rewrite pro Apache (a umi vyuzivat i specificke vlastnosti kontejneru, ne jen interni presmerovani)

Na to rozšíření se podívám, díky za tip.

UrlRewriteFilter znám, ale přiznám se, že nejsem moc příznivcem podobných řešení (míněno pro pěkná URL), a to ani u servletů, ani u Apache. Připadá mi to odtržené od zbytku aplikace a hůř spravovatelné. Nepříliš elegantně se pak také řeší takové věci jako například lokalizovatelná URL.

Uz zase, Danieli? ;)
Co je podle vas spatne vyreseno na validaci v CakePHP, prosim?

Ano, Jitko, uz zase ;)

Asi se shodneme na tom, ze validace muze byt definovana jako proces zjisteni, zda data prichazejici od uzivatele vyhovuji nami vybranym kriterium.

Kdyz vezmete v uvahu tuhle definici, pak vas musi pristup CakePHP prastit do oci: proc nekdo vaze system validace na Model? To je ta zakladni chyba, ze validace je nejen konfiguracne vazana na Cake model (tedy to, co oni tak odvazne nazyvaji modelem, ale co je ve skutecnosti pouze servisni vrstva, na kterou bud musite zahaknout third-party ORM nebo se smirit s temi jejich PHP poli), ale i procesne -- defaultne probiha nekdy behem ukladani modelu do DB, ne? A pokud chcete v Cake validaci zaridit nejakym slusnym zpusobem, musite menit standardni chovani.

Zakladem me argumentace je totiz platne tvrzeni, ze k validaci muze dojit aniz by se nasledne cokoliv delo nad datovou zakladnou/Modelem/domenovou vrstvou (ci jak to nazveme) a take ze k validaci muze dochazet nad daty, ktera ani nikdy do databaze nemaji prijit -- a to uz stavi system validace v Cake do problemu.

Proto povazuju system validace v CI za mnohem lepsi, protoze je ABSOLUTNE nezavisly na tom, jake dalsi vrstvy jsou pod controllerem (a kolik jich je)

Mnou zminovany javovsky Stripes taktez -- validaci provadi pri databindingu na ActionBeanu. Absolutne si nedokazu predstavit, ze by validace formularovych dat mela probihat na servisni vrstve nebo snad DAO ci domenove.

S vasim oblibenym "convention over configuration" zde nepochodite, tohle je proste architektonicka chyba jak prase. Naopak, pochodim s tim ja proti CakePHP, protoze CI na rozdil od nej ma mnohem vice preddefinovanych validacnich kriterii, ktere snizuji potrebu "configuration" (4 vs. 11 + 5 pomocnych fci)

Presouvate teziste nekam jinam. Nehodlam s vami rozebirat rozdily mezi pojetim MVC v ruznych frameworcich - a tim spise ne pod timto clankem, jehoz autorovi i ctenarum se timto omlouvam za me prispevky v off-topic threadu.

Podle meho nazoru je naprosto v poradku, ma-li byt vrstva zodpovedna za nakladani s daty zaroven zodpovedna za jejich validaci. K vasemu 'platnemu tvrzeni ktere je zakladem vasi argumentace' - skoro to vypada jako by jste nevedel, ze validaci dat muzete v CakePHP provest i bez pokusu o jejich ulozeni.

Presouvate teziste nekam jinam. Nehodlam s vami rozebirat rozdily mezi pojetim MVC v ruznych frameworcich

Nerozebiram tu MVC, validace dat nema s MVC nic spolecneho -- ani to kdy a kde se deje.

Podle meho nazoru je naprosto v poradku, ma-li byt vrstva zodpovedna za nakladani s daty zaroven zodpovedna za jejich validaci.

Ale proc? Predstavte si, ze mate prichozi data z formulare, ktera potrebujete zvalidovat a potom nasypat napr. do generatoru faktury nebo je odeslat mailem a ta data ani neodpovidaji strukture zadneho z vasich modelu. Tak kam validaci date? V CI proste natahnu tridu validatoru, priradim ji validacni pravidla napsana pro tuto prilezitost a validator spustim. Jak napisete v Cake modelu validacni pravidlo pro pole, ktere v tom modelu neexistuje?..a i kdyby to slo, nebije vas to do oci, to takhle delat?

skoro to vypada jako by jste nevedel, ze validaci dat muzete v CakePHP provest i bez pokusu o jejich ulozeni.

To, o cem tu celou dobu pisu, neni ZDA to jde udelat, ale JAK a jestli je ten nastroj dobre architektonicky uzpusobeny k tomu, aby to tak slo udelat.

To se rovnou muzeme shodnout na tom, ze udelat lze vsechno vsude a diskusi uzavrit. Ale ja tu mluvim o tom, ze tvurci Cake umistili mechanismus validace tak, ze vas v nezanedbatelnem procentu pripadu donut drbat se levou rukou za pravym uchem.....

uzivatel si neprial zostat v anonymite, len nechapem preco ma neprihlasilo ked som mal vyplnene aj meno aj heslo nad prispevkom ;)

Clanek na ktery odkazujete (7 reasons...) se mi take moc libil. Zde na ROOTu na nej pred casem upozornil Petr Cimprich http://pcimprich.blog.root.cz/0710/navrat-od-rails-k-php

cakephp

http://www.akelos.org/

Koukám na vzniklou debatu o php frameworcích. Je to tu sice offtopic u článku o ROR, ale dovolte mi se tu zeptat. Protože pohledat v Čechách lidi, zabývající se těmito php frameworky, je velmi obtížné a myslím, že je to na dobrou věc. Tedy byl bych rád, kdyby nás někdo z programátorů mohl seznámit s nějakým, zde vyjmenovaným frameworkem, na lednovém setkání phpkářů věnovaném právě frameworkům. Jako pořadatel bych měl zájem o ukázku některého z těchto frameworků:
Kohana, CodeIgniter, Agavi, Akelos, Qcodo.

Informovat o konferenci a zeptat se na možnost předvedení můžete na mém mailu: stv(zavinac)seznam.cz
Souhrnné info o konferenci:
http://blog.php-group.cz/2007/11/16/registrace-na-konferenci-php-zima-2008/