PHP frameworks, again

[bluesman]

@cvele: Opet pričamo o različitim stvarima. Ja pričam o određenom projektu a ti pričaš o izradi frameworka koji treba da daje razne mogućnosti.

@bokica: ja sam samo rekao da mi je svo ok sa FW osim te priče o "automatski generisanim querijima", ništa više od toga.

[cvele]

Originalno napisao nixa

a i sumnjam da nisu optimizovani upiti za svaki db tip posebno

Aj sad pojasni sta si hteo da kazes :P

Ako si mislio da su pisali po dva+ querija za paginaciju u oracle, mysql etc grdno se varas, to je zesce gubljenje vremena.

Poenta je da za svaku bazu postoji "drajver" (kako ih zovu u adodb npr) koji kreira querije na osnovu pripremljenog (npr) objekta.

[nixa]

Hoću da kažem ako nisu napisali, onda su makar tesitrali svaku stvar na ostalim db serverima, ajde da vidim tog magijaša koji će da izbaci deploy verziju u odnosu na bilo koji adodb driver ili generisanu apstrakciju kroz ORM.

Jednostavno to nije automagicly, a sigurno nećeš da kada radiš iole nešto ozbiljno da bude plug & pray .

[jablan]

Originalno napisao ivanhoe

SELECT * FROM users WHERE username='bla' ORDER BY users.username ASC LIMIT 1

Sam poziv ORM metode je duzi od SQL-a koji bi trebalo otkucati,

To zavisi od konkretnog slučaja, od konkretnog ORM-a i od jezika. Nikako ne može biti neki univerzalni argument za ili protiv.

a generisani upit je pun nepotrebnih stvari

Kojih? Ja vidim samo ORDER BY koji nisi eksplicitno zahtevao, a to se obično podešava na nivou modela. Svako ko ima imalo iskustva sa ORM-om znaće gde sve može da naglasi konkretan redosled.

Nikako, moras da logujes upit po upit dok ne vidis odakle dolazi...

Rails u development okruženju štampa sve upite koje šalje na bazu zajedno sa vremenom izvršavanja, trejsovanje stvarno nije neki veliki problem u realnom radu.

Tačno je da FW-ovi uvode dodatni nivo apstrakcije, i nekom to ne prija. Ja samo mislim da u većini slučajeva objektivno nemamo potrebe da brinemo o tome šta se tačno događa ispod, u suprotnom bismo svi još uvek pisali CGI aplikacije u C-u ili asembleru.

[ivanhoe]

samo treba znati sta ti je cilj, pa odabrati alat za to. Ako neces menjati bazu, zasto bi onda koristio db apstrakciju koja svaki poslati upit prvo preparsira na sitne delove, prilagodi trenutnoj bazi, pa tek onda posalje. Em je sporo, em ume da bude uzasno ogranicavajuce..

Recimo dok sam radio na Vivvu sam imao milion puta probleme sa MDB2 klasom koja ne podrzava razne mysql ekstenzije standardnog sql-a. Pa onda, kad radis paginaciju, umesto da posaljes jedan upit koji ce ti odmah vratiti i koliko ima rezultata, ti moras da saljes 2 upita, kad kreiras tabele u instaleru, malo radis preko MDB2 , a malo moras rucno da pravis upite, jer neki tipovi podataka nisu podrzani, jer nisu standard...

A da povezem ovu pricu sa FW, moja glavna zamerka vecini koje sam video je sto idu presiroko i preambiciozno u smislu da budu sve za sve situacije. To naprosto (jako cesto) ne pije vodu, i onda umesto da nesto brzo odradis u 3 linije koda, moras da se rves sa samim sistemom, pises kontrolere, hookove, napravis 4 klase da bi uradio najprostiju stvar.

To naravno nije problem FW kao koncepta, nego konkretnih realizacija koje su na trzistu... nista dok ne napises sam svoj... with blackjack and hookers

[bluesman]

Originalno napisao ivanhoe

A da povezem ovu pricu sa FW, moja glavna zamerka vecini koje sam video je sto idu presiroko i preambiciozno u smislu da budu sve za sve situacije. To naprosto (jako cesto) ne pije vodu, i onda umesto da nesto brzo odradis u 3 linije koda, moras da se rves sa samim sistemom, pises kontrolere, hookove, napravis 4 klase da bi uradio najprostiju stvar.

Bravo! Ja trtljam vec 2 strane a ti objasnis u 2 recenice.

[zidoo]

^

O tome ja tupim od prvog posta. Zato sam i pito jel ima neko konkretan primjer aplikacije koju je radio, jel zadovoljan itd...

[holodoc]

Originalno napisao ivanhoe

