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.

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

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?

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

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.

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 ciagle sie uczy

Ż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

Hehe
Wiedziałem ze sie myle

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ć?

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

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 .

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 .

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

----------------------------------------
Grr, dlaczego nie mogę dać 2 odpowiedzi pod rząd?
@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.

Co do wielu kontrolerow to zauwaz ze to Marcin wlasnie napisal a ja stwierdzilem ze jest to do przemyslenia
Co do modelu i akcji to chyba nie zakumalem od razu i dopiero teraz do mnie dotarlo W poprzednim rozumowaniu (dodam ze blednym ) 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.

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.

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ć ;>)) )



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

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

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 ?

to o czym myslisz to raczej DAO



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



moduł to raczej logiczny zbior akcji

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.

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 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 oczywiscie ostatnią akcją byłoby wyswietlenie odpowiedniego widoku ...

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.

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?

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?

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

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 ;]

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.

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

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

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

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

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

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.


heh - Ty go tylko ładne nazwałeś
Patern pozwalający na pobieranie nazwy wykonywanej akcji z adresu jest jednak chyba nieco starszy niż phiend...

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

to moze trzeba opatentowac bill ci opatentowal podwojne klikniecie to i my mozemy

no to już całkiem się zakręciłem

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

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

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 a wiec jak są rozróżniane zapytania wymagające i nie wymagające akcji ?

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

:D:D

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

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

1. wiem, ze nie musi byc to baza

2. na szczescie jest wersja pdf ale słaba jakosc obrazkow tam jest

3. dzieki hawk za rozjasnienie wszystkiego

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?

Hmm, są dwie zasady:

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



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 .

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

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

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:



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.

Kontroler z natury tego wzorca jest jeden.

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.

@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

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?





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

Faktycznie troche zmodyfikowalem wzorzec ale inny niz podales.

Pora na moje pytanie

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

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.

Vengeance, co u Ciebie robi showTopic?

to jest akcja wyswietlajaca to co widzisz teraz
tytul wątku i wszystkie posty (odpowiedzi) userów

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

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.

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ł

@kurak :

Hmmm... no to mamy tu przypadek rozbieznosci zeznan 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
Cale szczescie, ze poruszany jest ten temat, bo wlasnie pisze kontroler...