Ajd ovako, ja sam vec pisao o tome, ali kad vec vuces za jezik:

Programiram u PHP OO, prebacujem sve sto mogu u PHP5 zbog bolje podrske XMLu. Pristup mi je sledeci:

1. PHP klase za generisanje XML dokumenata
2. XSL za "stilove" (XHTML, RSS, WML,...) :)

Napomena u 1:

U vecni slucajeva dokumenti odrazavaju neku tabelu, upit, ... i lako je napraviti XML dokument na osnovu rezultata. Ja sam to skroz banalizovao i napravio klase koje transparentno preslikavaju redove u XML (tag = ime koline). Ono sto je zanimljivo je pomiti tabelarnu stukturu SQL rezultata i ugnjezdenu strukturu XMLa, ovo sam uspeo da resim sa par rekurzivnih funkcija za genrisanje XML-a iz SQL rezultata, no nisam zadovoljan kontrolnom strukturom u ovom procesu.

Razvio sam klase koje prave genericke forme za unos podataka.

Mozes pogledati kako sve to izlgeda u alpha fazi na http://sourceforge.net/projects/upxx-framework, posto nije bilo interesovanja nisam objavljivao novije verzije. Ako nekog interesuje ovaj pristup voljan sam da zajedno radimo na PHP engine-u.

poz, utvara

Mislim da je moj stil kodiranja dosta slican ovome pod 4), tj. ovo sto si opisao na kraju prvog posta.

Elem koristim Smarty i neku moju lite klasu oko MySQL-a.
Osim sto "command" obicno zovem "action" to je to.

Znaci u 'osnovnom' skriptu pokupim 'zahtev korisnika' obicno u jednom switch-u odgovorim na zahtev pozivanjem metode klase i eventualno sa jos malo koda, tako da mi taj php obicno dodje oko 100 linija. Svaku klasu smestam zaseban fajl.

Jedina bitna razlika je sto volim OO, tako da su tvoji:
inv-new(), inv-edit()...
kod mene metode klase, to mi povremeno pojednostavljuje i rad sa MySQL-om, jednostavno nasledim db klasu i teram...

Tako da imam nekoliko klasa koje su, manje vise, prilagodljive.
Tako da galerije slika, kataloge proizvoda, jednostavnije sisteme vesti i slicno mogu da ispisem vrlo brzo. Pager i slicno ne treba ni nesto prilagodjavati to radi.

Meni je to ok i za male projekte, tj. u PHP-u uglavnom i radim samo male projekte.

Ako bi mogao da pojasnis pojam 'lelemuda' mozda bi bilo zanimljivo...

ja se jos uvjek borim da predjem na OO..

inace koristim smarty (tek poceo...), logika je sledeca:

za akciju koristim promjenjivu "put". prvo onda provjerim ako u include diru postoji $put.".php", ako ima ubacim ga(on puni $sitedata[] specificnim podacima za taj $put) a zatim u indexu pokupim sve podatke i ubacim u smarty. nakon toga pozovem smarty sa index.tpl u kom pozivam header.tpl ($put).tpl i footer.tpl

kao sto rekoh ovo je staro 3-4 mjeseca i jedini projekat mi je moj wap sajt, na kom pokusavam da se dobro istreniram...

naredni korak mi je ucenje c++ a samim tim i OOP koje cu naravno prvo da istreniram u php-u

Evo moje evolucije MVC-a:

--------------
Model: tu spada obrada poslovne logike i perzistencija. U pocetku sam koristio razne varijante ActivRecord implementacije prepisano iz knjiga, web sajtova.

Onda sam poceo da razvijam svoju tako sto npr. autogeneratorom izvucem iz baze tabele, zatim formiram klase sa geterima i seterima i metod getFieldDescList() koji mi vraca niz sa nazivima i tipovima polja. Taj niz koristim prilikom generisanja CRUD procedura. Zatim formiram CriteriaClass za formiranje objekta sa kriterijumima koji prosledjujem dalje nekom getSelection(Criteria $objCrit)... onda sam otkrio propel.

