[MVC] Pytań kilka... Opcje

[Zepco]

Ponieważ nie mam dostępu do forum DEV, a wiem, że tam po części problem MVC był poruszany, postanowiłem zadać kilka pytań.

Coraz więcej mówi/pisze się na temat MVC (Model-View-Controller) ale pomimo usilnych starań nie mogę zrozumieć pewnych mechanizmów, tymbardziej, że większość przykładów podawanych jest w Java'ie.

Może zacznę od tego co już wiem, jeśli się mylę, proszę poprawcie mnie. (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Cała aplikacja składa się z trzech części:

:arrow: Kontrolera, który odbiera operacje z zewnątrz (input) i odpowiednio je przetwarza, wywołując konkretny model (modułu) i metodę tegoż modelu. Może również odwoływać się bezpośrednio do widoku.

:arrow: Modelu, który jest niejako modułem odpowiedzialnym za jakiś ułamek pracy aplikacji (menu, news, sonda itp, itd.). Także jak widać w przeciwieństwie do kontrollera istnieje wiele modeli. Jak wcześniej wspomniałem model odbiera od kontrolera odpowiednie rządania, przetwarza je i wynik może przesłać do widoku.

:arrow: Widok natomiast wszystkie dane wysłane z modelu lub kontrolera wysyła na zewnątrz (wyświetla wynik na WWW, tworzy dokument XML, PDF itp.). Tak więc może być kilka podwidoków, które wywołane przez widok głowny tworzą efekt końcowy widoczny dla użytkownika.

A teraz czas na pytania:
* w jaki sposób elementy te komunikują się?
* wiem, że najbardziej naturalnie będzie zastosować programowanie obiektowe, ale czy da się to zrobić strukutralnie?
* co jest w przypadku gdy jeden model jest zależny (potrzebuje danych) od drugiego modelu?
* czym są akcje (actions) i łańcuchy (chains)?

Jeśli coś pominąłem, proszę dopiszcie, Myślę, że dyskusja na ten temat wpłynie w jakimś stopniu na rozpowrzechnienie tego rozwiązania, a chyba na tym nam zależy, aby łatwiej tworzyć aplikacje webowe i w przyszłości korzystać z już napisanego kodu...

[rzseattle]

No wiec tak sorry ale odpowiem nie po kolei :

ad 4

Akcje sa to logicznie podzieone operacje tzn ze w akcji starasz sie zawrzec najbardziej niepodzielna operacje jaka sie da. Czyli na przyklad akcje : zaloguj, usun artykul, dodaj artykul, pokaz menu itd. Akcje dzielimy naa logiczne i widoki. Akcje logiczne sa odpowiedzialne za realizacje zadan takich jak dodaj, usun, powiarz, sprawdz itd. podczas gdy akcje widoki maja za zadanie zwrocic dane do przegladarki.
Łancuch akcji polega na tym ze jezeli wciskasz przycisk usun artykul to najpierw wlacza sie akcja potwierdzajaca wybor potem ta akcja uruchamia akcje usuwajaca artykul ktora z kolei wywluje widok pokazujacy liste artykulow, taki lancuszek.

ad 1

Kontroler dostajac odpowiednie dane uruchamia odpowiednia akcje ktora uruchamia odpowiedni model. Mozna ten schemat komplikowac ale generalnie tak to wyglada.

ad 2

Jesli udalo by ci sie to oprogramowac strukturalnie to ja chcialbym taki silnik zobaczyc (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

ad3

Wlasniesie spotkalem z takim problemem. No coz poprostu w akcji uruchamiam dwa modele.

ps Dodamtylko ze zadaniem modelu jest tylko i wylacznie stworzenie abstrakcji na dane tak aby jezeli sie cos zmieni np. w bazie to grzebiesz tylko w modelu a nie we wszystkich akcjach.

[radziel]

[...] Modelu, który jest niejako modułem odpowiedzialnym za jakiś ułamek pracy aplikacji[...]

Mylisz dwa pojęcia,
model ma za zadanie komunikację z bazą i zwracanie danych.

moduł to zbiór akcji które sąodpowiedzialne za "przetwarzanie" danych z modelu.

Mam nadzięję że dobrze wytłumaczyłem (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[rzseattle]

Mylisz dwa pojęcia, 
model ma za zadanie komunikację z bazą i zwracanie danych.

moduł to zbiór akcji które sąodpowiedzialne za "przetwarzanie" danych z modelu.

Mam nadzięję że dobrze wytłumaczyłem (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

No nie do konca (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) . To nie musi byc koniecznie baza danych, moga byc pliki, xml czy jeszcze jakies inne zrodlo danych.

[radziel]

No nie do konca (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) . To nie musi byc koniecznie baza danych, moga byc pliki, xml czy jeszcze jakies inne zrodlo danych.

No tak, ale wkażdym razie model zwraca dane do obróbki (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[Zepco]

No wiec tak sorry ale odpowiem nie po kolei :
ad3

Wlasniesie spotkalem z takim problemem. No coz poprostu w akcji uruchamiam dwa modele.

Nie wiem czy dobrze rozumiem, ale w pliku konfiguracyjnym mógłby być wpis o zależności (dependencies) od innego modelu.

A jak sprawa ma sie z widokiem i podwidokami?
Czy widok jest tą klasą główną, która wysyła dane do odpowiedniego podwidoku, a ten wysyła go na wyjście, czy też wyborem widoku zajmuje się kontroler?

[rzseattle]

Nie wiem czy dobrze rozumiem, ale w pliku konfiguracyjnym mógłby być wpis o zależności (dependencies) od innego modelu.

A jak sprawa ma sie z widokiem i podwidokami?
Czy widok jest tą klasą główną, która wysyła dane do odpowiedniego podwidoku, a ten wysyła go na wyjście, czy też wyborem widoku zajmuje się kontroler?

Jak juz wspomnialem model jest klasa tworzaca abstrakcje na zrodla danych, wiec jesli potrzebuje w danej akcji dwoch modelow to poprostu includuje oba i kozystam z dwoch przy czym jeden o drugim nie musi nic "wiedziec".

Nie rozumie co rozumiesz przez polwidok?? Akcje logiczna?

Lancuszek akcji jest tworzony w ten sposob:

1) Router "dekoduje" url i wysyla do kontrolera jak akcje ma uruchomic
2) Kontroler sprawdza czy akcja potrzebuje zalogowania , czy jest plik akcji itd...
3) Kontroler uruchamia akcje.
4) Akcja wykonuje sie i po zakonczeniu wywoluje inna akcje
5) Na koncu jest zawsze akcja - widok ktora wysyla dane do przegladarki i nie wywoluje juz innej akcji
6) Wykonywany jest destruktor kontrolera