A da povezem ovu pricu sa FW, moja glavna zamerka vecini koje sam video je sto idu presiroko i preambiciozno u smislu da budu sve za sve situacije. To naprosto (jako cesto) ne pije vodu, i onda umesto da nesto brzo odradis u 3 linije koda, moras da se rves sa samim sistemom, pises kontrolere, hookove, napravis 4 klase da bi uradio najprostiju stvar.

Potpuno se slažem sa ovom izjavom () iz razloga što koliko sam ja uspeo da primetim većina PHP framework sistema pokušava previše da se fokusira na abstrakciju konkretnih komponenti sistema (što je potpuno paradoksalno) i da ih učini što je moguće proširivim, umesto da se fokusira na proširivost jezgra sistema, tj. onoga što je u suštini najbitnije za osnovni layout aplikacije i njegovo brzo prilagođavanje potrebama razvoja. Posledica toga je veoma loše delegiranje odgovornosti osnovnih klasa koje jednostavno pokušavaju da budu previše generičke i da odrade što je moguće više iako realno većina funkcionalnosti koje nude nije neophodna u konkretnim projektima.

[pkrstic]

Da se vratim na osnovno pitanje, radm u CI i ZF.
Prednosti CI su ti naveli, a mane koje meni smetaju su:

• PHP4 kompatibilnost (nema auto loada i magic funkcija)
• nema gotove Authentication klase
• relativno spor razvoj
• relativno slaba striktnost u nazivima
• losa reseno pravljenja osnovnih klasa

Na CI se odlucio zbog togo sto mi je najvise licio na kod koji sam sam razvijao i upotrebio, ali na kraju sam digao ruke jer je logika bila da ce nekoliko hiljada ljudi pre naci gresku u nekom parcetu koda , nego sto cu ja videti to isto u svom. Ne slazem se sa bluesmanom do moram da znam kako funkcionise kod da bih ga koristio, jos manje me je interesovao Smarty. Bitno je da radi ono sto se od njega ocekuje i na nacin na koji se ocekuje.
Takodje smatram da je Smarty gubljenje vremena, i da je dovoljan cist php. Da se razumemo Smarty je dobro zamisljen ali po mom misljenju nepotreban, jer dosad niko dizajnera nije naucio da kodira, kao so ni jedan porgamer nije postao dobar dizajner, cak sta vise ne bih ga preporucio pocetnicima jer im je tesko da shvate kako to funkcionise.

Kohanu sam isprobavao ali me je razocarao njen View, koji ne funkcionise onako kako sam ocekivao. Mozda nisam dobro radio. Ostalo joj je ok, ima ACL, module i ORM.

Cela ova rasprava oko toga da li je ORM potreban ili nije zavisi od potreba i znanja korisnika. Onaj ko zna da napise dobar sql nece koristi orm, stvar izbora.

U firmi koristimo Zend, koji radi na sajtovima koji imaju 15M poseta mesecno. Ono sto mi se svidja kod Zenda je velika modularnost i mogucnost podesavanja. Ne svidja mi se sto svi tutorijali lose pokrivaju sam pocetak i podesavanje.

[Aleksandar.Ilic]

Originalno napisao pkrstic

Da se razumemo Smarty je dobro zamisljen ali po mom misljenju nepotreban, jer dosad niko dizajnera nije naucio da kodira, kao so ni jedan porgamer nije postao dobar dizajner, cak sta vise ne bih ga preporucio pocetnicima jer im je tesko da shvate kako to funkcionise.
.

zasto svi smrtnici vole da govore da je nesto nemoguce samo zato sto oni to ne znaju.

Od kako radim sa Smarty-ijem, skoro uvek dizajner sredi templejtove. U krajnjem slucaju ja napravim genericke i dizajner ubaci html/css. A ljudi koji sada rade kod mene u firmi poznaju smarty fantasticno, a veze nemaju sa programiranje.

Drugo, ja sam smarty BUKVALNO kao pocetnik u programiranju i PHP-u poceo da koristim (na nagovor zombi-a) i kao osobi sa 2 meseca iskustva trebalo mi je pola sata da shvatim i pocnem da koristim smarty.

Ovde se ne radi da li je neki FM tezak ili lak za shvatanje. Meni nijedan nije tezak, samo su mi neki ocajni jer su pravljeni po ukusima programera koji su ih razvijali a ne po mojim ukusima.

Ja ne volim ORM i slicne principe. Jednostavno volim da vidim sql u kodu. A s'obzirom da jako retko radim neku aplikaciju od nule, i da su to samo aplikacije za moje potrebe (cms-ovi), klasican gotov FM meni licno nista ne znaci. Vec imam sve sto mi treba razvijeno, ili od mene licno ili na netu (swift, smarty, phpthumb..)