Posle putesestvije kada sve saberem i oduzmem, zakljucujem vremenom da su stored procedure bolje resenje, jer vremenom objektni model "zagadim" custom sql-om i to vise ne spada u propisni domain-design...

SP mogu da pozovem iz nekog drugog programa, nije mi problem ni sto skoro za svaku tabelu imam po 4 procedure (koje se lako generisu, a i pronadju ako se sledi konvencija dodeljivanja naziva, cuvanje u fajlovima grupisanim po direktorijumima).

A i nisam naleteo jos na slucaj toliko slozen da mi je bolji cist OO, nego relacioni model - mozda bi u tom slucaju razmislio o uvodjenju prolog-a kao resenju :).


--------------
View: globalno koriste se dva pristupa Template View i Transform View (i two step View) prema M. Fowleru. Licno se opredeljujem za Template View, zato sto mi je laksi obican HTML nego xslt, a i druga osoba odradi sve u drimviveru. Kada treba nesto za stampu css odlicno odradjuje posao, a i manje rada-kucanja je potrebno nego za xslt(fo).

Kao engine koristim cist PHP. U vju-u samo citam objekte tipa product->getName() ili promenljive (vec zasta se opredelim), i vju ne sadrzi nikakav kod koji upisuje u bazu, ili manipulise poslovnom logikom. Takodje ne mesam php i html tipa echo "neki html tag, malo php, zatvori tag".

Koristim alternativnu sintaksu za kontrolne strukture npr. foreach:, koji mi daju citljiv kod, ali alt sintaksu koristim samo u delu vju-a, u ostalim delovima koristim normalnu {} sintaksu. I nisam primetio da web dizajneru smeta PHP.

--------------
Controller:
Rucno napisani Page Controller zavrsava 90% poslova. Ne vidim dovoljan razlog da koristim Front controller, ako mi valjana super klasa za PG zavrsava posao.

Takodje nije bauk ni spojiti PG sa vjuom u isti fajl. Ili jos prostije koristiti proceduralni pristup i na vrhu svakog vju-a inkludovati neki config, authorise, filter_post i sl. U 99% jedan kontroler ide na jedan vju, pa se stoga ne dobija nesto posebno razdvajanjem, osim sto je mozda teze testiranje. Najvaznije je razdvojiti model od prezentacije.

Zdravo svima,

Mi u firmi Logik d.o.o. (www.logik.co.yu) koristimo FastTemplate koji smo modifikovali u vise segmenta kako bi radio brze. Bilo kakvo mesanje PHP i HTML koda je najkraci put u propast. Sa druge strane protocnost u kreiranju stranica koriscenjem bilo kole template klase je, bar po nama, imerativ. Cim odredjeni deo stranice bude zavrsen, treba ga poslati korisniku. "Muljanje" cele stranice po memoriji web servera ce sigurno dovesti do nepodnosljivo losih performansi cim sajt bude postao malo poznatiji, a mozda cak i pre toga.

Sa visegodisnjim iskustvom u razvoju web aplikacija razlicite velicine, kompleksnosti i namene, odlucili smo da dalje unapredimo nacin krairanja stranica. Razvili smo posebnu klasu koju zovemo jednostavno page. Nasa page klasa se i dalje oslanja na FastTemplate, s tim sto se u okviru HTML koda templatea mogu definisati:
- slotovi - mesta gde je moguce ubaciti dinamicki sadrzaj
- izvrsni (execution) blokovi - delovi HTML koda koje obradjuje funkcija iz nekog modula

Slot omogucava da se u HTML kodu definisu mesta na kojima ce se umetati sadrzaj iz funkcija odgovarajucih modula. To je veoma korisno ako se isti glavni dizajn koristi za veci broj stranica web aplikacije, gde imate mesto (slot) za navigaciju u levoj koloni i mesto za glavni sadrzaj u centru stranice. Pre nego sto se procesiranje stranice zapocne od strane page klase, za svaki slot moramo da definisemo module i njihove funkcije koje ce ubacivati svoj sadrzaj.