THE END (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Przedstawilem to w sporym uproszczeniu, ten schemat tez mozna komplikowac, ale mniej wiecej tak to dziala.

[Zepco]

Specyfikacja URLa oczywiście nie ma znaczenia i zależy jedynie od wyobraźni twórcy?
Czy dane wysłane przez POST i GET oraz te, które są zawarte w SESSIONS wyciągane są bezpośrednio przez modele, czy też tym też zajmuje się kontroler?

[radziel]

Specyfikacja URLa oczywiście nie ma znaczenia i zależy jedynie od wyobraźni twórcy?
Czy dane wysłane przez POST i GET oraz te, które są zawarte w SESSIONS wyciągane są bezpośrednio przez modele, czy też tym też zajmuje się kontroler?

Zajmuje się tym kontroler - najlepiej napisz klasę / funcję (zależy jak programujesz (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ), która będzie zajmować się danymi z input'a.

[rzseattle]

Specyfikacja URLa oczywiście nie ma znaczenia i zależy jedynie od wyobraźni twórcy?

I od konfiguracji serwera (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

Czy dane wysłane przez POST i GET oraz te, które są zawarte w SESSIONS wyciągane są bezpośrednio przez modele, czy też tym też zajmuje się kontroler?

Nie trzeba MVC zeby wiedziec ze w pozadnym silniku nie uzywa sie tych tablic ( bezpieczenstwo). Tak na wstepie konstruktor kontrolera powinien wywolywac obiekt input ktory zajmie sie skladowaniem danych zewnetrznych. Sesje tez najlepiej zamaskowac pod jakas metoda kontrolera. Pamietaj tez ze zmienna z jednej akcji nie bedzie widoczna w drugiej wiec tez musisz pomyslec nad sposobem przekazywania tych zmiennych. Najlepiej wtedy dodac opcjonalny argument dla metody zapisujacej zmienna ktory powie "umiesc mnie w sesji" (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

ps Nie przesadzaj z tym Pomogl Mi

[kubatron]

A mógłbym zapytać gdzie to można ściagnąć jak zainstalować,jakis kurs/manual i co to jest (IMG:http://forum.php.pl/style_emoticons/default/rolleyes.gif)

[scanner]

Jeden z dostępnych: http://phiend.sourceforge.net

[Nalfein][WR]

Nie wiem czy dobrze rozumiem, ale w pliku konfiguracyjnym mógłby być wpis o zależności (dependencies) od innego modelu.

Mógłby być, ale po co. Możesz po prostu includować (bezpośrednio przez include() lub przez inny obiekt - menedżera klas aplikacji) plik z klasą odpowiedniego modelu z poziomu innego modelu.

A jak sprawa ma sie z widokiem i podwidokami?
Czy widok jest tą klasą główną, która wysyła dane do odpowiedniego podwidoku, a ten wysyła go na wyjście, czy też wyborem widoku zajmuje się kontroler?

Wyborem widoku zajmuje się kontroler, a raczej (przeważnie) ostatnia akcja w łańcuszku, tutaj nazywamy ją akcją widoku, gdzieniegdzie możesz ją znaleźć pod nazwą kontrolera widoku (ViewController). W niej ładujesz i wypełniasz szablon. Akcja widoku wypełnia sam widok, czyli przeważnie szablon Smarty, arkusz XSLT. Sam widok przeważnie nie jest klasą, chyba, że zastosujesz technikę kompilacji szablonów do klas. Na razie takiego engine-u pod php nie ma, ale już się robi (u mnie (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) ). Do widoku przekazujesz dane, porcję danych, możesz ją przechowywać w osobnej warstwie obiektów typu DataSpace/DataProvider, wtedy akcja widoku po prostu wybiera obiekty "dostawców danych" i obiekt(y) "widoku". Podwidoków w php nie ma wyodrębnionych jako tako, gdyż jak już wspomniałem widok jest płaski, inne widoki po prostu {include}-ujesz przez Smarty jak zwykłe fragmenty szablonów.

[bumelang]

Jak juz wspomnialem model jest klasa tworzaca abstrakcje na zrodla danych [ciach!]

Może jestem nadgorliwy, ale chodzi bardziej o to, że w kontrolerze nie są podejmowane żadne działania z zakresu logiki aplikacji. Kontroler steruje widokami, czyli po prostu interface'm użytkownika, zaś całość logiki zawiera się w modelu. Różnica jest taka, że model nie reprezentuje źródła danych. Fakt, że typowy model to np. wywołanie
[php:1:e6cd80946a]$managerProduktow->dodajProdukt($p)[/php:1:e6cd80946a]
ale od abstarkcji na źródło danych różni się to tym, że model może tu robić niezłą zamotkę z danymi, która z punktu widzenia kontolera jest nieistotna, i tu jest prawdziwy zysk - ktoś zmienia implementację logiki, ale logika prezentacji się nie zmienia.

Z resztą nie da się ukryć, że MVC ma największy sens przy aplikacjach heterogenicznych, gdzie model jest napisany w innym języku programowania, albo przynajmniej jest uruchamiany na innym serwerze.

[rzseattle]

zaś całość logiki zawiera się w modelu.

Musze przyznac ze sie pogubilem. Tworzac pod MVC nie spotkalem sie z sytuacja kiedy model w oparciu o dostarczone mu dane mial decydowac co ma zrobic ( a tak chyba definiujemy logike aplikacji :?: ), wrecz przeciwnie wszystko jest umieszczone w pojedynczych akcjach i to one decyduja co zrobic, przekazujac to modelowi ktory wie jak i gdzie. Jakdla mnie to jest czysta abstrakcja na zrodlo danych

... ale od abstarkcji na źródło danych różni się to tym, że model może tu robić niezłą zamotkę z danymi, która z punktu widzenia kontolera jest nieistotna, i tu jest prawdziwy zysk - ktoś zmienia implementację logiki, ale logika prezentacji się nie zmienia.

Jesli mozna wiedziec to co rozumiesz przez "zamotke z danymi". Bo dla mnie zbior operacji ukryty pod jedna metoda to juz jest abstrakcja i biorac pod uwage ze model zajmuje sie danymi zewnetrznymi ( przeciez nie robimy w akcji $mathModel->dodaj($this->input['a'], $this->input['b'], $this->input['c']) ) to dla mnie jest to abstrakcja na zewnetrzne zrodla danych. A to czy operacje na danych sa proste czy skomplikowane to mnie nie interesuje.

No ale moze zle rozumie stwierdzenie "Logika aplikacji" (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[bumelang]

Wszystko wskazuje na to, że mamy odmienne pojęcia na "abstrakcję źródła danych". Z tego, co wiem, to w typowym znaczeniu oznacza ona po prostu klasę dostępową do źródła, niezależną od implementacji na konkretnej bazie danych czy pliku - taki API, jak np. AdoDB.

Innymi słowy, w 3-warstwowym modelu aplikacji najniżej jest warstwa dostępu do danych (do której API dostępu z warstwy drugiej można określić "abstrakcją na źródło danych", jeśli takie jest zastosowane).

Warstwa druga, która jest najczęściej modelem, stanowi tymczasem zbiór klas czy funkcji tzw. "logiki biznesowej", co przede wszystkim oznacza, że ta warstwa + warstwa danych tworzy gotową aplikację - realizuje wszystkie zadane operacje na bazie danych, uwierzytelnianie użytownika, tworzy jakieś logi, wywołuje jakąś usługę SOAP, wysyła maila, cokolwiek, ale jest to kompletny, działający system, tyle, że zamiast interface'u użytkownika udostępnia API programistyczne dla warstwy jeszcze wyższej.

Warstawa kontrolera i widoku to tymczasem warstwa prezentacji, czyli jeszcze wyżej. I teraz wygląda to tak, że użytkownik się loguje, łaczy się z kontrolerem, któremu przesyła żądanie, ten czyści dane wejściowe i jeśli wszystko jest ok wywołuje funkcję zaloguj($login, $haslo) warstwy logiki biznesowej (czyli model) i sprawdza, czy to się powiodło, ale nie wie nic o szczegółach implementacji w modelu i - przede wszystkim - nie ma dostępu do bazy danych, nie może wywołać żadnego zapytania SQL. Później kontroler przekazuje sterowanie do odpowiedniego, w zależności od powodzenia operacji, widoku - ale to jest jasne.

Oczywiście 3-warstwowy model aplikacji jest tu tylko po to, żeby objaśnić zagadnienie modelu jako takie w kontekście "abstrakcji źródła danych". W rzeczywistym systemie z zastosowanym MVC mogą być z równym powodzeniem tylko 2 warstwy - sama prezentacja i model.

Jak widzisz, być może że tylko 1 pojęcie sprawiło, że myślisz, że tego nie rozumiesz, a rozumiesz - jeśli tak to sorry za zamotkę (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[rzseattle]

Warstwa druga, która jest najczęściej modelem, stanowi tymczasem zbiór klas czy funkcji tzw. "logiki biznesowej", co przede wszystkim oznacza, że ta warstwa + warstwa danych tworzy gotową aplikację - realizuje wszystkie zadane operacje na bazie danych, uwierzytelnianie użytownika, tworzy jakieś logi, wywołuje jakąś usługę SOAP, wysyła maila, cokolwiek, ale jest to kompletny, działający system, tyle, że zamiast interface'u użytkownika udostępnia API programistyczne dla warstwy jeszcze wyższej.

No maly OT sie zrobil. Ale czy udostepnianie API programistycznego ktore maskuje wszelkie zrodla danych i nie wymaga wiedzy skad i dokad podazaja zmienne nie jest abstrakcja na zrodlo. Dla mnie wlasnie tu jest granica - Dopiero tam gdzie przestajemy sie interesowac czy dane pochodza z ADoDB czy jakiegos obiektu obslugujacego XML konczy sie abstrakcja. Ale rozumiem twoje podejscie , jednak zauwaz ze np ADoDB tez udostepnia API programistyczne ktore ulatwia obsluge bazy danych.

No ale jak juz powiedzialem OT (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

[bumelang]

Być może to jest OT, ale nie wiem, czy można nazwać abstrakcją na źródło danych coś, co nie koniecznie operuje na danych w bazodanowym sensie i nie koniecznie ma dostęp do źródła danych. Przecież model może np. pobrać informacje o dostępności produktu przez SOAP, sprawdzić stan rachunku bankowego, zamówić produkt i przelać kasę. I to wszystko w jednym wywołaniu modelu.

A warto też dodać, że model może być np. aplikacją w C, która ma za zadanie obliczyć symulowane odsetki, a kontroler tylko robi exec('/usr/bin/odsetki -sklada_miesieczna 3000');

[Zepco]

Jak dla mnie takie OT mogą być, o ile mieszczą się w pewnych ramach tematu tak jak powyższa polemika. :-)

Tak na marginesie chciałem zapytać skąd czerpaliście informacje na temat MVC?

[Sh4dow]

Moze troche sie wtrącam do waszej zrozmowy, ale moze powiecie mi pare rzeczy. Jako ze nie obeznany jestem tak jak Wy, nie zawsze kojaze co za skroty uzywacie, albo jakies pojecia anglojezyczne. No ale nie o oto i do konca chodzi. Jak napisal scanner ze jeden z takich MCV jest dostepny na necie oczywiscie tam zagladolem. Ale niestety moja wiedza tajemna nie byla wstanie przegrysc samego manuala, wiec o testach na phiendzie nie bylo mowy.
Ale po kolejnych postach zaczyna cos mi swiatac na temat calego tego MVC.

Bumelang napisał o 3 warstwowym poziomie aplikacji, szczerze mowiac dopiero jego post dal mi do myslenia jesli chodzi o cale zagdanienie MVC.

Jesli dobrze zrozumialem do pierwsza warstwa jest odpowiedzialna za pobranie danych, naprzyklad skrypt rozpoznaje zapytanie, np User chce zobaczyc na stronie komantarze do artykulu, wiec skrypt rozpoznaje ze chodzi o komentarze o jakies danej specyfikacji, wiec lpobiera dane dla tej specyfikacji (pliki, bazy danych, sockets itd). Procz tego apytania, sa standardowe zapytanie, powiedzy o konfiguracje strony (tytul, adres, kolor itd). Jako standardowe zapytanie przy wiekszosci odslon.
Ta warstwa teoretycznie konczy swoje zadanie i przesyła dane do drugiej warstwy, której zadaniem jest przetworzenie wszystkich otrzymanych danych. Tutaj nawołując do przykladu, skrypt powiedzmy ze w komentarzach przetwarza text (np BBcode) ustawia zapis daty i jakie pare tam innych opcji mniej waznych.
Przetworzone dane wędruja teraz do warstwy ktora zajmuje sie wyswietlanie, powiedzmy ze beda to Smarty, które generuja nam gotowy kod wysylany do przegladarki. i tutaj piszecie jeszcze o wykonaniu destruktora.

A teraz pare Pytanek:
- czy dobrze zrozumialem to zagadnienie? oczywiscie jest ono mocno uproszczone.
- czy warstwa 2(czyli przetwarzanie danych) moze czesciej pobierac dane z 1 warstwy? Np. po otrzymaniu danych, podczas przetwarzania pobrac dodatkowe informacje, czy trzeba przewidziec to w 1 warstwie i wyslac odrazu.
- czym jest destruktor, jakie jest jego działaniei i co sie stanie jesli go nie bedzie?

Oczywiście 3-warstwowy model aplikacji jest tu tylko po to, żeby objaśnić zagadnienie modelu jako takie w kontekście "abstrakcji źródła danych". W rzeczywistym systemie z zastosowanym MVC mogą być z równym powodzeniem tylko 2 warstwy - sama prezentacja i model.

czy zalozenie 2 warstw mam rozumiec poprze poprzez polaczeni pierwszej i drugiej? Ma to jakas zalete?

[hawk]

Jak napisal scanner ze jeden z takich MCV jest dostepny na necie oczywiscie tam zagladolem. Ale niestety moja wiedza tajemna nie byla wstanie przegrysc samego manuala, wiec o testach na phiendzie nie bylo mowy.

Hmm, jako autor phienda potwierdzam że proste to-to nie jest. A moje anty-patriotyczne podejście do lokalizacji manula :oops: niektórym nie ułatwia sprawy. Ale podobno gdzieś tutaj na forum powstaje tłumaczenie.

Ja myślę że kojarzenie MVC z warstwami jest zbytnim uproszczeniem. Owszem, MVC wymusza podział aplikacja na warstwy (w ogóle wymusza sensowną organizację aplikacji). Ale warstw może być więcej niż 3, np:

1) baza danych (mySQL)
2) warstwa abstrakcji nad bazą danych (ADODB)
3) klasy Modelu (php)
4) Kontroler (php)
5) klasy Widoku (php)
6) szablony Widoku (Smarty)
7) wynik końcowy (HTML)

To daje 7 warstw (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) . Dzielić można różnie, ale ważne jest to, że wg. MVC aplikacja powinna mieć 3 główne częśći:

1) Model: logika biznesowa, operacje na źródle danych (np. baza danych), nic nie wie o HTML

2) Widok: logika prezentacji, czyli nie tylko szablony (ale implementacja Widoku za pomocą szablonów jest dobrym pomysłem), wie jak wyciągnąć potrzebne dane z Modelu

3) Kontroler: zbiera to wszystko do kupy, wie że jest żądanie strony i decyduje co należy zrobić żeby wygenerować odpowiedź

MVC pozwala łatwo modyfikować aplikację, np. zmieniać bazę danych, strukturę URLi, wygląd strony, przejść z HTML na PDF, itd. Bo jest podział odpowiedzialności i hermetyzacja.

Tak na marginesie chciałem zapytać skąd czerpaliście informacje na temat MVC?

Niektórzy, nie chwaląc się, czerpali m.in. z dokumentacji phienda (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) , ale poza tym polecam artykuły w php|architect z maja i czerwca 2003. Jakoś trafiłem na promocję i darmowy numer.

Poza tym, jak tylko ruszy portal php.pl, pokaże się na nim mój obszerny artykuł na ten temat. Na razie leży sobie gotowy w DocBooku i czeka, aż będzie gdzie go umieścić.

[bumelang]

Tak na marginesie chciałem zapytać skąd czerpaliście informacje na temat MVC?

Ja prywatnie znam to zagadnienie z Javy, gdzie jest kilka framework'ów MVC - np. Struts albo WebWorks i też kilka książek dotyczących wzorców projektowych. Nie mniej, jeśli nie znasz Javy, to niewiele Ci to pomoże - ale na lekturkę być może warto zawsze się szarpnąć, bo koncepcja jest wspólna.

Jak napisal scanner ze jeden z takich MCV[...]

Mylisz trochę pojęcia - MVC to nie jakiś program czy skrypt, tylko strategia pisania interface'u użytkownika. Taką strategię w bardziej rozwiniętych obiektowo językach nazywa się wzorcem projktowym. Ten wzorzec definiuje po prostu, że ma być ten model, view i controller i jak mają ze sobą współpracować. Wybór konktretnego ułatwiacza to nie wybór MVC.

A co do tego, co napisałeś potem, to chyba za bardzo namieszałem z tymi warstwami. MVC nie ma z tym nic wspólnego. Model, widok i kontroler to 3 klasy i tylko tyle. Teraz, jeśli masz aplikację pisaną w architekturze 3-warstowej, to tak wychodzi, że kontroler i widok są w warstwie klienta (prezentacji) a model w warstwie logiki biznesowej. Ale ogólnie mówiąc architektura 3-warstwowa jest niezależna od MVC jako pojęcie.

Działa to tak: użytkownik wysyła żądanie w sensie HTTP, np. wypełnia jakiś formularz i klika "Submit", gdzie akcja formularza jest ustawiona na skrypt, w którym znajduje się kontroler. Ten łączy się z modelem, wywołuje tam jakieś metody biznesowe i gdy te zwrócą mu już efekty swojej pracy, to w zależności od tego, jakie one są, przekazuje to wywołanie do odpowiedniego widoku, czyli odpowiedniej strony php (która może być napisana w Smarty). W php w najprostszym wariancie może być to po prostu
[php:1:a43ca395d1]<?php
/* Kontroler */
if($model->zaloguj($login, $haslo) == SUCCESS) //wywołanie modelu
include("strona_glowna.php"); // wywołanie widoku
else
include("blad.php"); // wywołanie innego widoku
?>[/php:1:a43ca395d1]

