Witam
Pytanie dotyczy dobrej praktyki w stosowaniu MVC a dokładniej:
a) widok - czy powinien zawierać elementy logiki - np: kontroler przekazuje do widoku dane -> widok sprawdza uprawnienia lub na podstawie uprawnień renderuje część danych (do których user ma uprawniania ) a resztę pomija ? Czy może powinno to wyglądać tak że kontroler przekazuje do widoku tylko te dane do których user ma uprawnienia a widok jakoś musi sobie poradzi z ewentualnym brakiem kompletu danych.
w frame-workach php opartych o MVC przyjęło się że widok to zazwyczaj kod html. Czy dobrą praktyką będzie tworzenie widoków także dla metod które nie kończą się wyświetleniem strony ? Na przykład gdy wchodzimy pod jakiś URI to kontroler uruchamia metodę renderującą (zazwyczaj html) ale gdy strzelamy pod URI ajaxem to czy powinien istnieć specjalny widok zwracający json czy wystarczy w kontrolerze echo json_encode($output);
a) Bardzo często tak się robi choćby w blade i laravelu (dyrektywa @can).
b) Tutaj albo odpytanie powinno iść do API, albo większość rozwiązań oferuje metodę typu disableLayout która automatycznie wyłącza renderowanie widoku z plików.
viking - dzięki za odpowiedź ale :
class Test { public function get_dane() { $imie = 'Jan'; http://www.php.net/echo $imie; } }
class Test { public function get_dane() { $imie = 'Jan'; $this->render('plik_widoku', $imie); } } plik widoku if( http://www.php.net/isset($imie)) http://www.php.net/echo $imie;
Zwróć to co ma dostać Ajax i olej. Jeśli oczekujesz HTML to wywal HTML, jeśli JSON to JSON. Nie ma sensu na siłę sztucznie kombinować.
Raczej nie powinieneś przekazywać danych do których użytkownik nie ma uprawnień. Jeśli jakimś sposobem się wyświetlą to co wtedy? Zawsze można podzielić szablony na mniejsze fragmenty i w nich sprawdzać dane uprawnienia.
A kto powiedział że ma być jeden kontroler? Może być jakiś ogólny oraz np JsonController. W przypadku ajaxa odpowiedź może być dowolnego typu json, html, xml dlatego nie ma jednoznacznej odpowiedzi co konkretnie stosować. Możesz mieć jakiś system szablonów który świetnie radzi sobie z XML i czemu miałbyś rezygnować z niego, ale może to być prosta odpowiedź gdzie nawet sam kontroler wygeneruje te kilka linijek kodu.
a. Bezpieczniej gdy kontroler generuje tylko te dane, które są potrzebne. Czyli np jeśli wykryje że użytkownik nie powinien czegoś zobaczyć, to tych danych nie przekazuje do widoku. Lub opcja druga - wybiera inny widok, który tych danych nie renderuje w ogóle.
b. Żeby nie powielać kodu to jeden kontroler będzie ok, wystarczy w nim sprawdzenie typu isAjax() i zwrócenie samych danych, a w przypadku zwykłego requesta renderowanie widoku.
Ok dzięki za odpowiedzi.
To mam jeszcze inne pytanie. Gdzie się powinno sprawdzać (czy w modelu , kontrolerze czy widoku) uprawnienia przy zapisie i odczycie? Czy te schematy poniżej są poprawne ?
Zapis
Z formularza dane trafiają do kontrolera , kontroler wczytuje model -> model waliduje dane i sprawdza uprawnienia czy zalogowany user może zapisać te pola do bazy i zapisuje tylko te do których user ma prawo
Odczyt
a) Kontroler wczytuje model -> model odczytuje dane z bazy (wszystkie pola, po prostu wykonuje zapytanie bez sprawdzenia uprawnień)-> kontroler przekazuje dane do widoku -> widok sprawdza uprawnienia i renderuje tylko te pola do których zalogowany user ma prawo np IF (access ($pole_x) ) echo 'input...
Kontroler wczytuje model -> model (sprawdza uprawnienia) odczytuje tylko pola do których user ma prawo -> w widoku jest seria IF sprawdzająca IF(isset( $pole_x) ) echo 'input...
c) inne rozwiązanie
Jako, że w aplikacjach webowych bliżej jest do MVP niż do MVC ja jestem za tym, żeby to kontroler kontrolował dostępy, rozporządzał danymi, był punktem styku pomiędzy danymi a ich prezentacją.
Tym samym:
Zapis - dane z formularza trafiają do kontrolera, ten sprawdza czy użytkownik na wystarczające uprawnienia do zapisania tych danych i jeśli tak to wczytuje model i zapisuje dane.
Odczyt - kontroler sprawdza uprawnienia użytkownika, wczytuje model (czasem sprawdza uprawnienia po wczytaniu modelu i pobraniu danych) jeśli użytkownik ma do nich prawo, albo do części z nich to tworzy odpowiednie zmienne, które przekazuje do widoku do wyrenderowania. Kwestia ifów w widoku jest moim zdaniem zależna od projektu, czasem nie warto duplikować widoków tylko po to, żeby wyświetlać w nich wszystko co przekaże kontroler. Lepiej mieć kilka ifów i re-używać widok w kilku miejscach. Czasem lepiej i wygodniej mieć 1:1 - wszystkie dane przekazane do widoku są wyświetlane, jeśli mamy inny poziom uprawnień, inne dane do wyświetlenia - stosujemy inny widok. W czasach twiga i fajnie rozbudowanego dziedziczenia / bloków / makr - można to fajnie zorganizować bez zbędnego duplikowania kodu.
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)