Izvrsni (execution) blokovi se oznacaju posebnim markerima i signaliziraiju page klasi da za obradu HTML koda izmedju markera iskoristi funkciju nekog modula. Naziv modula i njegova funkcija se mogu zadati u samom HTML kodu kao deo markera, ili se simbilickom imenu moze dodeliti modul/funkcija u PHP kodu. Ovakav pristup koristimo veoma cesto kada u zajednickom templateu za sve srtanice imamo dinamicke elemente, kao sto je dinamicka navigacija, kratka informacija o prijavljenom korisniku, kratka informacija o narudzbini.

Page klasa pokusava da citav proces kreiranja ucini protocnim, tako da se HTML u toku obrade salje korisniku cim je to moguce.

Pozdrav,
Nikola

Prvo jedan komentar. Prvo i osnovno nauci OOP u c++ ili pak javi, zavisi da sta te vise interesuje. To odradi ako mozes sto pre. U principu OOP u php-u nije isto sto i u javi ili pak c++, skoro je ista sintaxa ali razlozi koriscenja su malo drugaciji. Bar ja do sad nisam imao priliku da istu klasu koristim i u c++ i u php. Mozada date klasu ali i nju treba mnogo modifikovati da bi radila u php kodu.
____________________________________________________________________________________________________
Inace moja praksa je do skora bila da mesam php i html kod. Onda sam otkrio smarty i posle mnogo protivljenja da predjem na isti jednom prilikom sam probao i sad gledam da samo tako i radim.
Inace pravim klase i za najmanje sitnice, jer mi mnogo olaksavaju zivot
Stil pisanja koda:
1.) Prvo i osnovno napravim konstrukciju foldera za php kod.
root
Skelet
- header.php
- banner.php
- leftFlag.php
- midleFlag.php
- rightFlag.php
- copyright.php
- footer.php
Security
- DbManager.php
- SecurityClass.php
Classes
- ....
Images
- ....
Logs
- ....
2.) Kad pisem php kod gledam da ima sto manje linija koda. Da klase imaju intuitivna imena kako promenljivih tako i metoda. Kad pisem kod pokusavam da ga uprostim do krajnje mere, koristim sve fazone koji su mi dostupni tipa
resenje = ako?primer1:primer2=resenje3;
Komentarisem jako mnogo, skoro svaku znacajniju linju koda . Kako bih znao kasnije kad pogledam taj program sta sam radio.
Celine odvajam upecatljivim komentarskim linijama tipa /*_____________________________________*/
dok funkcije odvajam /*>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>*/
Praktikujem da na pocetku strane napisem mali komentar koji se odnosi prvenstveno na datum pravljenja stranice. npr


/*///////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
/* Class admin
It is free open source class, designed to manage and configure administrators and their privileges.
If any mistake or wrongly written part of code is found please email me to change mistake.
Also any help to improve this class Is desirable.

Written by: Boris Vujicic (goodfather )
Date: 26.04.2007
Email: [email protected]
*/
/*///////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/

Sama stranica je organizovana na vise upecatljivih celina.
0.) Komentar o klasi
1.) Includujem security i startujem sessiju. Zatim vrsim proveru usera, ako je proslo ok onda includujem ostale fajlove.
2.) sam php kod koji stranice treba da izvrsi.
3.) pomocne funkcije

3.) Za svaku stranicu pisem odgovarajuci log fajl u kome navodim sta ta strana radi i koje podatke prosledjuje dalje.
Posto sam poceo da koristim smarty dacu jedan primer loga za smarty dizajnera. npr

/*///////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
Log file for verify.php
Condition of all messages is empty if there is no error.

---------------------------------------------------------------------------------------
0 message[0]
false = Error 0.
Bad verify number.

1 message[1]
false = Error 1.
Bad Pass entered. No match.


2 message[2]
false = Error 2.
Bad userNamem entered. No match.


---------------------------------------------------------------------------------------
register
If everything vent on correctly register will be set to ON otherwise to OFF.
---------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------
verify
Verification number.
---------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------
curentPage
It sends page name.
---------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------
username
If user is LOGGED ON it will have his name as data,
otherwise it will contain guest.
---------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------
status
If user is registered it will be set to 1, otherwise to 0.
---------------------------------------------------------------------------------------