Różnica w architekturze pomiędzy MVC a jego brakiem jest taka, że bez MVC logika jest zaszyta w kontrolerze (można powiedzieć, że nie ma warstwy logiki). Nie można jednak traktować Smarty jako kolejnej warstwy, bo to nie o to chodzi.

Natomiast aplikacja może być 2-warstwowa w takim sensie, jak napisałem wtedy, jak nie ma bazy danych, tylko np. coś liczy. Wtedy warstwa danych nie istnieje, nie że łączy się z jakąś inną w jedność.

Mam nadzieję, że nie zaciemniłem za bardzo obrazu tymi warstwami (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[DeyV]

jak już trwa taka zaciekła rozmowa na temat MVC, to zauważę, że warto ponownie zainteresować się ciekawym systemem WACT http://www.phppatterns.com/index.php/artic...cleview/85/1/9/
System ten, poza paroma ciekawymi innowacjami, pokazuje również (z tego co zdążyłem się zorientować po paru minutach przegladania) bardzo ciekawy sposób komunikacji pomiędzy modelem a widokiem, któy pozwala na przeniesienie zainicjowania procesu pobrania danych przez view, dopir0o w momencie, gdy te dane będą mu potrzebne.
Chyba nie trzeba nikogo przekonywać, jak często takie rozwiązanie może być bardzo przydatne.

[hawk]

Hmm, ciekawe...
Z tego co na razie widziałem, WACT ma bardzo fajny system szablonów. Wspominał o tym gdzieś Nalfein (ale o idei, nie o WACT): wyciągać dane z modelu tylko wtedy, kiedy widok naprawdę ich potrzebuje, a nie jak np. w Smarty najpierw wyciągać, a potem zobaczymy czy widok w ogóle z nich skorzysta. To jest wielki plus.

I sam język szablonów jest ładny, taki XML-owy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) . Czyli podobny do Struts w Javie. Albo nie do samego Struts, ale do JSP generalnie. Taka strona wygląda jak JSP i działa mniej więcej jak JSP.

Ale nie widziałem tam jeszcze samego kontrolera :? . Może dlatego że coś mi strona WACT kiepsko działała. Anyway, gdzie tam jest założenie, że mamy jeden główny skrypt (kontroler) i akcje? Gdzie rozdział między akcjami a modelem? W tutorialu widziałem SQL przemieszany z assignami do szablonu.

No ale niedokładnie szukałem, a sam WACT jest pre-alpha. Na razie wydaje mi się, że to jest świetne rozwiązanie widoku, ale nie całego MVC.

[scanner]

Hmm, jako autor phienda potwierdzam że proste to-to nie jest. A moje anty-patriotyczne podejście do lokalizacji manula :oops: niektórym nie ułatwia sprawy. Ale podobno gdzieś tutaj na forum powstaje tłumaczenie.

Jako szef Content Teamu Mogę powiedzieć, że tłumaczenia już jest gotowe, niestety tłumaczka nie miała do dyspozycji edytora XML, zatem ja żmudnie w wolnych chwilach przenosze wszystko z Worda. Dostępne na CVS'ie (dla developerów) jest już 4,5 rozdziału i byłbym wdzięczny hawk, gdybyś na to zerknął. Jutro powinieniem dodać końcówkę 4 i może cały 5 rozdział.
Hawk: w razie uwag, proszę na PW lub maila (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Dokumentacja phienda po polsku w założeniach ma ukazać się na php.pl.

[cagrET]

Anyway, gdzie tam jest założenie, że mamy jeden główny skrypt (kontroler) i akcje? Gdzie rozdział między akcjami a modelem?

Jeżeli dobrze doczytałem to doszli do wniosku, że kontroler jest zbędny w php. Kod jest mniej elastyczny, trudniej jest go zintegrować z innymi aplikacjiami. Za kontroler uznano sam Apache, a akcjami są pliki .php

czyli struktura aplikacji jest w stylu:

/news/view.php
/news/list.php
/news/edit.php

/forum/viewTopic.php
/forum/viewForum.php

etc

[Nalfein][WR]

Jeżeli dobrze doczytałem to doszli do wniosku, że kontroler jest zbędny w php. Kod jest mniej elastyczny, trudniej jest go zintegrować z innymi aplikacjiami. Za kontroler uznano sam Apache, a akcjami są pliki .php

Wow! A już myślałem, że tylko ja jestem taki crazy, żeby zrywać ze wszystkimi standardami ;P Założenia bardzo fajne, popieram wszystkiema ręcami i nogami.

Ale to ma też minusy, bo nie można dać dwóch urli (np. pl-"electronics" i en-"elektronika") pod jedną akcję, chyba, że będziemy chamsko robili require() przy w drugim pliku. Dlatego robię u siebie akcje tylko wywoływane (wybierane) ze skryptów w "site dir", a implementecje są dalej w "code dir". W ten sposób zyskuję to co chcieli w WACT - eliminuję router (do pewnego etapu - pliki w "site dir" mogą być routerami, bo mogę napisać /forum/viewpost.php/110), ale zachowuję możliwość zmiany URLi bez zmiany nazwy pliku z akcją.

[hawk]

Minusów jest więcej:
- Co zrobić, jak tego pliku akurat nie ma? Kontroler sobie poradzi, Apache nie.

- Nie każda akcja musi kończyć się wyświetleniem HTMLa - patrz akcje logiki. A tak co? Robić require w tych plikach, i skończyć z taką siecią powiązań?

- Jak będziesz chciał zmienić np. lokalizację WACT, albo jakiekolwiek inne ustawienie globalne, to globalny regexp po wszystkich plikach albo z godzinka roboty...

Jest różnica pomiędzy wywaleniem w ogóle kontrolera, a eliminację routera. Chociaż pojęcie routera jest nasze autorskie i nie występuje w MVC. Hierarcha katalogów jako sposób wybierania akcji do wywołania OK, ale oni idą znacznie dalej.

BTW, trochę zabawne że oni mimo to piszą o MVC. Zrobiliśmy framework oparty o wzorzec Model-View-Controller, ale wywaliliśmy z wzorca cały kontroler (IMG:http://forum.php.pl/style_emoticons/default/laugh.gif) . Co nie znaczy że wszystko co dobre musi być MVC. Ale jeżeli ktoś usilnie stara się przedstawić swój projekt jako MVC, to o czymś świadczy...

[Nalfein][WR]

Nie wywalili kontrolera, ale wywalili obiekt typu FrontController. Akcje logiki to też przecież warstwa kontrolera.

[hawk]

Ale warstwa kontrolera bez kontrolera? (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)
To tak jak system bazodanywy bez bazy danych. Albo aplikacja obiektowa bez obiektów.

Zresztą, u nich nie ma akcji logiki.

[Nalfein][WR]

Chyba za dużo nad Phiendem przesiedziałeś (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) To tak jak rozproszona baza danych (np. pliki XML) czy jak aplikacja obiektowa bez menedżera obiektów. Ja robię to tak np. w pliku /forum/view.php mam:

[php:1:17e5bd469d]
<?php
$app = CodeZone::instance();
$action = $app->create('ViewForumAction', 'actions/forum');
$app->run($action);

// albo $app->execute($request, $response, $action);
// aby realizować testy XP z obiektami FakeRequest oraz FakeResponse
?>
[/php:1:17e5bd469d]

Metoda ::run() klasy aplikacji przekazuje obiekt $action do kontrolera wraz z obiektami $request, $response, które tworzy. Kontroler obsługuje żądanie wypełniając $response, a aplikacja wyrzuca wynik na ekran. Nie wywołujemy tutaj jawnie kontrolera (FrontControllera), przez co możemy w ogóle z niego zrezygnować w prostych aplikacjach, a może za tym wszystkim siedzieć nawet Phiend2.

© Paladine Framework (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[cagrET]

- Co zrobić, jak tego pliku akurat nie ma? Kontroler sobie poradzi, Apache nie.

Już raz to gdzieś pisałem

Kod

<IfModule mod_rewrite.c>

    RewriteEngine On

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule ^(.*)$ error/404.php [L]

</IfModule>

- Nie każda akcja musi kończyć się wyświetleniem HTMLa - patrz akcje logiki. A tak co? Robić require w tych plikach, i skończyć z taką siecią powiązań?

Nie rozumiem co miałeś tutaj na myśli. Kto powiedział że każda akcja musi się kończyć wyświetleniem htmla ? Jaka sieć powiązań ? To właśnie użwając FronControllera jest dużo niepotrzebnych includów.

- Jak będziesz chciał zmienić np. lokalizację WACT, albo jakiekolwiek inne ustawienie globalne, to globalny regexp po wszystkich plikach albo z godzinka roboty...

Bardziej cenię sobie elastyczność. Ty już jesteś przyklejony na zawsze do tych ustawień globalnych. Ja mam wolną rękę. A gdy potrzebuję globalnych zmian REGEXP jest idealnym narzędziem (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

BTW, trochę zabawne że oni mimo to piszą o MVC. Zrobiliśmy framework oparty o wzorzec Model-View-Controller, ale wywaliliśmy z wzorca cały kontroler (IMG:http://forum.php.pl/style_emoticons/default/laugh.gif) . Co nie znaczy że wszystko co dobre musi być MVC. Ale jeżeli ktoś usilnie stara się przedstawić swój projekt jako MVC, to o czymś świadczy...

Nie zapominaj że php jest językiem skryptowym. Nie widzę sensu kopiować wszystkiego krok w krok z innych języków, bo w php się to po prostu nie sprawdza. O kontrolerze już pisałem że jest, tylko inaczej pojmowanym.

[hawk]

To w takim razie każda aplikacja w php jest oparta o wzorzec MVC, bo w każdej występuje Apache jako kontroler. Dochodzimy do absurdu.

[Sh4dow]

Hmm, tak szczerze mowiac, to kazda strona napisana w php, z wykozystaniem, bazy danych, jest juz oparta na modelu MVC.
Jesli dobrze wszystko rozumiem, to kazda strona dziala na takim założeniu. Dziwne by to chyba wygladało jak by szlo to w odwrotnym kierunku.
zeby nie zrobic gafy opieram sie na zend.com. Chyba kazda strona pobiera najpierw dane, pozniej dane sa obrabiane w tak zwanej "business logic" a na koncu sa/"moga byc" wyswietlane.
mam nadzieje ze teraz rozumiem to, jakos prawidlowo. Patrzac na to co wy mowicie, to jedyne czym moga sie roznic "wasze" strony od "moich" (mowie tutaj o sposobie pisania) to jest taka ze wy tworzycie zaawansowane klasy, a ja siedze jeszcze po czesci w procedurach.

[Nalfein][WR]

To w takim razie każda aplikacja w php jest oparta o wzorzec MVC, bo w każdej występuje Apache jako kontroler. Dochodzimy do absurdu.

Jeśli uważasz, że wzorzec FrontController-a = całe MVC to może i tak (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Tylko, że Apachem możemy wskazać jeden obiekt MVC, zależnie co mamy pod urlami - akcję lub widok. Chyba, że w plikach .php wybieramy widok i akcję wypełniającą widok (ViewController jak się zresztą ją określa) - wtedy mamy taki rozproszony kontroler, a Apache robi za router.

[KaGe]

OK
MVC itd...
Ale jak to wygląda w praktyce? - w momencie, gdy mamy zabrać się za pisanie właściwego projektu - opisać klasy itd...

czy ktoś ma jakiś gotowy wykresik prezentujący np. podział klas na MVC - w miarę dokładny?

Bo z tego co tu się pojawia to ja to widzę jakoś tak:

+KONTROLER © - max nadrzędnie
|- MODEL_a (M) - ściąga dane z bazy i operuje na nich fizycznie
|- MODEL_b (M) - inna klasa operująca na danych - np. danych usera itd..
|- MODEL_c (M) - jeszcze co innego - np. odpowiedzialnego za newsy, artukuły itd...
|- WIDOK (V) - dostaje info z kontrolera - po przetworzeniu odpowiedniego modelu i wyświetla to lub tworzy plik z wynikiem - w każdym bądź razie jest wywoływany na końcu i zajmuje się tylko prezentacją

Czy dobrze rozumuję?

[marcin96]

http://phppatterns.com/index.php/imagecata...cleview/19/1/1/

...tyle tylko, że w większości frameworków MVC masz jeden obiekt kontrolera, który wywołuje odpowiednie akcje/widoki w odpowiedzi na dane wejściowe. Model łączy się z akcjami/widokami poprzez agregację (czyli tak jak na tamtym diagramie) lub kompozycję (a nie przez dziedziczenie... bo wtedy to już masz model zagnieżdżony w akcjach/widokach.. a tego chcemy uniknąć przeważnie - inaczej to nie jest MVC (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) ) ). Czyli jedyne co robisz w widokach/akcjach, to wywołujesz odpowiednie metody odpowiednich modelów. Przynajmniej ja tak to wszystko rozumiem (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) ]

[KaGe]

Diagram widziałem, napisałem sobie nawet własne MVC - dokładnie takie samo, ale dot. czego innego - żeby się nauczyć. - nauczyłem się tego.
Ale:
1) jakbym chciał zrobić usuwanie, doadawanie itd.. - to gdzie dodać odpowiedzialne za to funkcje? - chyba do modelu, ale tam model jest tak zrobiony, że nie odpowiada konkretnemu zbiorowi danych w tabeli a jedynie służy za narzędzie. Więc może do kontrolera? - ok, ale on musiałby przekazać to wszystko do modelu i patrze pkt. wyżej....
2) nigdzie tam nie ma ustalonego id dla OKREŚLONEGO odpowiednika w bazie danych!! - ja wiem, moze nie do konca rozumiem OOP itd.. ale czy to nie jest troche malo uniwersalne, jezeli tylko kontrolerowi podaje id do wyswietlenia i nie moge potem np. zrobic tak:
[php:1:a31b6f25fe]<?php
$a = new ArticleSingleController($dao,$_GET); // gdzie $_GET[id]=2
$a-> // i tu jakos podzialac zeby display wyswietlil np. 3 art.
echo $a->view->Display();

?>[/php:1:a31b6f25fe]
Da sie tak?

[marcin96]

ad 1) poczytaj dokumentacje phienda (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) )

