PHP Stilovi pisanja aplikacija (Best design practices)

[ivanhoe]

^^ 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..

[andrej]

Originalno napisao ivanhoe

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..

Nisam gledao Cake i kako su oni to odradili, medjutim to i jeste pravilno, ne po MVC-u, ali po Web MVC-u (Model 2) da.
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).

[ivanhoe]

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
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...)

[andrej]

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

[ivanhoe]

hvala na linku, pogledacu

[dee]

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?

[Ilija Studen]

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:

class SomeController {

  function index() {
    $this->smarty->assign('users', Users::findAll());
  }

} 


Gde kasnije u templateu imaš nešto tipa:

PHP kôd:

{if $users}
<ul>
{foreach from=$users item=user}
  <li>{$user->getUsername()|clean}</li>
{/foreach}
</ul>
{else}
<p>No users here</p>
{/if} 


[dee]

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?

[Ilija Studen]

Parče koda bi pomoglo

[dee]

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:

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?

citam po netu razne primjere, npr onaj koji je vec naveden -> http://www.onlamp.com/pub/a/php/2005...ontroller.html

covjek za prezentaciju u kontroleru koristi:

$presenter = FR_Presenter::factory(
                                  $instance->presenter,$instance
                              );

                              if (!PEAR::isError($presenter)) {
                                  $presenter->display();
                              } else {
                                  die($presenter->getMessage());
                              }

gdje u samom dijelu odabira template engine-a nije ogranicen samo na smarty.

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?