PHP Stilovi pisanja aplikacija (Best design practices)
Ovaj thread sam bio pokrenuo na [es], ali posle dve nedelje je ostao nezapazen, pa sam morao da intervenisem da bih nekom iscupao odgovor. Dobio sam PM od jednog korisnika da postavim isto pitanje na ovom forumu jer tu ima strucnijih korisnika PHP-a.
-- Zeleo bih da se malo razvije diskusija na ovu temu. Zanima me koje sisteme za kodiranje koriste neki od programera koji svaki dan zive sa PHP-om (i zaradjuju 'leba od toga). Voleo bih i da cujem njihovu evoluciju ka savrsenijem kodiranju. Postoje sledeci nacini: 1) PHP embedovan u HTML kod i preklapanje PHP i HTML koda (ono sto svako na pocetku radi, uzas zivi) i kodira se svaka stranica za sebe sa pomocnim funkcija koje odradjuju deo posla Kôd:
<html> 3) Koriscenje nekog od Template Engine-a (FastTemplate, Smarty, patTemplate, Flexy... ) i razdvajanje Logike od Prezentacije 4) Koriscenje MVC programskog modela u kombinaciji sa nekim od TE. Ovo poslednje me je malo zainteresovalo... Naime, skinuo sam source kod galerije slika "Gallery 2" i malo sam ga analizirao (bolje reci izgubio ceo vece na to)... I mogu reci da mi se dopada. E, sad, ne znam koliko je taj pristup dobar za neke manje projekte i isplati li se upotrebljavati ga za jednokratne projekte. Plasi me pomalo odluka da pocnem da navikavam mozak na tako nesto jer sam jako dobro usavrsio model programiranja koji koristim vec neke 3 godine. Mozda je strah neopravdan jer sam slican otpor imao pri prelasku sa FastTemplate-a na Smarty, ali sam video da sam usporio sebe zbog oklevanja. Elem, sada koristim sledeci sistem: Nad svakom tabelom/logickim blokom (clanci, korisnici, inventar i sl.) imam jednu skriptu koja upravlja tim podacima. Npr. skripta se zove adm-inv.php U skripti imam 4 najcesce funkcije: inv-new() inv-edit() inv-save() inv-delete() Preko GET/POST metoda prosledjujem parametar "command" koji je == "new|edit|save|delete" i pozivam ove metode sa $func = "inv-$command"; $func(); Lepo sam napisao pomocnu skriptu koja generise adm-inv.php, adm-nesto_drugo.php i sl. posto sve skripte imaju istu strukturu. Kad dobijem kostur, onda uzmem npr inv-list() i dopisem Kôd:
$rs = $conn->Execute("SELECT * FROM inv ORDER BY id"); Za pristup bazi koristim AdoDB. Nisam opterecen OO programiranjem vec koristim proceduralno programiranje. Nekako je brze. :-) Takodje, ne koristim ni PEAR zbog (jos uvek) lose dokumentacije vec se snalazim sa pomocnim klasama ili napisem ponesto za svoje potrebe. Ako neko ima neke savete ili zeli da podeli svoja iskustva, neka slobodno uskoci sa primerom. |
pa meni se cini da ako su ti php skripte takve da mozes da ih generises, onda nema potrebe da imas zasebne (generisane) skripte, nego samo jednu glavnu skriptu kojoj ces da menjas parametre...
|
I ja za bazu koristim ADOdb (za prostije projekte ADOdb Lite)
Trenutno koristim Smarty, al bi voleo da se bacim na MVC, sprecava me samo manjak vremena za ucenje... |
Ja imam svoje razradjene i proverene klase koje sam pisao godinama za razne projekte i samo njih koristim. Jedina je razlika da li cu da koristim smarty ili ne.
I kod cistog php postoji nekoliko metoda rada, jos nisam odlucio koja mi najbolje lezi jer i to zavisi od tipa projekta. Poslenji sajt koji sam odradio je ceo je jednom fajlu, + .htaccess i mnogo include. Trudim se da vece html blokove cuvam kao html, dako jedan ili 2 reda html-a obicno radim sa: echo "<div id=blabla>".$test."</div>"; I jos uvek su mi svi projekti kompatibilni sa php4 (osim par sitnih izuzetaka) |
Citat:
Elem, procitavsi clanke o MVC-u http://www.onlamp.com/pub/a/php/2005...mvc_intro.html i http://www.onlamp.com/pub/a/php/2005...ontroller.html rekoh da se bacim na izucavanje MVC-a. I, cini mi se da sam uhvatio odakle treba da krenem, ali nikako da napravim nesto... Postoji gomila MVC Frameworka, ali su svi PHP5 specificni. Jedini framework koji je PHP4 specifican je Phrame. I taman da pocnem da ga ucim, likovi izbacili v3 koja je "E do mojega"... So, ima li neko iskustva sa nekim MVC Framework-om? |
Citat:
Ja koristim sopstveni MVC framework (klasičan MVC, Propel i par trikova pokupljenih od Ruby on Rails, modularan - stvarno povećava produktivnost). Može se opisati kao križanac RoR i Symfony frameworka sa modulima :D MVC je deifinitvno pravi izbor za sve veće od prosečne news skripte. MVC može da bude implementiran jako jednostavno, čak i u PHP4 - da radi brzo, da su aplikacije jednostavne za pravljenje i održavanje. PS: Razlog zašto je ogromna većina frameworka PHP5 specifična je u tome što su programeri koji koriste OOP za kompleksnije modelovanje aplikacija odavno migrirali na isti. Jako malo ljudi za koje se može reći da su PHP gurui koristi PHP4 kao primarnu razvojnu platformu. |
Jedno pitanje oko MVC kad je vec krenula prica u tom smeru...
Imam malih nedoumica oko View-a, jer bi mi se jako dopalo da ga skroz zatvorim u templejte endzine (a Kontroler da mi bude u php skripti, pa da budu bas razdvojeni). Ali opet od View-a se ocekuje da on sam trazi od Modela sve podatke koji mu trebaju, a nije mi zgodno da mi se u templejtima pojavlju pozivi funkcija kao moj_model->selektuj_blogove ili nesto slicno, jer one ne prikazuju same podatke nego ih samo spremaju da se prikazu (urade SELECT i vrate rezultate recimo). Ja bih da mi u templejtu bude samo funkcije koje nesto ispisuju, a da se detalji oko komunikacije sa modelom sklone iz templejta. Ali to onda opet znaci da mi se View logika mesa u skripti sa Kontroler logikom. Kako vi to organizujete? |
Tehnički, klasičan MVC (pričamo o SmallTalk definiciji istog) nije preterano primenljiv na webu jer je http connectionless te se neke bitne stvari vezane upravo za Views ne daju primeniti.
Malo mi je kasno (ili rano) pa ne mogu naći direktan link - ono što te interesuje je "MVC 2" (tako ga je Sun krstio), na netu možeš naći i više nego što želiš o istom ;) Mada ti savetujem da kreneš od www.sun.com |
mislis na Javin Model 2, znam ja za to...
procitao sam dosta teorije o tome, nego mi malo fale tudja real-life iskustva oko najprakticnijeg pristupa, zato sam pitao... Nedavno sam gledao Cake framework i recimo oni ne implementiraju MVC kako treba, jer kod njih kontroler prikuplja podatke pa ih daje View-u na koriscenje. Takav pristup mnogo direktnije odgovara kombinaciji php + templejt endzine (php je kontroler, a templejti su view), ali to nije onda nije pravilan MVC model. Inace jako puno ljudi na netu potpuno pogresno tvrdi da je to MVC (u masi tutorijala to mozes da procitas) i koliko sam video nekoliko mainstream framework-a koristi bas takvu "nepravilnu" implementaciju.. Pretpostavljam da se u MVC insistira da View uzima sam svoje podatke od Model-a sa razlogom, valjda da bi se izbeglo da promenom View-a mora da se menja i Kontroler. Medjutim to je ok za klasicne aplikacije koje cele rade programeri, pa nije strasno ako ti u View-u imas par upita nad bazom, ali meni to pravi problem sa dizajnerima, jer ne zelim da oni osete rad sa bazom. Idealno bi bilo da oni mogu samo u templejtu da kazu: prikazi mi taj podatak i to je to, bez SELECT-FETCH-PRINT medjukoraka. Ali takodje bi bilo super da cisto iz templejta moze da se pridje svim potrebnim podacima, bez potrebe da ih ja unapred dovlacim iz Modela u glavnom php kodu. |
Statika?
PHP kôd:
PS: Da li sve mora (može?) da bude po knjizi? |
^^ niko ne kaze da sve mora po knjizi, ja sam uvek za prakticarski pristup...ali mislim da je glupo hvaliti se da radis po nekom standardizovanom teorijskom principu, a onda ga odraditi na svoju ruku (govorim o Cake). Nisu pametni ljudi smisljali 20 godina MVC takav kakav je, bez razloga..
|
Citat:
Kao sto gore neko rece, nije bilo moguce preslikati original MVC (Smalltalk) u web okruzenje (model i controller su na serveru, a view na client-u), pa su nacinjene neke korekcije, odn. model ne obavestava vise view da je doslo do promene stanja, vec to ide preko controllera (Action-a). |
moje znanje o MVC i Modelu 2 je pomalo sa faxa, iz par knjiga o Javi i par clanaka sa Wikipedie, tako da ne mogu da tvrdim da sam neki poseban poznavalac niti sam se udubljivao u temu do sad, pa sto rece Djole: ako su mene lagalili, lazem i ja vas :D
moguce da oni nisu lepo objasnili (clanak na wikipediji bas koristi web kao primer, ali objasnjenje MVC je klasicno, isto kao po knigama, znaci View poziva Model, Kontroler poziva i Model i View, Model cuti i smrdi (i registruje callbacks po potrebi)) Jedna opaskica: view nije na clientu, odnosno bitan deo (logika) nije, vec je u php-u ili Smartiju ili kako vec odlucis da generises html...ako ne racunamo na javascript, naravno... jako me zanimaju prakticne posledice upotrebe jedne, odnosno druge varijante MVC-a, ako je neko potkovan teorijski i prakticno oko ovoga...Sta je po vama flexibilnije, lakse i brze za napraviti, i naravno efikasnije ? (mislim da je to dobar redosled prioriteta, bar za mene...) |
View treba samo da prikaze podatke korisniku i ne petljati ga u logic, a na controller-u je (Model 2) da mu dostavi te podatke ("Controller pushes information into the View"), koje ce ovaj da sklopi i da browseru.
Znaci view nije neki objekat koji ce biti obavesten o promeni(recimo, tesko ili nemoguce da bi izveo Observer obrazac), vec strana (template) koja se iznova renderuje nakon zahteva klijenta. (u tom smislu je na klijentu, na drugom racunaru). Sad tu dolaze i novi koncepti, kako bi web development lici sto vise na standardni razvoj aplikacija, takozvani "component-based frameworks" - JSF, ASP.NET, Tapestry... i tu se koristi princip "View pulls information out of the Model". Evo i link na chapter iz jedne knjige: http://jerry.cs.uiuc.edu/~plop/plop2...hardson0_3.pdf |
hvala na linku, pogledacu :)
|
malo iz formalina, ali naisao sam na detalj koji bih volio razjasnit.
sto rece ivanhoe, na raznim mjestima razne definicije i pogledi. jel se iskristaliziralo na kraju: kako se generira view? da li view 'zove' model za podacima vezanim uz prezentaciju ili model dodjeljuje vrijednosti npr. template sistemu i time view postaje potpuno neovisan? konkretno, recimo da imamo smarty kao template engine, nije li logicno da svaki modul u svojem model dijelu radi smarty->assign() njemu bitnih varijabli + sto eventualno odredjuje koji glavni template ce se koristiti, controller radi finalni smarty->display() i time view ostaje potpuno pasivan? |
Kontroler je spona između viewova i modela. Ako imaš $smarty->assign() u modelu nešto ne radiš kako treba ;)
Evo ga jedan konkretan primer gde mislim da je odvajanje dobro urađeno: PHP kôd:
PHP kôd:
|
sorry, neprecizno pricam...
u sustini controller ima funkciju/objekt koji radi smarty->assign() na osnovi varijabli dobivenih od modela, jasno. to za ovu opciju potpuno pasivnog view-a. dakle, to je pravilno s aspekta MVC? |
Parče koda bi pomoglo ;)
|
nema konkretnog koda jer ni ne pitam u vezi niceg konkretnog sto vec razvijam, tek sam u fazi smisljanja sheme u glavi :)
a u tom smisljanju, javila mi se upravo ona dilema koju je ivanhoe ranije ovdje opisao: Citat:
covjek za prezentaciju u kontroleru koristi: Kôd:
$presenter = FR_Presenter::factory( ali sad vec sirimo pricu mozda malo previse. sustina mog pitanja je bilo bas ovo (boldano) iz ivanhoe-ovog citata: pita li view od modela podatke ili je controller taj koji na osnovi rezultata modela salje podatke viewu? prosto kako je po PSu? :) |
Ne vidim ništa loše u tome da se u view-u pozivaju metodi modela, dokle god si ti pozivi tiču izvlačenja i prezentovanja podataka. Ako ih koristiš za nešto drugo (tipa osvežavanje sesije, modifikacija ili brisanje vrednosti itd) tome nije mesto u view-u (duh!).
U gornjem primeru getUsername() može da bude prost accessor, a opet iza njega može da se krije nešto mnogo složenije. Koga je briga dokle god dobijamo očekivani rezultat. Stvari bi bile izuzetno loše kada bi u viewu imao nešto tipa: PHP kôd:
|
ma to je jasno ;)
[iako, tnx na volji da se bude jasan, svakako] |
Dizajneri ZendFramework-a su malo zeznuli stvar oko MVC-a, pa su na kraju morali da isprave model. Detalji su na
http://devzone.zend.com/article/2072...e-ViewRenderer Controller - setuje podatke dobijene iz Model View - radi samo "glupu" prezentaciju |
a evo i necega sto nisam mogao da nadjem kad mi je trebalo
cake lifecycle http://www.cakecollab.org/lifecycle.png |
Citat:
Inace slazem se sa Ilijom u pogledu View dela MVC strukture. Dok god ne menja stanje aplikacije i samo prezentuje podatke nema nikakvih problema sa pozivima bilo direktno modela bilo akcija kontrolera koji na neki nacin komuniciraju sa modelom. |
Citat:
|
Nije objekat već klasa sa par statičkih metoda. Sama klasa se nikada ne instancira jer potrebe za instancom nema.
Funkcija findAll() vraća niz objekata. S druge strane findById() vraća samo objekat koji odgovara prosleđenom ID-ju ili NULL ako ga ne nađe. |
Vreme je GMT +2. Trenutno vreme je 02:05. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.