http://phiend.sourceforge.net/manual/actions.html <- zwlaszcza to pomoże...

W akcjach/widokach wywolujesz jedynie odpowiednie metody modelu. np
[php:1:121515932c]<?php
$ProductModel->DeleteItem($_GET['id']); // to będzie w akcji odpowiedzialnej za usuwanie
$ProductModel->UpdateItem($_GET['id'], $_POST['data']); // a to w akcji odpowiedzialnej za update..
?>[/php:1:121515932c]

Dopiero w modelu trzymamy SQL, czy cokolwiek innego odpowiedzialnego za usuwanie, modyfikacje.. czy zwracanie danych.

ad 2) w tym przykladzie jak zobaczysz na zrodlo ( http://phppatterns.com/index.php/article/a...cleview/19/1/1/ ...bo chyba podałem wczesniej link przypadkiem tylko do samego diagramu..), to kontroler tak naprawde zostal zrealizowany w index.php:
[php:1:121515932c]<?php
switch ( $_GET['view'] ) {
case "product":
$controller=& new ProductItemController($dao,$_GET);
break;
default:
$controller=& new ProductTableController($dao,$_GET);
break;
}
?>[/php:1:121515932c]

Tamten przykład podałem aby pokazać zależność między widokami/akcjami a modelem.. natomiast jak dla mnie realizacja kontrolera jest całkowicie bezsensowna... Naprawdę polecam lekturę Phiend'a. Na stronie projektu ( http://sourceforge.net/project/showfiles.p...?group_id=90219 ) też jest źródło aplikacji, którą masz tutaj:
http://phiend.sourceforge.net/application/

[KaGe]

1) Czy mam w takim razie do kontrolera, oproocz $model i $view dodać np. obiekt $action , który będzie działał na modelu? czy po prostu do samego modelu dodac odpowiednie metody?

2) A moze po prostu w modelu owszem, dopisac metody usuwania itd... a potem w kontrolerze - odpowiadające im, ale juz przekazujące identyfkatory i dane? - czy tak bedzie dobrze?

3) Jeszcze jedna sprawa: Tak mi sie wydaje, ze jak robie strone w MVC to:
powinien byc 1 kontroler - ktoory by wszystko tworzyl, ustawial, usuwal itd...
modele : odpowiedzialny za baze danych, odpwiednie do newsoow itd.. ,
widoki : prezentacje kazdego z modeli do newsoow itd...

Teraz tak:
czy nie powienien byc jeszcze jeden model i odpowiadajacy mu widok : np. o nazwie SiteModel i SiteView - ktoore odpowiadaly by za cala strone?
i np: SiteView to cos takiego:
[php:1:21abc83259]<?php
Class SiteView
{
var $views;
var $model;
var $output;

function SiteView($model)
{
$this->model = $model;
}

function AddView($view)
{
$this->views[] = $view;
}

function Header()
{
// naglowek <html> itd...
}

function Footer()
{
// /html itd...
}

function Site()
{
foreach($this->views as $n => $view)
{
$this->output .= $view->Display();
}
}

function Display()
{
$this->Header();
$this->Site();
$this->Footer();
return $this->output;
}
}
?>[/php:1:21abc83259]

Czy to jest dobre rozwiązanie?
jak np. chciałbym wyswietlic newsy to tylko bym dal w kontrolerze, ze

[php:1:21abc83259]<?php
$news= new NewsModel;
$newsview = new NewsView($news);

$siteview = new SiteView;
$siteview->AddView($newsview);

// a potem juz tylko:
echo $siteview->Display();

?>[/php:1:21abc83259]

[marcin96]

1) Czy mam w takim razie do kontrolera, oproocz $model i $view dodać np. obiekt $action , który będzie działał na modelu? czy po prostu do samego modelu dodac odpowiednie metody?

Do kontrolera nie dodajesz modelu... to w akcji/widoku sobie tworzysz instancje jednego modelu.. lub więcej, jeśli masz taką potrzebę.

Wprowadziłem tutaj podział na obiekty action i view podobnie jak w phiend - te pierwsze to akcje logiki - odpowiadają za modyfikację danych (tak, operują na modelu, który posiada metody dodajElement, zmieńElement itp), a te drugie to akcje widoku - odpowiadają, za zwracanie danych klientowi - wyświetlanie, przekierowanie do innej strony itp (również operują na modelu, korzystają z metod typu np:zwróćListęProduktów, zwróćProdukt itd). Może przykładowy kod (phiend) ;>]
[php:1:4e23e0d6b9]
<?php

class ActionUpdateProduct extends Action
{

function perform()
{
$data['ID'] = $_GET['ProductID'];
$data['price'] = $_POST['ProductPrice'];
$data['name'] = $_POST['ProductName'];

$product = new Product($_GET['ProductID']);
$product->updateProduct($data);
return 'ViewProduct';
}

}



class ViewProduct extends Action
{

function perform()
{
$product = new Product($_GET['ProductID']);

$data = $product->getAsArray();

// i tutaj wyświetlanie produktu
// [..]

return true;
}

}
?>
[/php:1:4e23e0d6b9]

2) A moze po prostu w modelu owszem, dopisac metody usuwania itd... a potem w kontrolerze - odpowiadające im, ale juz przekazujące identyfkatory i dane? - czy tak bedzie dobrze?

Kontroler służy jedynie do wybierania, którą akcję/widok ma 'uruchomić', tworzenia sesji, autoryzacji i sprawdzania, czy dany user ma uprawnienia do odpalenia danej akcji itp, natomiast nie ma nic wspólnego z modelem (yhm... jedynie np: mechanizm autoryzacji musi korzystać z modelu User, ale to już troche inna para kaloszy)

3) Jeszcze jedna sprawa: Tak mi sie wydaje, ze jak robie strone w MVC to:
powinien byc 1 kontroler - ktoory by wszystko tworzyl, ustawial, usuwal itd...
modele : odpowiedzialny za baze danych, odpwiednie do newsoow itd.. ,
widoki : prezentacje kazdego z modeli do newsoow itd...

Dokładnie...

Teraz tak:
czy nie powienien byc jeszcze jeden model i odpowiadajacy mu widok : np. o nazwie SiteModel i SiteView - ktoore odpowiadaly by za cala strone?
i np: SiteView to cos takiego:
[..]
Czy to jest dobre rozwiązanie?

IMHO nie bardzo... operując na MVC w stylu phiend, to zrobiłbym raczej klasę rodzica, a każdy widok aby dziedziczył po tej klasie:
[php:1:4e23e0d6b9]
<?php
Class SiteView extends Action
{

function Header()
{
// naglowek <html> itd...
}

function Footer()
{
// /html itd...
}

}

Class ViewProduct extends SiteView
{

function Display()
{
$this->header();

// tutaj inicjowanie modelu, zbieranie danych itp
// i następnie ich prezentacja

$this->footer();
}

}
?>[/php:1:4e23e0d6b9]

...albo drugie rozwiązanie (i to może być bardziej elastyczne) - zrobić widoki Header i Footer i wtedy (znowu - phiend)

[php:1:4e23e0d6b9]<?php
Class ViewProduct extends Action
{

function Display()
{
$this->_callAction('header');

// tutaj inicjowanie modelu, zbieranie danych itp
// i następnie ich prezentacja

$this->_callAction('footer');
}

}
?>[/php:1:4e23e0d6b9]

[KaGe]

Na phppatterns jest schemacik prezentuajcy MVC 2 i do tego jest śliczny kodzik źródłowy.

Mam pytanko w sprawie modelu (ProductModel) z tego kodu:
... a raczej kilka pytań:

1) Dlaczego ten model nie odpowiada pojedynczemu produktowi (wierszowi w tabeli bazy dancyh)?

2) ... można go napisać tak, żeby odpowiadał, ale wtedy możemy się pożegnać z listProducts - czyli wysłaniem żądania o kilka wierszy.... Jak sobie z tym poradzić

3) Czy można napisać taki model (np. articleModel) - który miałby też tablicę modeli np. CommentModel - i dzięki temu jakoś mógły sobie podporządkowywać Komentarze do samego siebie, dodawać usuwać itd...
np tak:
[php:1:7db2f59b24]<?php
Class Comment
{
var $data;
var $dao;

function Comment($dao)
{
$this->dao = $dao;

// Standardowa pusta tablica na dane - czy to doby pomysł?
$this->data[title] = "";
$this->data[body] = "";
}

function GetById($id)
{
$this->dao->query("SELECT * FROM comments WHERE id=".$id);
// i tu pojawia się kwestia : czy dać tu od razu, żeby uzupełnić całą pustą tablicę $data, czy też jakoś inaczej? - jakaś rada?
}

function cośtam?()
{
// i tu by sie przydało coś co wyciąga je po np. articleid
}

function ReturnComment()
{
// i teraz nie wiem czy dać
// return $this->data;
// czy też return $this->dao->GetRow();
// w zależności od rozwiązania, jak dam $this->data to mogę się pożegnać z późniejszym wykorzystaniem while($cośtam = $CommentModel->ReturnComment())
}
}

// i do tego klasa art
Class ArticleModel
{
var $dao;
var $data;
var $comments;

function ArticleModel() // tu wszystko po staremu
{
}

// KWESTIA OPISANA PONIŻEJ:

}

?>[/php:1:7db2f59b24]

Jak zrobić, żeby dało się tak przypisać klasie ArticleModel przynależność kolejnych Komentarzy w bazie, żeby ArticleModel zarówno odpowiadał artukułowi co jest w bazie jak i komentarzom, im przypisanym?

Wie ktoś może jak to rozwiązać?

O widoki nie pytam, bo to już w miare mały problem (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[marcin96]

Na phppatterns jest schemacik prezentuajcy MVC 2 i do tego jest śliczny kodzik źródłowy.

Mam pytanko w sprawie modelu (ProductModel) z tego kodu:
... a raczej kilka pytań:

1) Dlaczego ten model nie odpowiada pojedynczemu produktowi (wierszowi w tabeli bazy dancyh)?

Bo to jest tylko prosty przykład? (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) )

2) ... można go napisać tak, żeby odpowiadał, ale wtedy możemy się pożegnać z listProducts - czyli wysłaniem żądania o kilka wierszy.... Jak sobie z tym poradzić

Nalfein napisał artykuł o podstawach OOP i tam jest przykład, który myślę pomoże Ci (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) )
http://php.pl/index.php/phppl/artyku_y/apl...zanie_obiektowe

3) Czy można napisać taki model (np. articleModel) - który miałby też tablicę modeli np. CommentModel - i dzięki temu jakoś mógły sobie podporządkowywać Komentarze do samego siebie, dodawać usuwać itd...
np tak:
[..]
Jak zrobić, żeby dało się tak przypisać klasie ArticleModel przynależność kolejnych Komentarzy w bazie, żeby ArticleModel zarówno odpowiadał artukułowi co jest w bazie jak i komentarzom, im przypisanym?

Wie ktoś może jak to rozwiązać?

