Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [Kohana] czy tak ma wyglądać model?
Forum PHP.pl > Forum > PHP > Frameworki
terabit
Witam,

tak sobie grzebie na forum, szukam różnych ciekawych rzeczy o kohanaphp...
no i znalazłem coś takiego: http://phpfi.com/327959 w temacie http://forum.php.pl/index.php?s=&showt...st&p=487669
i się zastanawiam czy właśnie tak powinien wyglądać model? Tyle ifów i nawet jakies komunikaty:
  1. <?php
  2. $message = 'Witaj '.$display_name.'<br/><br/> Zarejestrowa?e? si? w serwisie '.config::item('config.custom_page_domain').'. Aby aktywowa? konto kliknij w poni?szy link:<br /><br />'.html::anchor('authentication/activate/'.$activation_key, 'Aktywuj Konto').'<br /><br/>'.url::site('authentication/activate/'.$activation_key).'<br /><br />Wiadomo?? wygenerowana automatycznie. Prosimy na ni? nie odpowiada?.';
  3. ?>


Myślałem że takimi rzeczami zajmują się metody controllera...

Czy tak powinno się to robić?
LBO
Tak, to jest istota modelu, żeby chować implementację źródła danych. Większość frameworków źle pojmuję istotę M w MVC udostępniając ActiveRecord (Cake), ORM (Symfony) czy coś jeszcze innego (ZF) i wpajając, że tak powinno być.

Przeczytaj ten post ActiveRecord sucks, but Kore Nordmann is wrong, a dokładnie zrozumiesz o co chodzi.

Przytoczę tutaj jedno z moich doświadczeń.
Napisałem całkiem ciekawą aplikację dla małej budżetówki. Oparłem to o Agavi (gdzie Model jet interpretowany poprawnie) i całość operacji na bazie (Propel) zamknąłem w obiektach modelu udostępniając jedynie odpowiednie metody. Jak przyszło co do czego biedna budżetówka na serwer mogła dać jakiegoś stary Durona z 512MB (aplikacja wewnątrz sieci) - nawet nie wyobrażasz sobie jak łatwo i SZYBKO przepisałem większość modeli, by używało nie Propela (która jest trasznie pamięciożerny i dławił serwer),a czyste mysql_*

Mogę się spierać jedynie z komunikatami wewnątrz modelu, ale to juz zalezy od programisty, wazne, że ogólnie jest w porządku.

EDIT: Zapomniałem dodać, że owe przepisanie modelu odbyło sie bez najmniejszego tykania Kontrolerów/Akcji i Widoków.
bełdzio
jak dla mnie to powinno byc w widoku smile.gif

model -> dane
kontroler -> sterowanie
widok -> GUI smile.gif
LBO
Co powinno być w widoku?
bełdzio
sorki my bug smile.gif nie zobaczylem linkow tylko ocenilem ten kawalek kodu smile.gif idzie info do modka zeby wywalil moj post :-)
LBO
Cytat(bełdzio @ 11.08.2008, 23:11:06 ) *
sorki my bug smile.gif nie zobaczylem linkow tylko ocenilem ten kawalek kodu smile.gif idzie info do modka zeby wywalil moj post :-)


No to jeżeli już o tym mowa to ja takie komunikaty umieszczam w widoku.
W kontrolerze analizuje co zwrócił model np: jeżeli przy pobieraniu listy czegoś zwróci pusty wynik uruchamiam widok "NotFound" (w którym informacje już są), jeżeli coś jest to widok "List", jak rzuci wyjątkiem to na odpowiednia stronę błędu etc. Komunikaty w widokach, które odzwierciedlają naturę tych komunikatów.
terabit
Cytat(bełdzio @ 11.08.2008, 23:11:06 ) *
sorki my bug smile.gif nie zobaczylem linkow tylko ocenilem ten kawalek kodu smile.gif idzie info do modka zeby wywalil moj post :-)


hmmm

jak w widoku?
przecież komunikaty wyswietlamy jesli cos sie tam stalo...
wiec wedlug mnie pobinien byc w kontrolerze i przekazywany do widoku gdy bedzie taka potrzeba :]

---

LBO byłeś szybszy tongue.gif
właśnie o coś takiego mi chodziło
bełdzio
dokladnie o to mi chodzi smile.gif wszelkie komunikaty to kwestia kontrolera i widokow smile.gif
terabit
i jeszcze jedna sprawa:
zerknijcie tutaj:
http://forum.php.pl/index.php?showtopic=96...=0&p=487669

w modelu pętle?