Object send to user:
_________________________
/ type | name \
|----------------------------|
| string | register |
| array | messages |
| int | verify |
| string | curentPage |
| string | username |
| int | status |
\________________________/

/*///////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/

Tako otprilike organizujem stranicu i sajt u celosti. Nadam se da vam je ovo nesto pomoglo. kao ima neko neku primedbu ili komentar, plzzzzzzz post it. Pozdrav

Komentar na prethodni post:

- Nije loše, samo još nauči da koristiš PHP documentor pravilno i držiš se njegovog (inače standardnog) načina komentarisanja klasa, metoda i promenljivih i imaćeš 100% jasan kod.

Komentar na druge postove:

- Primećujem da većina ljudi ovde koriste Smarty, koji je u poslednje vreme postao gigant i po mom mišljenju prestao da bude "mali, fleksibilan, upotrebljiv template engine". Za neke manje projekte, dovoljno je iskoristiti i neki drugi, manji i optimizovaniji engine, kao npr: http://www.phpxtemplate.org/HomePage - koji ima drugaciju logiku, ali je veoma upotrebljiv za manje stvari

- Po meni, best practice u programiranju je pisanje samo-dokumentujuceg koda, koji kada se provuce kroz PHPdocumentor, sam izgenerise dokumentaciju.
Probajte, nije tesko. Tako generisani kod takođe može biti pretvoren u UML diagram, kao kod PHP2XMI alata.

- Takođe, PHP5 objektni model je dooosta uznapredovao u odnosu na OOP model iz PHP4, tako da tvrdnja iz prethodnog posta prosto-ne pije vodu. Jeste, PHP i dalje ne podržava multiple inheritance, ali 95% klasičnog OOP "oružja" je tu-uključujući i polimorfizam kao, po meni, najjače.

- PHP debugger i profiler, kao deo razvojnog alata je neophodan; Preporucujem Xdebug i WinCacheGrind/KcacheGrind kombinaciju. Ovo se ne odnosi direktno na stilove pisanja aplikacije, koliko na olakšavanje razvoja.

- Mock objects i PHP unit testing - vredi probati, naročito ako je veliki projekat u pitanju (omogućava testiranje objekata pojedinačno, izolovano).

- Dve reči: Design patterns. Naučite šta je factory, Singleton, Adaptor, Template, Active record, Table Data Gateway, MVC pattern, verujte, nećete zažaliti. Kada jednom krenete da pišete aplikaciju koja je deo stvarno velikog projekta videćete koliko to štedi vreme.

Ima tu dosta sitnica koje treba da se navedu, ali ovo su ključne stvari.

Ako neko misli da ne može da se napiše ozbiljna i robusna PHP aplikacija, neka pogleda ovo:

http://www.niallkennedy.com/blog/uploads/flickr_php.pdf

Pozz

heh dovoljni je samo ovo http://www.facebook.com/home.php ~40M usera mesecno
ako znate sta je PHP easter eggs [http://shiflett.org/blog/2006/feb/php-easter-eggs]
http://37signals.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 ovu su izmislili ruby on rails a koriste PHP ???
http://basecamphq.com/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 navodno RnR

moj point je da je PHP dovoljno evoluirao da postane odlicna/flexibilna/skalabilna ... platforma za web aplikacije.

OO u PHP-u je odlicnan potez Zend-a , koristio sam Zend Framewrok za sajt-ove za kompanije u kojoj radim al ZF je dosta spor ...
Za privatne potrebe koristim svoj OO framework, mali ali explozivan, baziran na ZF layoutu klasa kao i templejta i controllera

po meni Best design practice je
1. imate config file koji mapira odredjene URL-ove prema controllerima npr


u Controleru odradite pozive biblioteka spremanje podataka za views/template

kad se sve pripremi pozovete TPL koji po mojoj toploj preporuci treba da bude PHP template syntax (malo ljudi zna za ovo )

Zasto PHP kao tpl engine
1. nema potrebe za ucenjem jos jednog TPL jezika
2. Sve sto vam padne na pamet da odradite u templejtu sigurno vec imate u PHP-u
3. Brzina, posto svaki TPL engine mora da isparsira TPL syntaxu da popuni TPL za podacima iz PHP-a i tek onda printra HTML

primer coda



Po meni ako se pridrzavate pravila da sve podatke pripremite u Controllerima TPL u PHP je poprilicno cist i razumljiv uz to i brz

Samo male napomene...

Da, ali facebook je razvio svoju PHP ekstenziju (znači C kod) u kojoj je uvukao mozillin kod... Tako da to malo odskače od "nas običnih smrtnika". I dalje se slažem da PHP predstavlja prilično napredan, popularan i moćan jezik relativno opšte namene. Mada mu je veooooma slaba strana podrška za Unicode.


Tačka 2. skriva opasnost od narušavanja principa podele odgovornosti (MVC), pa se mora gledati u strogoj vezi sa poslednjom rečenicom u gornjem citatu.

Veoma se slažem sa mikom u pogledu elemenata razvoja. Pored ovoga za samo upravljanje razvojem aplikacije bitni su i elementi radnog okruženja (IDE...). Recimo Eclipse + xdebugger za remote debugging.
Svakako u razvojnom okruženju podešavanja PHP (E_NOTICE, display_errors=on...), ali već odoh u drugu temu :)

Sve to stoji, ali ne treba zaboraviti da Flickr koristi PHP samo za UI, API i takve stvari, dok poslovnu logiku vrti u Javi...

Postovana gospodo :) ,

Vidim da je krenulo nasiroko da se raspravlja o OO Php-u i slazem se da je to izuzetno vazna tema od koje u krajnjoj liniji i zavisi organizacija projekta itd. sto je i osnovna tema ove diskusije.
Ali ne bih mnogo ulazio u OO jer za vecinu aplikacija (web sajtova) srednje velicine i kompleksnosti nije neophodno forsirati maksimalnu iskoriscenost objektno-orjentisane organizacije samog Php-a. Moze se videti recimo u opensource projektu Xoops kako se moze organizovati citav niz klasa i maksimalno iskoristiti OO php.
Dobar pregled kako organizovati framewrok moze se videti i kod Codeigniter ili Zend frameworka.

A sad da iznesem neka moja vidjenja u vezi organizacije projekta:

Pre svega mislim da je davno apsolvirano da treba odvojiti prezentacionu od upravljacke logike. Druga stvar, u pocetku su me naucili da je neki template engine bolje resenje od mesanja php koda i html-a pa se toga i drzim. Koristim smarty vec godinama, radio sam i sa nekim drugim ali Smarty je po meni neprevazidjen i najlaksi za upotrebu, neuporedivo je brzi za kodiranje od recimo FastTemplate-a. Sa druge strane, moguce je sesti i napisati neki svoj template engine (skup funkcija preciznije receno) ali mislim da je tu prihvatljivo preuzeti neki gotov, prouciti ga i koristiti.

Druga vazna stvar je koliko toliko organizovati framework (u punom smislu te reci : radni okvir) po MVC modelu. Ja koristim fusion box strukturu u osnovi (sve ide preko index.php) i tu mi je srz kontrolera, tu pozivam funkcije za kontolu pristupa, obradu pojedinacnih zahteva, generisanje stranice itd. Svi entitety, da ih tako nazovem, su organizovani po klasama, pa tako za user-a imam klasu class.user.php, za razne forme recimo class.form.php itd. te klase sadrze osnovne add/get/update/delete funkcije kao i sve ostale vezane za taj entitet. Za obradu pojedinacnih zahteva tu su php fajlovi kao npr. user.php , page.php itd i oni vracaju kontroleru informacije o datom objektu i sta dalje sa njim.

REQUEST -> index.php -> poseban case u something.php -> index.php(function generate_view) -> tras HTML :)
(u najbanalnijem mogucem vidu opisa :))

Jos jedna stvar, koju praktikujem, je sto manja upotreba glomaznih tudjih klasa za sve i svasta. Koristio sam adodb za bazu ali sam to skroz izbacio i koristim native mysql funkcije. Gde mora mora a dge ne mora treba zaobici i sve svesti na sopstvenu odgovornost ali i potpunu kontrolu :)

Eto valjda neko bude u stanju izvuci nesto korisno iz ove moje price.

Pozdrav

Svako preporučam prijelaz na Objektno Orjentirano programiranje - velika ušteda vremena, puno veća preglednost, puno jednostavnije naknodno mijenjanje i sl. Svakako se ne treba toga bojati, treba iskoristiti sve što se nudi ;-)

Mislim da su se od 2008.e svi (ili barem vecina) okrenuli ka OOP-u :-)

ovo su lepi primeri lepog pisanja i dobro bi bilo da se svi toga pridrzavaju.
Drugo sto bih zelo je jedno pitanje:
Da li postoji funkcija ili neki nacin u PHP-u za pozicioniranje recimo slika
koje se koriste na veb stranicama, kao sto je to tag <DIV id=nesto>?
trajanovic

^Moderni dizajn aplikacija sve vise koristi MVC, tako da se izlaz (HTML) odvaja od ostatka aplikacije.
Sve prikaze treba resavati kroz templejte, a konkretan izgled putem CSS-a.

---

Vidim da svi lepo pisete u koriscenju OOP-a, mada postoji masa koja to nikako ne prihvata. Najspornija je "Drupal zajednica".
(kada neko insistira da mu se sajt uradi u drupalu, odlepim :))

Da, i uglavnom taj neprelazak na OOP opravdavaju istorijskim činjenicama, kako je core Drupala proceduralan, itd. A najsmešnije od svega mi je to što na Wikipedia-i piše da je Drupal MVC-based. Čak su ga stavili pod framework-e, evo dokaz: http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks.

Imam pitanje na ovu temu.
Moze li neko, neku malu aplikaciju (sa login,logout,session... ) da stavi (uploaduje za downoad) da malo "pokupim" zanat :D

Ja radim sledecim redom:
1. napravim dizajn (html+css)
2. stavim neke Smarty varijable u header (npr. pagetitle, users online etc.) i footer
3. isecem header,middle,footer
4. Napravim klase za sessiju, mysql.. itd. i smestim u /includes

Pa middle dalje radim i kopiram za svaku stranu...
Na pocetku svake strane, kreiram objekte od klasa include pa new... jelte.

Varijable pisem u stilu neka_varijabla, a klase "Klasa", a fukncije TamoNekaFunkcija().....

dakle?

Posto sam novi u php-u i ucim tek zamolio bi neke da mi objasne sta je
FastTemplate, Smarty, patTemplate, Flexy... ) MVC, php OO itd

Pogledaj ovde http://lmgtfy.com/?q=Smarty

Sve to što si nabrojao nije nešto što može da se shvati i nauči tek tako preko noći, a i kad bi ipak neko hteo da napiše nešto o svemu tome, bila bi to jedna jako velika poruka.

Što se template engine tiče, kreni sa nekim od tih što si nabrojao, svaki od njih ima dobru dokumentaciju, pogledaj neke primere, itd. MVC (Model View Controller) arhitektura je dosta kompleksnija stvar, eto taj template engine bi bio deo samo te arhitekture, tačnije, on bi bio to "V" u MVC. Za shvatanje celog tog koncepta je možda najbolje da uzmeš neku knjigu koja se bavi tom materijom, čisto da imaš i neki teorijski uvod u celu tu priču, a zatim i da probaš neki od brojnih framework-ova za PHP, jer se svi oni u principu baziraju na MVC arhitekturi.

A naravno, objektno-orijentisano PHP programiranje je preduslov za MVC. PHP manual je za početak pravo mesto za neke osnovne, a i naprednije stvari u OOP-u, u PHP jeziku.

Da se ubacim i ja:

radim iskljucivo OOP, koristim Doctrine, Smarty i moj kontroler. Moj savet je da klase ne koristis kao skup funkcija; objekat je tu nesto da uradi, a ne samo da drzi funkcije u sebi. Mozda ti ovo zvuci malo konfuzno, ali kad pocnes da koristis ORM, bice ti jasnije.

Skoro nijedna moja dinamicka funkcija ne zahteva parametre, sto i tebi preporucujem. Ako funkciji treba parametar, ona bi morala sama da se snadje.

Static metode koristi da dovuces instancu te klase; npr. Worker::getLogged() koristim da bih dovukao instancu logovanog radnika. Uzmi sledeci primer;



I ovo ce da radi. Ali korisnik jako lako moze da izmeni URL i da umesto 15, stavi 21 sto na primer ne bi smeo da uradi; zato ti odlucujes da napravis dodatnu zastitu. Metodu Article::delete(), prepravis na ovo:


(naravno, u klasi worker moras da napises i metodu canDeleteArticle)

Nadam se da si razumeo zasto je bitno da metode nemaju ulazni parametar. Article::delete() ce sam da se pobrine oko provere brisanja sto znaci da je mozes pozvati odakle god hoces, iz bilo kog modula ili instance neke druge klase.

Metode MORAJU biti kratke; vremenom ces shvatiti zasto, ali zasad mi veruj na rec. Ako metoda ima vise od 10 linija, znaci da nesto ne valja. Kod mene je prosek 4-5 linija, gornji primer je u stvari:


jer koristim nasledjivanje klasa u Doctrine-u.

Zasto je jos bitno da metode nemaju ulazni parametar:
Uzmimo opet primer Article::delete(); ako bi toj metodi dodao neki ulazni parametar (kazem, samo primer), onda bi svuda gde se ta metoda poziva morao da dodam slanje parametra. Neki drugi programer koji bi nastavio takav program bi sasvim sigurno ispizdeo u lutanju kodom. Naravno, uvek mozes da ostavis haos i da onda kupac tvog programa jednostavno mora tebe da pozove, ali mislim da tako nesto raditi uopste nije lepo. Veruj, ima ljudi koji hoce da plate vise ali da takav kod ne zavisi od toga hoce li programer biti dostupan i kasnije.

I jos nesto; ako planiras da budes dobar programer, batali dizajn. Kad god sam morao da radim i programiranje i dizajn, nista od ta dva nije valjalo. Pre 4 meseca sam presekao i rekao da tako vise ne moze; sad pisem veoma komplekse programe za 5 puta krace vreme, pri cemu je kod neverovatno kratak, brz, lako citljiv i prosiriv.

Pitanje o kome trenutno razmišljam: Zašto svi okviri i tekstovi sa savetima iz prakse koriste Router/Dispatcher i index.php kao jednu ulaznu tačku odakle se učitava odgovarajući kontroler? Onda pored rutiranja ove komponente implementiraju i druge mogućnosti veb servera kao što su dogovaranje o formatu sadržaja, jeziku...

Koja je prednost u odnosu na dizajn u kome je svaki kontroler nezavisan i iz svog konstruktora inicijalizuje sistem? Tada imamo više nezavisnih ulaznih tačaka, možemo neograničeno da ih skaliramo horizontalno po različitim serverima zajedno sa njihovim resursima, a ostatak posla oko rutiranja, dogovaranja i autentifikacije može da odradi i veb server, sigurno brže nego kada se to radi iz PHP-a.

Lakse je za odrzavanje koda, ako se ukaze potreba za korekcijom na ulaznom skriptu lakse je kad je to samo na index.php.

Jos jedan razlog, za jedan sajt na hostingu site5.com sam imao potrebe da korigujem php.ini da bi korektno radio, i u uputstvu nasao da je dovoljno u direktorijum postaviti svoj php.ini koji ce override-ovati default vrednosti, ali sam ga morao iskopirati u SVAKI direktorijum gde imam "ulaznu tacku" - hosting gleda ini samo u tekucem a ne i u roditeljskim direktorijumima. Nazalost taj sajt nisam radio u "Front Controller pattern" stilu.

Ulazna tačka uvek može u konstruktoru da pozove taj neki zajednički kod odakle može da se radi popravka. I ja sam do ovog sada projekta radio sa jednim index.php, međutim sada se razmišljam. Deluje mi daleko fleksibilnije da svaki kontroler bude nezavisna ulazna tačka.

Još jedna prednost jedne ulazne tačke je što kontroleri mogu biti van document root direktorijuma, ali i to lako može da se prevaziđe automatski generisanim ulaznim tačkama koje pozivaju kontrolere.

Pa zar to i nije slučaj kod većine framework-a? Ne znam samo šta podrazumevaš pod tim "inicijalizuje sistem"... Svaki zaseban kontroler, odnosno ta klasa koja ga predstavlja, je celina za sebe, u početnoj fazi dispatch-ovanja, odnosno nakon što bude "prozvan", može da vrši neku custom inicijalizaciju, pre izvršavanja konkretne akcije. Eto taj Front controller pattern, koji je uglavnom karakterističan za web aplikacije, definiše jednu komponentu koja je zadužena za prihvatanje svih zahteva. Samim tim, potrebna je samo jedna ulazna tačka, taj neki index.php. A kasnije, u zavisnosti od samog zahteva, instanciraće odgovarajuće kontrolere, kako bi na njih preneo nadležnost za handle-ovanje konkretne akcije.

Alternativa ovome bi bila upravo to što ti predlažeš - separacija sistema na pojedinačne ulazne tačke (PHP skriptove), pri čemu ja ne vidim benefite takvog pristupa, a pritom bi u takvoj situaciji sigurno dolazilo do ponavljanja koda, što je svakako loše.

Većina radnih okvira omogućava da do najsitnijih detalja custom-izuješ ceo taj "uvodni" proces, sa ciljem postizanja te potpune fleksibilnosti koju bi imao u slučaju zasebnih ulaznih tačaka.

Uzmi sledeci primer; kontroleri admin dela programa zahtevaju da administrator bude svo vreme ulogovan i to je prvo sto se proverava. Svi admin kontroleri nasledjuju neku klasu BaseAdminController koja radi sledece:

Na jednom mestu ces sve da postavis i proveris, tvoji kontroleri uopste ne moraju da se zezaju oko toga. Ali, ako ipak zelis neke custom varijante za svaki kontroler pojedinacno, samo ces u njemu napisati novi __construct() i to je to.

@mitke013: To što ti pričaš nema veze sa pitanjem, promašio si temu.

Neka imamo UsersAdminController extends BaseAdminController implements Controller. Umesto da postoji Dispatcher koji od index.php?q=usersadmin (uz kakav god url_rewrite) učitava UsersAdminController zamisli sledeće:


Dakle nema Dispatcher koda, ne postoji jedinstvena ulazna tačka. To su poslovi koje odrađuje veb server i to radi znatno efikasnije nego neki PHP kod. Sada BaseAdminController može da izgleda:


i admin/users.php:


Sada imamo fleksibilnost da admin/articles.php premestimo zajedno sa svim resursima na drugi server, da implementiramo dogovor o jeziku i sadržaju koristeći HTTP i koristimo sve drugo što veb server sam nudi zato što su pojedinačni kontroleri nezavisni skriptovi na serveru.

Ja pitam, koje su mane, pošto očigledno da svi okviri za koje ja znam koriste jedinstvenu ulaznu tačku? Nikola je rekao ponavljanje koda, ja ne vidim u primeru nikakvo ponavljanje. mitke013 nije ništa rekao, ali naterao me je da sastavim primer. Miroslav je pomenuo postavljanje podešavanja na nivou skripte/direktorijuma, nije nerešiv problem.

Pa u tom slucaju onda dispatcher ulogu ima rewrite engine web servera. Jer ako ides preko FrontController patterna, tj. sa jednom ulaznom tackom, tamo "dignes" aplikaciju, pa dalje aplikacija odredjuje na osnovu zahteva koja ruta treba da se dispatch-uje. A u ovom drugom slucaju, recimo .htaccess. Jeste rewrite engine brzi od gomile PHP objekata, ali opet, kako se meni cini, sa PHP-om dobijes lakse odrzavanje/podesavanje.