Artykuły nie muszą nic wiedzieć o komentarzach - po co? Jedynie przy usuwaniu artykułu przydałoby się automatyczne usuwanie komentarzy... ale tutaj może się przydać wzorzec observer - zerknij na www.phppatterns.com . Jeśli zaś chodzi o komentarze, to wystarczy znać id artykułu, a klasa Comments już będzie posiadać metodę getCommentsByAID.

Jeśli zaś chodzi o kod, to chyba w artykule Nalfeina znajdziesz odpowiedzi na pytania (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) )

[KaGe]

Mam problem. Chciałbym zapisywać i dodawać, szukać itd... dane w bazie na tej zasadzie, ze przekazuje nie Id, czy jakis jeden paramentr a cala tablice odpowiadajaca zawartosci danego modelu w bazie. czyli np:

ArticleModel i ArticleDataModel - gdzie ArticleDataModel jest obiektem generującym tablicę zawierającą dane artykułu. Później w ArticleData dodać metodę SaveByData($data), gidze $data to instancja ArticleDataModel i zawiera dane, które mają być zapisane. TAk samo z dodaniem. ArticleDataModel będzie mógł być tworzony bezpośrenio z formularza - co wy na to?
jak to rozwiązać?

[hawk]

Nie rozumiem :? ArticleDataModel i ArticleModel mają odpowiadać obiektowi Article i kontenerowi artykułów? Sugerowałbym wywalenie tego Model z nazwy klasy, bo ono tam nie pasuje a nikt nie powiedział że klasa należąca do Modelu musi mieć to w swojej nazwie. Nazwa klasy powinna odzwierciedlać jej przeznaczenie i być prosta, jasna i oczywista.

[KaGe]

Więc w takim razie przedstawie ten problem tak:

[php:1:22b83270b7]<?php
Class ArticleData
{
var $data = array(
art_id => null,
art_title => null
); // i tak dalej z całą resztą

function ArticleData($data=array())
{
foreach($data as $key => $value)
{
if ($data[$key] != "")
{
// tu następuje przepisanie danych z tablicy data - np. z formularza
// do tablicy tej klasy
$this->data[$key] = $data[$key];
}
}
}

function ReturnAsString()
{
$str = array();
foreach($this->data as $key => $value)
{
if (!is_numeric($value))
{
$value = "'$value'";
}
$str[] = "$key=$value";
}
return implode(" AND ", $str);
}
}

Class Article
{
// konstruktor itd...

function GetByData($data)
{
$this->dao->query("SELECT * FROM articles WHERE ".$data->ReturnAsString());
}
}

?>[/php:1:22b83270b7]


I teraz tak:
Article i ArticleData są właściwie wogóle nie związane - ArticleData jest tworzone np. tak, że jako argument podawana jest zawartość fomularza - klasa sama wie co ma sobie wziąć ;. ArticleData będzie tworzona w widokach i przekazywana do modelu Article jako argument dodawania, wyciągania z bazy itd...

Czy to jest dobre rozwiązanie? Może zaproponuje ktoś coś lepszego?

[hawk]

Hmm, zaczynasz od końca... co nie jest jakąś szczególną krytyką bo to jest raczej powszechne.

Bo przedstawiasz kod, a kod dużo mówi na temat algorytmów i sposobu implementacji, a mało o projekcie i założeniach jakie system miał spełniać.

Po co są klasy Article i ArticleData? Nazwa ArticleData jest myląca, bo nie wiadomo czym to się różni od Article. Piszesz że nie są związane, a potem że ArticleData jest przekazywane do Article jako argument - to jest asocjacja, nawet jeżeli tylko <<uses>>.

Dyskusja na odpowiednio wysokim poziomie abstrakcji jest bardzo trudna i często nie kończy się niczym konkretnym. Ale dyskusja na nie zdefiniowanym poziomie abstrakcji jest jeszcze gorsza.

Jest różnica pomiędzy OOP a OOD, tak jak pomiędzy programowaniem a projektowaniem w ogólności, a wątek w końcu jest o wzorcu projektowym :wink: . Mam nadzieję że nie zamieszałem zbytnio (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) .

[KaGe]

"Dyskusja na odpowiednio wysokim poziomie abstrakcji jest bardzo trudna i często nie kończy się niczym konkretnym. Ale dyskusja na nie zdefiniowanym poziomie abstrakcji jest jeszcze gorsza. " - chodzi mi tylko o to, czy takie przekazywanie danych jest wogoole przyjmowane za "poprawne" ? - jeśli jest to ok - będe tak pisał całą stronę, jeśli nie to trudno... - trzeba poszukać lepszego rozwiązania

[Balin]

Ja mam pytanie o cos innego.
Wiadomo, ze niektore akcje moga zostac wykonane, jesli uzytkownik ma odpowiedni poziom (np. usuwanie newsow tylko przez admina) - jak to dobrze przeprowadzic w aplikacji wzorowanej na mvc ?
Czy sprawdzaniem poziomu uzytkowanika ma zajmowac sie kontroler, czy tez modul artykulow powinien zarzadac wiadomosci o poziomie usera ?

[gkeb]

Ostatnio troche dumałem nad MVC i w związku z tym mam pytania. Zaznaczam że jestem w tym temacie poczatkujący (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

1. Chodzi mi o przeplyw informacji między Kontrolerem Widokiem i Modelem. Zakładam, że każdy z nich to osobna klasa z czego Kontroler jest nadrzędny. Kontroler na podstawie danych z Inputa wywołuje odpowiednie metody z Modelu. Czy Model przekazuje dane zwrotne klasie Kontrolera czy bezpośrenio Widokowi?

2. Czy Model może samodzielnie pobierać dane (np. konfiguracji) z Kontrolera czy też lepiej w trakcie tworzenia klasy Modelu przez Kontroler wysłać wszystkie niezbędne dane potrzebne do pracy (login, hasło do db itp.)?

3. Rozumiem że Widok jest typu Output i nie powinien nic wysyłać do Kontrolera.

Na pewno namieszałem (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

[Zepco]

1. Z tego co ja już zdążyłem się zorientować, to np. w przypadku wyświetlania kontroler wywołuje widok, który wyciąga dane z modelu i "wyrzuca" je na wyjście.

3. Widok może wysłać do kontrolera żądanie wywołania innej akcji, ale nie powinien mieć wpływu na zmianę danych w modelu i kontrolerze.

[rmn]

kurcze od jakiegos czasu probuje dowiedziec jak 'to' robic w mvc;) Zaczelo sie od artykuly na php.pl. Potem napisalem nawet sporo kodu w oparciu o to co zrozumialem. Nie wiem tylko jak zweryfikowac to czy to co napisalem faktycznie mozna opatrzec etykietka mvc... Jest tak dlatego, że

każdy pisze coś innego (IMG:http://forum.php.pl/style_emoticons/default/ohmy.gif)

Jedni twierdza ze pewne rzeczy powinien robic kotroler inni ze nie; ze model(instancja) powiniene byc przekazywany jako parametr do widoku, inni ze absolutnie nie tak itd... Generalnie widze same sprzecznosci i dochodze do wniosku ze tak naprawde idea mvc jest bardzo ogolnym spojrzeniem na zagadnienie projektowania aplikacji i nie dostarcza konkretnych rozwian do wielu problemow tutaj poruszanych:/ a ew dywagacje na te tematy wprowadzaja straszne zamieszanie?

czy ktos ma podebne odczucia?

[Ozzy]

MVC jest dobre, ale....w Javie:) Przykład: Swing, widok zmienia się w zależności od platformy lub "wyglądu i wrażenia". Sterowniki przechwytuje zdarzenia, a model przechowuje dane komponentu. W takim przypadku stosowanie MVC wydaje się uzasadnione, jednak w php, gdzie każda dodatkowa klasa wydłuża czas generowania strony, próby używania MVC na siłę, tylko po to, by być "trendy" wyraźnie mija się z celem. Może niektórym nie spodoba się to co napisałem, jednak taka jest moja opinia na dzień dzisiejszy:)

[Ace]

Tak, tez mam takie wrazenie. Wyszedlem z zalozenia ze MVC [ model view controler ] mozna bardziej luzno potraktowac. Jesli ty piszesz swoj MVC, to zapewne bedziesz mial w planie rozszerzac jego mozliwosci, a wiec to na ogol ty bedziesz go pisal/rozszerzal. Wiec na poczatku wychodzisz z glownego zalozenia, musi byc MODEL, WIDOK , i KONTROLER tego wszystkiego. Reszta wedlug mnie to kwestja sporna. Fakt, ze Widok nie powinien edytowac danych, tylko je wyswietlac, nie ma nic wspolnego z tym, ze nie moze zarzadac zmiany danych przy Modelu. Teraz tez pisze aplikacje na podstawie zalozen MVC, najgorszy jest pomysl. Siedze juz dluzszy czas przy kontrolerze, zeby wyszedl elastyczny/latwy do edycji, modyfikacji... Dlatego skupie sie dluzej na kontrolerze... Pozniej Model, oraz glowne zalozenia, jakie maja spelniac akcje, prawa dostepu/autoryzacjia... I widok. Calosc nastepnie trzeba rozszerzac o dodatkowe moduly/akcje.

[gkeb]

Tak sobie dumam i dumam i.... :

koncepcja 1:
1.wywolany jest index.php;
2.index uruchamia klase kontroler wraz z wszystkimi parametrami (dane z adresu URL, i inne potrzebne);
3.Kontroler przekazuje informacje do klasy modelu w celu wykonania odpowiedniej akcji z danych pobranych z kontrolera(informacje dla akcji jak i do przekazania widokowi);
4.model przesyla wynik do klasy widoku wraz z danymi niezbednymi do wyswietlenia a uzyskanymi od kontrolera;
5.widok generuje odpowiedni szablon z danymi z modelu.

koncepcja 2:
1.wywolany jest index.php;
2.index uruchamia klase kontrolera wraz z parametrami
3.Kontroler przekazuje niezbedne informacje (tylko i wylacznie dane potrzebne do uzyskania danych z modelu) klasy modela w celu wykonania odpowiedniej akcjii z danych pobranych z kontrolera;
4.model przesyla wynik do klasy kontrolera;
5.kontroler przekazuje dane do widoku (te uzyskane z modelu jak i inne wymagane do poprawnego wyswietlenia)
6.widok generuje odpowiedni szablon z danymi z modelu.

czy ktoras z tych koncepcji jest prawidlowa?? czy moze jeszcze inaczej to powinno wygladac?
wiem ze pewnie namieszalem ale czlowiek stale sie uczy (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ciagle sie uczy

[marcin96]

Żadna nie jest ;>)

1. index[*] odpala kontroler
2. kontroler sprawdza sobie url, parametry itp i na tej podstawie odpala akcje (wcześniej moża wrzucić jakieś sprawdzanie autoryzacji i praw dostepu do danej akcji)
3. akcja operuje na klasach modelu niezależnych[**] od widoków, akcji, kontrolera...
4. wynik wykonania akcji przekazywany jest do widoku
5. na podstawie danych z akcji widok wypluwa wynik na ekran/ przesyla gdzies indziej xml itp

[*] nie musi być tylko jeden 'wyzwalacz' kontrolera.. można zrobić kilka wyzwalaczy, każdy będzie operował na tych samych bibliotekach itd, ale dzięki temu można zrobić kilka różnych wersji konfiguracji - rozbicie aplikacji na mniejsze, niezależne od siebie/mniej zależne od siebie

[**]dlaczego podkreśliłem niezależnych? Dzięki temu gdy w przyszłości będziemy chcieli zmienić framework obsługujący aplikację modelu nie będziemy musieli nawet ruszać.. i w drugą strone - jeżeli mamy już jakiś gotowy model, a chcemy 'ożywić' go za pomocą MVC, to właśnie ta separacja pozwala nam bezproblemowo to uczynić.

Zależności między widokami/kontrolerem/akcjami i częscią autoryzującą wykonanie akcji/widoku oraz jak odseparować to od modelu.. to już inna bajka, zostało to całkiem fajnie poruszone w temacie 'jak pisać jądro...': http://forum.php.pl/index.php?showtopic=13770

Ten post edytował marcin96 26.07.2004, 00:01:00

[gkeb]