i w ogóle to mi się coś nie podoba :/ czy to nie powinie być kontroler?
  1. <?php
  2. foreach($query as $row)
  3. {
  4. $this->session->set('isLogin', TRUE);
  5. $this->session->set('id', $row->user_id);
  6. $this->session->set('login', $row->user_name);
  7. $this->session->set('email', $row->user_email);
  8. $this->session->set('lastvisit', $row->user_last_login);
  9. $this->session->set('role', $row->role_id);
  10. $this->db->from('users');
  11. $this->db->set(array('user_logins_count' => $row->user_logins_count+1, 'user_cookie_key' => $cookie_key, 'user_last_ip' => $this->input->ip_address(), 'user_last_login' => mktime()));
  12. $this->db->where(array('user_id' => $data[0], 'user_cookie_key' => $data[1]));
  13. $this->db->update();
  14. ?>

oczywiście troszkę inaczej... smile.gif
LBO
Cytat(terabit @ 11.08.2008, 23:16:08 ) *
wiec wedlug mnie pobinien byc w kontrolerze i przekazywany do widoku gdy bedzie taka potrz


Wiesz, boli mnie jak widzę też interpretację Widoku w MVC serwowana przez frameworki :/

  1. <?php
  2. // w akcji
  3. if(($list = $model->getList()) !== null) {
  4. $this->view->set('list', $list);
  5. } else {
  6. $this->view->set('error', 'Nie znalezione');
  7. $this->vie->setTemplate('Error');
  8. }
  9. ?>


W sumie wtedy można powiedzieć, że robisz to w kontrolerze.
W Agavi natomiast widok to zupełnie inna sprawa, każdy rodzaj widoku to osobna klasa, ze swoją logiką i metodami.

  1. <?php
  2. // w akcji
  3. try {
  4. if(($list = $model->getList()) !== null) {
  5. $this->setAttribute('list', $list); // przekazuje dane do widoku.
  6. return 'List'; // a widok juz sie zajmie tym i albo wypluje html, albo json, albo coś jeszcze inn
    ego
  7. } else {
  8. return 'NotFound'; // nie znalezione -> tam komunikat
  9. }
  10. } catch (Exception $e) {
  11. // model rzucił błędem
  12.  return 'Error'; // tam komunikat, że wystąpił błąd
  13. }
  14. ?>


Cytat(terabit @ 11.08.2008, 23:23:42 ) *
<?php
foreach($query as $row)
{
$this->session->set('isLogin', TRUE);
$this->session->set('id', $row->user_id);
$this->session->set('login', $row->user_name);
$this->session->set('email', $row->user_email);
$this->session->set('lastvisit', $row->user_last_login);
$this->session->set('role', $row->role_id);
$this->db->from('users');
$this->db->set(array('user_logins_count' => $row->user_logins_count+1, 'user_cookie_key' => $cookie_key, 'user_last_ip' => $this->input->ip_address(), 'user_last_login' => mktime()));
$this->db->where(array('user_id' => $data[0], 'user_cookie_key' => $data[1]));
$this->db->update();
?>[/php]
oczywiście troszkę inaczej... smile.gif


To już robisz jak chcesz, teoretycznie model powinien zamknąć w sobie całość działania aplikacji, więc kod powyżej się nie kłoci z tym.
W agavi (jak i w Symfony) istnieje obiekt sessionUser, w którym w odpowiedniej metodzie inicjalizacyjnej uruchamiam model użytkownika, pobieram dane i ustawiam wartości zmiennych sesji. Ale jakby tego nie było, prawdopodobnie bym użył modelu.
terabit
czyli właściwie kontroler powinien tylko pośredniczyć miedzy widokiem a modelem, pobiera z modelu i wrzuca do widoku... żadnych zbędnych pętli etc questionmark.gif?
LBO
Dokładnie - model pobiera dane (czy z bazy, czy z Jakiegoś API sieci), zwraca dane (dobrze jak zwraca jakieś w ustalonym formacie, czyli np tablice, a nie obiekty należące np do ORM) i robi jakieś dodatkowe rzeczy (jak ustawianie zmiennych sesji, jezeli zajdzie potrzeba).

Mam nadzieję, że ---> POMOGŁEM <---- smile.gif
terabit
oczywiście że pomogłeś :]

dodatkowo bardzo proszę o jakiś post od Pana Normanosa bo z tego co widziałem to na Kohanaphp zna się bardzo dobrze :]
nrm
oj, już nie wypominaj mi wieku ;P, poza tym w necie jesteśmy zwykle na "ty" winksmiley.jpg

przykład nr 1 jest u mnie widokiem sterowanym przez kontroler

przykład nr 2: tak, zgadzam się z przedmówcami winksmiley.jpg

a tak w ogóle to bardziej pytasz o teorię niż Kohanę, a ja z teorii to lewy jestem winksmiley.jpg

ps. wróciłem z urlopu - dlatego tyle nie pisałem winksmiley.jpg
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.