Hehe (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Wiedziałem ze sie myle (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

W mojej koncepcji chcialem by wszystko bylo wprowadzone do kontrolera jako parametry by potem juz ani kontroler ani model ani widok nie korzystaly z tablic GLOBAL. Czy to ma sens?
Zastanawia mnie koncepcja wielu kontrolerów. Jakby to miało wyglądac?
Jeżeli chodzi o akcje to też sobie podobnie wymyśliłem, tzn.: sam model to klasa ktora jest interfejsem wywołującym konkretną akcje (każda akcja to osobna klasa w osobnym pliku).Czy tak może być?

[hawk]

Oczywiście że model nie powinien korzystać z żadnych globalnych tablic, bo nie ma tam nic co mogłoby być mu potrzebne. Natomiast ciekawe jak napiszesz kontroler który w ogóle nie rusza tablicy $_POST, chociażby bo to aby gdzieś przepisać jej zawartość (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) .

Po co ci wiele kontrolerów? Chyba że mówimy o Page Controller, ale MVC raczej operuje na jednym, centralnym kontrolerze.

Jeżeli chodzi o model i akcje to ni <męski narząd moczowo-płciowy> nie mogę nic z tego wyrozumieć. "model to klasa ktora jest interfejsem wywołującym konkretną akcje"? Klasa nie jest interfejsem, to raz. Dwa, że obiekt modelu absolutnie nie powinien wywoływać metody obiektu akcji. Jak by to miało wyglądać? No chyba że mówimy o listenerze w Smalltalku/Swingu, ale to inny MVC niż w php i raczej nie o to nam chodzi (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) .

BTW, dlaczego z MVC jest tyle zamieszania? Mi się wydaje że to bardzo naturalny sposób tworzenia aplikacji, i jakby nie był wymyślony, to i tak ludzie sami z siebie by do tego doszli (IMG:http://forum.php.pl/style_emoticons/default/blink.gif) .

BTW2, Marcin wyrasta nam na eksperta od MVC, który nie tylko wie co i jak ale i potrafi to łopatologicznie wyjaśnić (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

----------------------------------------
Grr, dlaczego nie mogę dać 2 odpowiedzi pod rząd? (IMG:http://forum.php.pl/style_emoticons/default/aaevil.gif)
@Ozzy:
IMHO to nie tak. MVC w Swingu sporo różni się od tego w php, bo inny jest model interakcji. Więcej, MVC w Swingu różni się od tego w JSP i Struts, z takich samych powodów.
Natomiast używanie MVC na siłę oczywiście jest stratą czasu. Zwłaszcza w php gdzie wczytywanie kolejnych klas jest tak popieprzone jak jest. php na ogół stosowane jest do prostych serwisów. Serwisy banków już raczej w JSP. Dlaczego? Bo php jest zbyt prymitywny do tego celu. Jeżeli php dalej ma się rozwijać do Personal Home Page, to nie ma problemu, można sobie zlać MVC, wzorce i w ogóle wszystko to co wprowadzili w PHP5 bo bez tego też się da. Ale całe te zmiany idą (chyba) w kierunku uczynienia z php dobrego języka na poziomie "enterprise". I wtedy Smarty przestaje wystarczać, i trzeba pomyśleć np. o modyfikowalności itd.

[gkeb]

Co do wielu kontrolerow to zauwaz ze to Marcin wlasnie napisal a ja stwierdzilem ze jest to do przemyslenia (IMG:http://forum.php.pl/style_emoticons/default/aaevil.gif)
Co do modelu i akcji to chyba nie zakumalem od razu i dopiero teraz do mnie dotarlo (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) W poprzednim rozumowaniu (dodam ze blednym (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ) uznalem ze kontroler wywoluje model a dopiero ten wywoluje odpowiednia akcje - zakladalem ze jest jeden model, wiele akcji. Prawidlowo to jest tylko jeden kontroler a wiele modeli i tu tkwi moj blad (zgadza sie??)
Co do zamieszania przy MVC to zauwaz ze kazdy jakos inaczej pisze i jak ktos dopiero zaczyna zabawe z tym (tak jak ja) to moze sie troche pogobic.

[hawk]

Z tymi wieloma kontrolerami to Marcin raczej pisał (IMHO, nie chcę nic imputować) o wielu konfiguracjach. Nie możesz odpalić na raz dwóch kontrolerów, ale możesz mieć kilka wersji konfiguracji, albo kilka aplikacji na jednym serwerze, itd.

Co do modelu, to generalnie jest takie permanentne zamieszanie. Bo co to jest model? Zbiór klas. Więc co to znaczy "wywołać model"? No nie wiadomo. O ile kontroler jest pojedynczym obiektem i może coś wywoływać, o tyle w przypadku modelu możemy mówić o konkretnym obiekcie należącym do modelu, który coś robi. A cały model to logiczna część aplikacji a nie jakaś fizyczna rzecz. Więc nawet nie ma sensu mówić że jest "jeden model" lub "wiele modeli". To tak jak jedna pamięć/wiele pamięci, jedna policja/wiele policji, itd. Bez sensu. Niepoliczalne. Klasy modelu już są policzalne.

Jak dla mnie, to w tych dyskusjach nad MVC ciągle są wątpliwości co do szczegółów, a brakuje jakby zrozumienia idei. Że chodzi o sensowne zaplanowanie aplikacji i nieważne czy jest "jeden model", czy 50, ale ważne że sterowanie idzie od kontrolera do modelu a nie w drugą stronę. Bo inaczej to nie ma sensu. Takie rzeczy jakoś mało się rzucają w oczy w php. Znacznie bardziej w zwykłych, okienkowych aplikacjach. MFC jest oparte o MVC, AWT i Swing też. Spróbuj zrobić aplikację na chociaż kilkanaście tysięcy linii kodu bez separacji dokumentu od widoku. Wychodzi z tego wielki syf który nie wiadomo jak działa i dlaczego w ogóle działa. A w php jakoś się daje sklecić system, wydajność jest ważniejsza od jakości i nie czuć tych problemów.

[marcin96]

Z tymi wieloma kontrolerami to Marcin raczej pisał (IMHO, nie chcę nic imputować) o wielu konfiguracjach. Nie możesz odpalić na raz dwóch kontrolerów, ale możesz mieć kilka wersji konfiguracji, albo kilka aplikacji na jednym serwerze, itd.

otototo.. wiele wyzwalaczy kontrolerów, a nie wiele kontrolerów.. czyli np możesz mieć powiedzmy trzy wyzwalacze:

sklep.php
hurtownia.php
costamjeszcze.php

...wszystko będzie działało na tych samych klasach, ale będą inne konfiguraje odpalone. Tutaj mamy jedną witrynę podzieloną na trzy niezależne aplikacje korzystające z tych samych klas/bibliotek etc. Po co osobne konfiguracje? A po co hurtownia ma wiedzieć jakie są akcje dostępne w sklepie oraz na odwrót?

Oczywiście nie we wszystkich przypadkach jest sens tak robić... ale czasem takie myślenie może się przydać (np: gdy korzystając z phienda zaczyna nam się konfig niebezpiecznie rozrastać ;>)) )

BTW2, Marcin wyrasta nam na eksperta od MVC, który nie tylko wie co i jak ale i potrafi to łopatologicznie wyjaśnić

A tam.. po prostu uważnie prześledziłem manual phienda ;>)P

[aleksander]

witam,

więc bez zbędnych wstępów parę pytań:

1. nie wiem czy dobrze rozumuje: model to czesc programu, ktora jest posrednikiem pomiedzy DB a widokiem/akcja. wykonuje ona zapytania, wstawia dane i je zwraca ( w czystej postaci). dobrze rozumuje??

2. czy dla skryptu forum (ktory wlasnie chce zaprojektowac w oparciu o MVC) cos takiego bedzie poprawne:

a) dla wyswietlenia tematow

- kontroler ustala, ze przegladarka chce zobaczyc topiki. wywoluje widok 'showforum($forumid)'
- widok wywoluje model 'showforum($forumid)' ktory zwraca dane z bazy danych w czystej postaci (tablica)
- widok obrabia te dane, i przekazuje wynik do szablonow

(IMG:http://forum.php.pl/style_emoticons/default/cool.gif) dla wstawienia postu

- kontroler ustala ze przegladarka chce dodac posta. wywoluje akcje 'addpost'
- akcja wywoluje model 'addpost' ktory tylko robi polecenie insert i zwraca, czy udalo sie wstawic posta
- ta sama akcja po udanym wstawieniu wywoluje widok 'showtopic($topicid)'
-widok wywoluje model 'showtopic($topicid)' ktory zwraca dane z bazy w czystej postaci (tablica)
- widok obrabia te dane i przekazuje je do szablonow (smarty)

3. zamierzam wszystkie metody (nawet takie standardowe jak showtopic, showforum itp) umiescic jako moduły. Czyli taki moduł powinien składać się z modelu i widoku/akcji ?

[bela]

1. nie wiem czy dobrze rozumuje: model to czesc programu, ktora jest posrednikiem pomiedzy DB a widokiem/akcja. wykonuje ona zapytania, wstawia dane i je zwraca ( w czystej postaci). dobrze rozumuje??

to o czym myslisz to raczej DAO

2. czy dla skryptu forum (ktory wlasnie chce zaprojektowac w oparciu o MVC) cos takiego bedzie poprawne:

a) dla wyswietlenia tematow

- kontroler ustala, ze przegladarka chce zobaczyc topiki. wywoluje widok 'showforum($forumid)'
- widok wywoluje model 'showforum($forumid)' ktory zwraca dane z bazy danych w czystej postaci (tablica)
- widok obrabia te dane, i przekazuje wynik do szablonow

- kontroler wywołuje akcje showtopic
- akcja wywołuje model
- widok odpowiada za wyswietlanie np. Smarty

3. zamierzam wszystkie metody (nawet takie standardowe jak showtopic, showforum itp) umiescic jako moduły. Czyli taki moduł powinien składać się z modelu i widoku/akcji ?

moduł to raczej logiczny zbior akcji

[matid]

A czy taki przebieg pracy aplikacji jest zgodny z modelem MVC?

• Tworzymy instancję Kontrolera
• Kontroler pobiera dane od Routera sparsowane dane _POST, _GET oraz _SESSION i na podstawie tych danych określa jaką akcję którego modułu ma wykonać (powiedzmy folder 'maths' plik 'mnozenie.action.class.php' i metoda 'execute();' albo plik maths.class.php, metoda 'mnozenie();' BTW który z tych sposobów wydaje się wam lepszy? )
• Akcja wykonuje jakieś operacje logiczne (np. w akcji, która za zadanie miałaby pomnożyć liczby, akcja by za to była odpowiedzialna) i przesyła odpowiednie dane do odpowiedniego widoku (np. mnozenie.view.class.php)
• Widok określa czy potrzebuje jeszcze jakiś danych, jeśli tak to pobiera je od modelu (np. $model->getData(); - tutaj pytanie - jak akcja powinna pobierać dane od modelu? Rozumiem, że nie ma być to kod SQL ale w takim razie jak uniezależnić to co chcemy pobrać od tego, w jaki sposób jest to przechowywane)
• Model korzysta z abstrakcji odpowiedniego źródła danych, pobiera te dane i wysyła je spowrotem do Widoku
• Widok zbiera te wszystkie dane do kupy i przekazuje do systemu szablonów.
• System szablonów parsuje dane pobrane od widoku na kod HTML i przesyła spowrotem do Widoku.
• Widok wysyła te dane w odpowiednie miejsce: np. przeglądarka, albo jakiś cache.

Tak w zasadzie wygląda moja koncepcja. Jak widać nie ma jednej klasy Widoku, jest ich wiele, natomiast Model i Kontroler jest tylko jeden.
Oczywiście to jest prosty przykład, bez żadnych łańcuchów, ale chciałbym wiedzieć, czy ta idea jest dobra, a jeśli nie to co w niej wymaga poprawienia.

[aleksander]

ale teraz wywiązuj się pytanie: jeżeli dodam nową funkcjonalność do aplikacji (powiedzmy wyświetlanie userów) to oprócz widoku, który przetwarza dane z modelu, musze także dodać model odpowiedzialny za wyciągnięcie odpowiednich danych z bazy i przekazanie w czystej postasci widokowi. czy tak?

[ActivePlayer]

Nie wiem czy moja idea jest dobra ale czy mozna najpierw pobrac dane z GET POST i SESSION, potem wg nich stworzyc lancuch akcji a potem w petli while je wykonac (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) oczywiscie ostatnią akcją byłoby wyswietlenie odpowiedniego widoku ...(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)

[matid]

ale teraz wywiązuj się pytanie: jeżeli dodam nową funkcjonalność do aplikacji (powiedzmy wyświetlanie userów) to oprócz widoku, który przetwarza dane z modelu, musze także dodać model odpowiedzialny za wyciągnięcie odpowiednich danych z bazy i przekazanie w czystej postasci widokowi. czy tak?

Nie. W moim rozumowaniu model dostaje od widoku zapotrzebowanie na jakieś dane. Pobiera te dane i wzraca je widokowi. Niezależnie od tego jakie zadanie ma wykonać akcja Model pozostaje ten sam i służy za pośrednik pomiędzy aplikacją a źródłem danych. Takim źródłem danych może być baza danych obsługiwana przez klasę abstrakcji.

Prosiłbym o wypowiedź kogoś obeznanego w tych tematach i o poprawienie moich ew. błędów w rozumowaniu.

Ten post edytował matid 30.10.2004, 21:31:16

[aleksander]

no tak, ale jeżeli nowy widok bedzie kozystal z nowej tabeli w db to skad model ma o niej wiedziec, a jak ma stworzyc odpowiednie zapytanie zwracajace odpowioednie dane?

[dag]

ArticleModel:
- dodaj
- edytuj
- usun
- get title
- get author
- get body



ArticleView:
pobiera z modelu ArticleModel -> get title, get author, get body, formatuje i wyswietla


AddArticleAction:
dodaje za pomoca ArticleModel -> dodaj

W ten sposób mamy obiektowość. Można by było zrobić każdą metodę ArticleModel jako osobny model ale po co??

Co sądzicie?

[hawk]

@ogólnie:

Nie ma sensu zastanawiać się, czy model jest jeden, dwa czy dwadzieścia. Model to tylko warstwa. To tak jakby mieć dwie warstwy bazy danych. Można mieć dwie bazy danych, ale obie należą do warstwy bazy danych. Masłomaślanizm powyższego dowodzi, że mówienie o modelach jest bez sensu.

Ja jestem przeciwny jakiemuś akcentowaniu w nazwach itd. że mamy do czynienia z modelem. Po prostu klasy Article, User, itd. Cała zabawa polega przecież na tym, żeby model był odseparowany od HTTP i innych okropności. Żeby był to ładny, elegancki projekt obiektowy (OOD), bez zawiłości protokołów, sesji, itd. Więc nie żadne $model->getData(), nie żadne metody modelu, tylko po prostu $articleContainer->getArticleById(12345) itd.

A nazywanie klasy ArticleModel jest niekorzystne z tego powodu, że skoro model jest odseparowany od całej reszty, to też nie wie nic o kontrolerze i o MVC. Jak tworzę klasę do artykułów, to nazywam ją Article. Jak tworzę klasę do artykułów w aplikacji MVC, to powinienem postępować tak samo jak poprzednio. W końcu o to chodzi w MVC.

@dag:

To już zagadnienie nie MVC, tylko ogólnie OOD, ale podane przez ciebie metody do Article(Model) są złe. Tzn nie złe z punktu widzenia modelu, tylko złe z punktu widzenia hierarchii klas. Jeżeli są sobie artykuły, to logiczne jest, że potrzebuję klasy Article. Ale potrzebuję też kontenera artykułów. Inaczej się nie da tego sensownie zrobić. Jeżeli mam zbiór artykułów (a przecież mam), to ten zbiór musi być "czymś", czyli musi mieć obiekt. A jak obiekt to i klasa. Kontener. Na tym etapie też robi się tzw. projekt trwałości, czyli po ludzku zaznacza, co siedzi w bazie danych (artykuły). I kontener je wyciąga.

[Vengeance]

hmm no tak w MVC nigdy nie wnikalem ale teraz moje podstawe pytanie nie odnosi sie w sumie tylko do MVC.

jeden Artykul obrazuje klasa Article powiedzmy

[PHP] pobierz, plaintext 
<?php
 
class Article
{
   var $author, $title, $content;
}
 
?>
[PHP] pobierz, plaintext 

Teraz hawk mowisz o kontenetrze. Czyli on trzyma kolejne instancje klasy Article (czyt. kolejne artykuly). Pytanie on trzyma wszyskie arty czy np. tylko 10 (bo powiedzmy porcjowanie wynikow na www jest co 10 artow). I czy pobieranie do niego danych polega na tym
ze z bazy sql pobieramy wszystkie rekordy, w petli tworzymy kolejne obiekty klasy Article uzupelniajac je danymi a potem wkladamy je w ten kontener. Chyba zle to rozumiem bo to zbyt ergonomiczne nie jest ;]

[hawk]

Zaczynamy od tego, że mamy ten Article tak jak w twoim kodzie. Wyszukiwanie artykułów nie jest zadaniem dla samego artykułu, więc potrzebujesz coś do tego. Kontener. Manager. Jak zwał tak zwał. Nie chodzi o to, żeby ten kontener trzymał 10 czy 100 artykułów, tylko żeby umożliwiał do nich dostęp. A to, że artykuły są w bazie, i że jest jakiś SQL, to jest jego wewnętrzna sprawa.

Pewnie, może sobie wszystkie wczytać i przechowywać, ale to będzie mało wydajne.

Popatrz na to z punktu widzenia MVC. Nie możesz do akcji wrzucić zapytania SQL, które wyciąga artykuły, bo to jest Model. Więc gdzieś to zapytanie musi się znajdować, i to najlepiej w jednym miejscu. Nie może znajdować się w klasie Article, bo musiałbyś stworzyć artykuł a potem go wyciągać - masło maślane. No chyba że w metodzie statycznej, wtedy klasa Article pełni podwójną funkcję. Więc potrzebujesz osobną klasę która potrafi wyciągać artykuły.

Dobrze jest sobie popatrzyć na dostępne systemy DAO, takie jak Turbine/Propel etc. Chociaż tam akurat rozwiązali to poprzez metody statyczne.

[bela]

hm dzis sobie w szkole myslałem o mvc i narysowałem taki oto "projekt"

Kod

           |-----------|
           | 2.Router  |
           |-----------|
              |    |
          3.  |    | 1.
              |    |
           |-----------| 10.|----------|
           | Kontroler |--->|  Widok   |
           |-----------|    |----------|
              |    |
           4. |    | 9.
              |    |
           |-----------|
           | 8.Akcja   |
           |-----------|
              |    |
           5. |    | 7.
              |    |
           |-----------|
           |   Model   |
           |-----------|
              |    |
              |    |
              | __ |
              6.DB

1. Kontroler odwołuje się do Router
2. Router parsuje URL i wyciąga z niego nazwe akcji
3. Nazwa akcji jest przekazywana do Kontrolera
4. Kontrole wywołuje akcje
5. Akcja odwołuje się do Modelu
6. Model odwołuje się do DB
7. Model zwraca dane
8. Akcja operuje na danych z Modelu
9. Akcja zwraca przetworzone dane do Kontrolera
10. Kontroler wywołuje Widok
11. Widok zwraca dane do USER_AGENTa

Niech ktoś skoryguje błedy (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

I teraz mam pare pytań:
1. Dotyczy punktów od 9. wzwyż, czy dan są przekazywane przez Kontroler do Widoku czy bezpośrednio z Akcji ?
2. Gdzie są trzymane dane o akcjach ( we Phiendzie w pliku XML, ale jaka jest sensowna alternatywa )
3. Jak są generowane linki (IMG:http://forum.php.pl/style_emoticons/default/dry.gif)
4. Jeżeli dane są przesyłane przez Kontroler do Widoku, to w jakiej formie no przepływają ?
5. Jak sensownie rozwiązać kwestie szablonów ? Wiadomo, że szablon dla artykułów różni się od szablonu forum
6. @hawk skąd ty brałeś informacje (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[hawk]

1. Ja bym to zrobił tak, że Widok może dostać dane bezpośrednio od Modelu. Tzn normalnie pobiera dane. Pamiętając o tym, że nie wolno mu niczego modyfikować, ale nie da się tego wymusić przez jakieś zabronienie dostępu.

2. Hmm, gdzie? Można w pliku ini. Można w wielkiej tablicy php (np. phrame). Można mieć wszystko hard-coded w kodzie akcji (np. mojavi). Nie widziałem jeszcze sensownego systemu, gdzie to wszystko siedziałoby w bazie danych, ale jest to niegłupie rozwiązanie - ułatwia zarządzanie akcjami.

3. Jak chcesz. To jest niezależne od MVC. Ale po to wymyślałem router, żeby był obiekt odpowiedzialny za tworzenie linków (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

5. -

6. Szablony są niezależne od MVC. Klasa Widoku to w końcu tylko klasa. Jaki szablon ma w środku, to już jej sprawa, i reszcie aplikacji nic do tego.

7. Jestem genialny (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) . Serio, w sumie to nie wiem. phparchitect. sitepoint. phrame. Polecam też materiały Suna i Microsoftu na temat MVC i takich. Oni to mają trochę lepiej uporządkowane.

A router to wyszedł tak sam z siebie, i nie ma go ani w Javie, ani w .NET.

[DeyV]

Ja bym to zrobił tak, że Widok może dostać dane bezpośrednio od Modelu.

Ja zazwyczaj komunikację pomiędzy modelem a widokiem sprowadzam do tego, że w akcji pobieram jakieś dane z modelu, które przesyłam do widoku, który je jakoś iteruje i wyświetla.
Skoro jednak w php5 mamy swietną obsługę iteratorów, pozwalającą na pełną symulację tablicy przy pomocy obiektu, to często najlepszym sposobem, jest właśnie pobranie od modelu iteratora (który w sumie również jest częścią modelu) i przesłanie go do widoku.
Oczywiście - dzięki temu zyskujemy nie tylko wydajność - (zamiast przechowywać dane w tablicach, można je "na żywo" pobierać z bazy), ale również upewniamy się, że widok nie będzie nam w żaden sposób 'wpływał' na model.

Ale po to wymyślałem route

heh - Ty go tylko ładne nazwałeś (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
Patern pozwalający na pobieranie nazwy wykonywanej akcji z adresu jest jednak chyba nieco starszy niż phiend...

[hawk]

@DeyV: ale phiend wcale nie ma routera. Ba, nie znam żadnego obecnie funkcjonującego frameworka, który ma router. Owszem, wszędzie przejawia się koncepcja, że z URLa trzeba wyciągnąć nazwę akcji, i jakiś kawałek systemu się tym zajmuje. Niektóre systemy dają tutaj kilka możliwości (index.php?page=foo, index.php/foo, itd). Np. phiend daje kilka możliwości.

Ale nie o to chodzi. Chodzi o to żeby wywalić tą funkcjonalność poza kontroler. Zrobić takie MVCR. I to mi daje dużą elastyczność bo mogę router wymieniać nie ruszając reszty systemu.

A co do wymyślania i nazywania - w sumie to bez znaczenia. I tak nikt routera nie patentuje (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) .

[Vengeance]

to moze trzeba opatentowac (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) bill ci opatentowal podwojne klikniecie to i my mozemy (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[bela]

1. Ja bym to zrobił tak, że Widok może dostać dane bezpośrednio od Modelu. Tzn normalnie pobiera dane. Pamiętając o tym, że nie wolno mu niczego modyfikować, ale nie da się tego wymusić przez jakieś zabronienie dostępu.

no to już całkiem się zakręciłem (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

jezeli dane są bezpośrednio wysyłane z Modelu do Widoku to jaki sens akcji ?

[dag]

bela_666 @ przeczytaj dokładnie artykuł o MVC na php.pl.

Akcja to np. dodawania usera, usuwanie artykułu.

Widok wyświetla, jak sama nazwa wskazuje czyli to co widzimy ;-). Wytłumaczone łopatologiczne, tak na chłopski rozum ;-) lepiej masz wszystko opisane w artykule.

[bela]

bela_666 @ przeczytaj dokładnie artykuł o MVC na php.pl.

Akcja to np. dodawania usera, usuwanie artykułu.

Widok wyświetla, jak sama nazwa wskazuje czyli to co widzimy ;-). Wytłumaczone łopatologiczne, tak na chłopski rozum ;-) lepiej masz wszystko opisane w artykule.

przeczytałem, przeanalizowałem i znalazłem błąd (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

z tego co zrozumiałem jezeli dane sie nie zmieniają / są tylko pobierane to akcje nie istnieją, jeżeli są jakies operacje na danych to w gre wchodzą akcje, w drugim miejscu jest napisane że model jest odpowiedzialny za zmiene danych, pogubić się można (IMG:http://forum.php.pl/style_emoticons/default/dry.gif) a wiec jak są rozróżniane zapytania wymagające i nie wymagające akcji ?

[aleksander]

zapytania nie wymagające akcji: SELECT
zapytania wymagające akcji: UPDATE, INSERT

(IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) :D:D

[hawk]

@Bela:

Lepiej nie mówmy o zapytaniach, bo w MVC wcale nie musi być bazy danych. A zwłaszcza nie powinno być tego widać w akcjach i w Widoku.

W moim artykule był taki ładny schemat działania MVC, ale chyba się nie wyświetla (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) .

Powinno być tak:

1) Zawsze uruchamia się akcja, która robi wszystkie zmiany w Modelu (addUser, deleteUser, modifyUser, blah, blah).
2) Akcja zawsze podaje, jaki widok uruchomić
3) Zawsze uruchamia się widok, który wyciąga z Modelu potrzebne dane i wyświetla je, bez zmieniania niczego

Czyli w najprostszym przypadku (tylko wyświetlamy coś) akcja nic nie robi, poza wskazaniem widoku. Inna sprawa, czy chce nam się robić klasy dla takich jednolinijkowych akcji, ale tak wygląda oficjalny MVC. Zawsze jest akcja - widok. Tak więc nie ma żadnego rozróżniania zapytań wymagających i nie wymagających akcji. Zawsze jest akcja, a jak ta akcja nic z siebie nie robi, to już jej sprawa.

Tak na marginesie, w phiendzie zrobiłem tak że w zdegenerowanym przypadku bez żadnych modyfikacji można przejść od razu do widoku, bez wywoływania "pustej" akcji. Tylko że to się nazywało "logic action" i "view action". Tak też można, ale ze świadomością, że naginamy wzorzec żeby poprawić wydajność.

[bela]

Lepiej nie mówmy o zapytaniach, bo w MVC wcale nie musi być bazy danych.  A zwłaszcza nie powinno być tego widać w akcjach i w Widoku.

W moim artykule był taki ładny schemat działania MVC, ale chyba się nie wyświetla (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) .

1. wiem, ze nie musi byc to baza

2. na szczescie jest wersja pdf (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ale słaba jakosc obrazkow tam jest

3. dzieki hawk za rozjasnienie wszystkiego (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował bela_666 12.11.2004, 00:05:22

[aleksander]

ok to mi jeszcze ukazał się taki oto problem:

wyobraźmy sobie, że robię silnik/cms oparty na mvc. Na stronie opartej o taki skrypt może być jednocześnie potrzebnych kilka widoków np. widok newsow, widok menu, widok stopki i Bóg wie jeszcze czego. A jak wiadomo widok musi być ostatni - więc jak wywoływać te poszczególne widoki? Ja pomyslałem nad kolejką ale co wy o tym sądzicie?

[hawk]

Hmm, są dwie zasady:

1. Widok powinien być jeden.
2. Jeżeli potrzebujesz więcej widoków, patrz punkt 1.

(IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

Tak naprawdę jest. Żaden wzorzec nie jest idealny i MVC po prostu nie podejmuje tematu: co zrobić jak chcemy mieć wspólne menu itd. I nie musi. Zauważ że nic ci nie zabrania includować w klasie widoku wspólnego szablonu menu. Oczywiście, wspólny szablon menu wymaga też wspólnego kodu który stworzy to menu i podstawi odpowiednie wartości. Ale ten sam problem miałbyś ze zwykłymi skryptami, które korzystają z szablonów i też muszą jakoś współdzielić kod. MVC ani tutaj pomaga ani przeszkadza.

Może trochę jednak ułatwia, bo mamy klasę widoku, więc możemy jakoś sobie dziedziczyć, np. ArticleView extends ViewWithMenu itd. Możesz wpychać to co wypluwa klasa widoku w jakieś headery/footery generowane przez inną klasę. Jest pole do popisu (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) .

BTW nie mówimy "widok stopki", tylko raczej "klasa wyświetlająca stopkę należąca do warstwy widoku". Podobnie jak bez sensu jest mówić "model artykułów".

[hamlecik]

Witam,

Mam taki maly OT. Otoz stworzylem sobie ostatnio cos na wzor MVC. Jest to bardzo prosta aplikacja, wyswietlanie listy userow i wyswietlanie danych jednego usera. Idea jest prosta. Wywoluje kontroler w zaleznosci od tego jaka wartosc przyjmuje zmienna $_GET['show'], kontroler wywoluje widok, widok pobiera dane z modelu i wyswietla strone.

Jednak moje rozwiazanie jest malo elastyczne poniewaz kazda akcja ma "swoje pliki".

np wylistowanie userow:

UsersController
UsersModel
UsersView

wyswietlenie danych jednego usera:

UserController
UserModel
UserView

Problem pojawia sie np jak bym dodal jeszcze inne funkcje do tej aplikacji, wtedy bym zginal w gaszczu plikow (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

1) Myslalem, zeby zrobic jeden kontroler, wtedy kazda akcja, miala by tylko plik modelu i formatowana przez Smarty strone. Ale jak to zrobic?

2) Chcialem jeszcze zrobic "glowny" kontroler. Byl by to trzon aplikacji. Jego zadaniem bylo by wywolywanie "malych kontrolerow", ktore mialy by okreslone zadania np kontroler userow, kontroler newsow.

Przyklad:

Kod

"Glowny" kontroler -> "maly" kontroler

   modul newsow    -->  wyswietlanie newsow
                            |->  wyswietlanie konkretnego newsa
                            \->  kasowanie newsa itd itp

Niestety znowu moja ograniczona wiedza (albo brak wiary?) nie pozwala mi tego osiagnac. Byl bym bardzo wdzieczny gdyby ktos chcial ze mna podyskutowac na ten temat.

Ten post edytował hamlecik 17.12.2004, 11:16:25

[Ludvik]

Kontroler z natury tego wzorca jest jeden.

Wywoluje kontroler w zaleznosci od tego jaka wartosc przyjmuje zmienna $_GET['show']

To raczej kontroler powinien się zajmować tym, to on powinien wiedzieć którą akcję uruchomić. W katalogu BluePrints jest ładnie napisane: Sterownik tłumaczy interakcje[użytkownika] z widokiem na akcje, aby zostały wykonane przez model.
Te interakcje są zawarte w zmiennych przesyłanych metodą GET. Chcesz zobaczyć newsy, to klikasz na odnośnik do newsów, pod którym kryje się adres w postaci np. index.php?show=news. Zmienna show jest analizowana przez kontroler, który z niej się dowiaduje, że powinien wykonać akcję "news". Akcja pobiera dane z modelu i przesyła je do widoku, który jest dostępny dla końcowego użytkownika. Przynajmniej taki jest mój punkt widzenia.

Skoro jesteśmy już przy tym temacie, to na jakiej zasadzie działały twoje kontrolery?

Polecam lekturę artykułu hawka o MVC i dokładniejszy opis MVC na stronach BluePrints Suna.

[Seth]

@hamlecik:
Ja to robie w ten sposob:
Mam jeden glowny kontroler, ktory pobiera dane od usera i na ich podstawie odpala odpowiednia akcje, ktora jest w konfigu.

Przyklad wywolania:
www.example.pl/index.php?go=/phppl/news/12

W pliku z konfigiem mam np.:
$actionsConfig['phppl'] = array( 'news' => 'NewsAction' );
(oczywiscie to tylko kawalek, bo brakuje fallbackow i defaultowych akcji)

phppl - oznacza widok
news - to nazwa akcji
12 (i ew dalsze wartosci po slashu) - to parametry akcji

I teraz kontroler na podstawie tych danych odpala akcje, ktora znajduje sie w action/phppl/NewsAction.class.php:
NewsAction->run( $view, $param );

$view = 'phppl'
$param = array(12)

Na tej podstawie akcja cos tam sobie mieli i korzysta np z NewsModel, ktory to potem odpowiednio przekazuje do widoku - umnie jest to smarty.
I tyle (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[hamlecik]

Seth: Wielkie dzieki za rozjasnienie mi sprawy, chociaz to co napisales troche mi koliduje z tym co czytalem. Czy kontroler nie powinienen wywolywac akcji, akcja wywoluje rzadany widok, a widok pobiera z modelu potrzebne mu dane?

Kod

INPUT -> kontroler -> akcja -> widok <-> model
                                   |        
                                   |        
                               OUTPUT

Chyba powoli rozumiem dlaczego nic mi nie wychodzi. Bo kazdy kto pisze o MVC robi to troche inaczej niz jest w oryginalnym wzorcu, a jak sie przeczyta 5 wypowiedzi, w ktorych jest cos innego to sie nie wiem wkoncu co i jak.

Ide pisac, jak cos napisze to wtedy tu wroce (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[Seth]

Faktycznie troche zmodyfikowalem wzorzec ale inny niz podales.

Kod

input ---> [kontroler] <---> [akcja] <---> [model]
               |
               v
output <--- [widok] <---> [model]

[Vengeance]

Pora na moje pytanie (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Dwa różne schematy działania:

1. user chce zobaczyc tresc danego wątku na forum

ActionController >> showTopic >> showTopicView

2. user dodaje nowy post, na koniec wyswietla sie taka sama tresc danego wątku
z tą jednak roznica ze na gorze jest "belka" z napisem "post dodany pomyslnie"

ActionController >> addNewPost >> showTopic >> showTopicView


Jeśli już tu są jakieś błędy to mnie poprawcie. Teraz jednak podstawowe pytanie.
Jak i gdzie zamieścić ten kod php odpowiedzialny za wyświetlanie belki z "post dodany pomyślnie".

[bregovic]

U mnie to wyglada tak:

• Wyswietlamy temat:
  FrontController >> ShowTopic
• Dodajemy post i wyswietlamy temat:
  FrontController >> AddNewPost >> ShowTopic

Co do twojego pytania, to ja wyswietlilbym belke przekazujac parametr do akcji ShowTopic.

[kurak]

Vengeance, co u Ciebie robi showTopic?

[Vengeance]

to jest akcja wyswietlajaca to co widzisz teraz (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
tytul wątku i wszystkie posty (odpowiedzi) userów (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[kurak]

A po co Ci i showTopic, i showTopicView? Przeciez mozna to zrobic tylko za pomoca showTopicView. Z reszta przegladajac ten topic i czytajac art Hawka mozna sie dowiedziec, ze akcje sa czescia MVC odpowiedzialna za updatowanie uduwanie i dodawanie danych do np. bazy danych - dlatego nie wiem co ma akcja do wyswietlenia topicu. Tym powinien zajac sie widok, pobierajac przez model dane i je wyswietlajac.
Jak sie myle to mnie poprawcie.
pozdrawiam i zycze swietnej zabawy sylwestrowej do rana (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[bregovic]

Zaraz, moment, akcja jest częścią kontrolera - i nie ma nic wspólnego z danymi - model jest odpowiedzialny za prace z danymi, widok za wyświetlanie danych w porządanym formacie - natomiast kontroler (więc i akcja) jest odpowiedzialny za aktywowanie modelu, wyciągniecie od niego właściwych danych i przekazanie ich do widoku - który cały ten szajs wyświetli.

[kurak]

bregovic, sciagnij sobie pdf'a z artem hawka 'Wprowadzenie do MVC'. Jest tam bardzo fajny schemat obslugi zadania (rozdzial: 'Obsługa żądania'). Niestety w arcie na wortalu go nie ma.

[bela]

bregovic, sciagnij sobie pdf'a z artem hawka 'Wprowadzenie do MVC'. Jest tam bardzo fajny schemat obslugi zadania (rozdzial: 'Obsługa żądania'). Niestety w arcie na wortalu go nie ma.

tak i omawiane było to wiele razy, że rysunku nie ma, ale nikt nic z tym nie zrobił (IMG:http://forum.php.pl/style_emoticons/default/sad.gif)

[Vengeance]

@kurak :

Powinno być tak:

1) Zawsze uruchamia się akcja, która robi wszystkie zmiany w Modelu (addUser, deleteUser, modifyUser, blah, blah).
2) Akcja zawsze podaje, jaki widok uruchomić
3) Zawsze uruchamia się widok, który wyciąga z Modelu potrzebne dane i wyświetla je, bez zmieniania niczego

Czyli w najprostszym przypadku (tylko wyświetlamy coś) akcja nic nie robi, poza wskazaniem widoku. Inna sprawa, czy chce nam się robić klasy dla takich jednolinijkowych akcji, ale tak wygląda oficjalny MVC. Zawsze jest akcja - widok. Tak więc nie ma żadnego rozróżniania zapytań wymagających i nie wymagających akcji. Zawsze jest akcja, a jak ta akcja nic z siebie nie robi, to już jej sprawa.

[kurak]

Hmmm... no to mamy tu przypadek rozbieznosci zeznan (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) Hawk w swoim arcie jasno dal do zrozumienia, ze akcje uruchamiamy tylko w przypadku, kiedy zachodzi potrzeba zmiany stanu danych w modelu. Najlepiej poczekajmy na wypowiedz Hawka (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)
Cale szczescie, ze poruszany jest ten temat, bo wlasnie pisze kontroler...