[MVC] Pytań kilka... Opcje

[Vengeance]

ee ale to w sumie jest dowolne! nie przesadzajmy ze jesli hawk powie to i to to jest to wlasnie MVC a cala reszta nie.

MVC takze nic nie mowi o akcjach przeciez! ich nawet nie musi byc.
Pozatym wzroce sa po to takze aby je naginac (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif) (czesto tak powstaja nowe wzroce) hehe ;]

[hawk]

Żeby wyjaśnić rozbieżności:

Diagram to nie implementacja. Jeżeli kontroler ma uruchomić po prostu widok, i nie ma żadnej modyfikacji (czyli nie potrzeba do tego specjalnej akcji), to jak to zrobić? Można sobie wyobrazić taką implementację, gdzie bezpośrednio wykonywany jest widok (np. phiend), lub taką, gdzie potrzebna jest jakaś minimalna akcja, która odpali ten widok (tak ma większość). To kwestia tego, jak sie napisze framework. Ale idea jest ta sama - nie ma żadnej modyfikacji, chcemy wyświetlić widok jak najmniejszym kosztem.

[bregovic]

Hmm... Hawk, podsumowywując - nie ma znaczenia czy nazwiemy to akcją, czy widokiem, czy czymkolwiek - to musi być jakaś klasa, która coś wyświetli. W przypadku phienda, są to klasy z funkcją display - które ewentualnie łączą się z modelem i wyświetlają output (np. przy pomocy smarty).
Innym rozwiązaniem (które tak na prawdę jest dokładnie tym samym - z tymże z innymi nazwami) jest stworzenie akcji - które nie robią nic innego jak wyciągnięcie danych z bazy i wyświetlenie ich.

Różnica, z tego co widzę polega na ilości kontroli jaką przekażemy widokowi. Mnie, wydaje się że widok jako taki nie powinien mieć dostępu do modelu - bo zbyt komplikuje to implementację. Wydaje mi się że to kontroler (więc i akcje) powinien pracować na api modelu - a widok powinien zająć się wcale niełatwą sprawą wyświetlania danych...

Czy się mylę?

[Vengeance]

@bregovic: krotka mowiac myslisz o tworzeniu widoku przez akcje
i przekazywaniu mu jakos (glownie przez parametry w konstruktorze)
jedynie wyniku jakis tam operacji na modelu (pobierania danych).

Z tego co widze bo roznych przygladach wiele skryptow przekazuje do
widoku instancje modelu aby ten zrobil sobie "co potrzebuje". Jednak moze zrobic takze cos wiecej. A w przypadku rozwiazania podanego powyzej mialby dostepdo tego co naprawde jest mu koniecznie.
Czy tak?

[DaNTe]

Podłącze się pod temat, żeby nie zakładać nowego (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Jestem na etapie budowania aplikacji w oparciu o phiend (co prawda to tylko podstawa, którą trzeba dosć mocno rozbudować, ale zawsze).

Z tego co zdążyłem się zorientować, nie ma tutaj matod dających dostęp to parametrów POST, GET itp, a jako, że nie bardzo chcę operować na nich bezpośrednio - muszę sobie taki kawałek kodu dopisać.

Problem jest właśnie z parametrami GET (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) bo prawdopodobnie czasami na wywołania nałożony będzie mod_rewrite, zresztą ze standardową postacia index.php/moja/akcja/ też nie ładnie wyglądały parametry get przekazane po znaku zapytania.

I tu właściwe pytanie - jak radzicie sobie z wywolaniami w stylu /artykul/15/strona/6 ?

Jakieś idee poza ręczną analizą REQUESTED_URI - którą defacto powinien odwalić rontroler ?

[hawk]

Jeżeli chodzi o index/nazwa/akcji, to na pewno możesz to zrobić za pomocą standardowego phienda. Tak działa np. strona projektu.

Jeżeli chodzi o artykuł/16/strona/5, to istotnie kontroler powinien takie coś odwalić. Ale sam framework nie, bo nie wie nic o artykułach. W zależności od tego, ile akcji potrzebuje takich danych, można wydziedziczyć wszystkie/niektóre akcje z abstrakcyjnej klasy, która parsuje takie coś i wyciąga to co potrzeba.

Można też przyjąć, że url zawsze ma postać cośtam/nazwa/wartość/nazwa2/wartość2 itd. Tego phiend automatycznie nie parsuje, i wtedy najlepiej chyba byłoby zrobić klasę bazową dla wszystkich akcji.

[aleksander]

ok no więc ja poruszę troche inny temat MVC. Jest to własciwie tylko małe uniedogodnienie, ale czasem może wkurzyć. Być może ja coś źle robię.

mam akcję showcomments. W tej akcji są wyświetlane komentarze i formularz do wstawienia nowego komentarza. Gdy kliknę na przycisk dodaj komentarz, przejdę do akcji addcomment. Ta akcja zwróci nazwę widoku showcomments, wieć znowu zobaczę komentarze, ale w pasku adresu będzie nadal addcomments i gdy użytkownik niechący lub chcący kliknie F5 to do bazy znowu doda się identyczny komentarz (pomijam, że przeglądarka ostrzega przed tym).

Można by w akcji addcomment zrobic header( 'Location'); do akcji showcomments i po problemie, ale to z kolei odbiera od zasady MVC. Co Państwo o tym myślą?

pozdrawiam

[dag]

Można zwrócić widok z tekstem "komentarz został dodany..<a>zobacz komentarze</a>"

[sobstel]

albo po prostu uneimożliwić dodanie takiego samego komentarza, poprzez sprawdzeni przy dodawaniu do bazy czy nie istnieje juz dokladnie taki sam rekord (pomijając czas oczywiście, no i trzeba uważać żeby przy okazji nie zablokować użytkownikowi możliwości wielokrotnego postowania popoularnych fraz np. "ok")

nawiasem mówiąc, przy okazji implementujemy mały mechanizm anty-floodowy.

[marcin96]

Można by w akcji addcomment zrobic header( 'Location'); do akcji showcomments i po problemie, ale to z kolei odbiera od zasady MVC. Co Państwo o tym myślą?

Czemu odbiega? Zrobić widok wykonywany po wykonaniu akcji dodania komentarza do bazy. Widok ten wysyła do użytkownika właśnie header("Location: ..."); i tyle...

Ten post edytował marcin96 10.02.2005, 15:06:23

[hawk]

Fakt, nie odbiega. Patrz np. phrame.

A generalnie to po prostu potrzebna jest kontrola postback. A przekierowanie jest właśnie jedną z takich metod.

Zresztą można nawet puścić header już w początkowej akcji. Redirect i tak jest tylko wewnętrznym trikiem, a nie widokiem.

[squid]

czy mozna laczyc MVC z innymi wzorcami, ktos juz tak probowal?

[M4chu]

Mozna? Nawet trzeba! Np Dao, Intercepting Filter, Decorator (do widoku).
Btw sam MVC jest zbudowany na Composite, Observer, Strategy i pewnie jeszcze kilku (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[UFO]

Witam!
I ja pozwolę sobie dołączyć się do dyskusji (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) Zacząłem właśnie pisać własny framework. Początkowo miał to być CMS, ale stopniowo ewoluowało do frameworka. Planuję wykorzystać model MVC, jednak męczy mnie parę kwestii...

Po pierwsze:
We wprowadzeniu do MVC wyczytałem że powinien być tylko jeden kontroler. Co w sumie logiczne jest jeśli system ma być elastyczny i łatwo się dopasowywać poprzez wyedytowanie configa. Jednak problem pojawia się jeśli chcemy zastosować do tego czegoś subdomeny. Mamy dany kontroler kontroler.php. I teraz w zależności od parametrów przekazanych do niego chcemy wyświetlić dział newsy albo czat. Czyli kontroler.php?dzial=newsy kontroler.php?dzial=czat I wszystko ładnie i pięknie do czasu aż wprowadzimy subdomeny. newsy.domena.pl czat.domena.pl I co się wtedy dzieje? Wychodzi na to że trzeba zastosować kilka kontrolerów. Chyba że... wykorzystać mod_rewrite, ale ten nie zawsze jest dostępny. Można też teoretycznie wykorzystać stronę błędu 404 do "emulacji" mod_rewrite ale to rozwiązanie mało eleganckie. A jeśli podzielimy kontroler to znowu stracimy możliwość łatwej konfiguracji i system w ten sposób będzie mało elastyczny (właściwie przypisany do jednego konkretnetego rozwiązania - czyli przestanie być frameworkiem). Może więc w każdej subdomenie dać plik index.php, w którym wysyłać header Location, przekierowujący do kontrolera i przekazujący mu wszystkie parametry? To też rozwiązanie mało eleganckie i rozwiązujące problem tylko częściowo. A może są jeszcze jakieś ciekawe rozwiązania tego problemu?

Druga sprawa:
Druga? W trakcie pisania tego postu przyszło mi do głowy kilka pomysłów na rozwiązanie pozostałych problemów (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

Pozdrawiam

[Ociu]

Ja mam coś takiego: localhost/język/content(lub forum, chat)/moduł/opcja/id/

przykładowo: localhost/pl/content/articles/show/1/

Do subdomen, można by rzeczywiście użyć mod_rewrite... jaki w tym problem ?

Ten post edytował Ociu 11.08.2005, 09:51:41

[Vengeance]

przecież każda subdomena może wskazywać na ten sam katalog, z tym samym index.php i kontrolerem, a kontroler sprawdzi poprawność $_SERVER[HOST].

Jeżeli stwierdzi, że ma doczynienia z odwołaniem z subdomeny, ustala np. katalog z którego ma brać akcje np. /actions/chat/*

Pozatym do tego służy także wzorzec FrontControllera pozwalający utworzyć "jeden spójny punkt wejścia" do aplikacji.

[max_catch]

Mam pytanie z nieco innego obszaru. Nie dysponuję gotowym kodem, rozważam jedynie teoretycznie, ale postaram się przedstawić moje wątpliwości w miarę zrozumiale.

Rozpatrując modularyzację aplikacji wygodna jest możłiwość wykonywania sekwencji akcji (czy też łańcuchów akcji; być może mylę pojęcia) przy czym akcje te mogą być dynamicznie kolejkowane w trakcie wykonywania dowolnej akcji.

Przykład: stronę tworzą takie komponenty: drzewiaste menu (np: katalog produktów w e-sklepie - kategorie), lista produktów (główna treść), pole wskazujące w jakim miejscu strony jest użytkownik. Aby wygodnie rozdzielić zadania i ułatwić edycję, każdy z wymienionych komponentów strony może być realizowany oddzielną akcją i wywoływany w zbiorczej akcji, choćby tak:

[PHP] pobierz, plaintext 
<?php
 
class Store extends Action {
	public function perform(httpRequest $request, httpResponse $response) {
		// kolejkowanie potrzebnych elementów, czyli tworzenie omawianej sekwencji akcji
		Controller::getInstance()->enqueue('displayCatalog');
		Controller::getInstance()->enqueue('displayLocation');
		Controller::getInstance()->enqueue('displayProducts');
	}
}
 
?>
[PHP] pobierz, plaintext 

w takiej sytuacji kontroller otrzymawszy żądanie 'www.test.com/go/Store' podczas inicjalizacji wprowadza do swojej wewnętrznej listy akcji nazwę akcji do wykonania (tutaj 'Store', nie jest uzasadnione wprowadzanie na listę gotowego obiektu). Kontroler startuje; podczas wykonania Store zakolejkowane zostają 3 kolejne akcje i pętla wykonawcza sunie dalej.

A teraz sedno sprawy. (IMG:http://forum.php.pl/style_emoticons/default/sad.gif)

Na platformie MVC potrzebujemy także filtrów. Moje pytania dotyczą wzajemnych relacji między akcjami a filtrami.

1. Czy wykonanie łańcucha akcji powierzać samemu kontrolerowi, czy może kontroler powinien wykonywać jedynie szereg filtrów, z których ostatni będzie filtrem ExecutionFilter i jemu przekazywać kontrolę nad sekwencją akcji? Jakie są korzyści zastosowania każdego z rozwiązań?

2. Czy wykonanie akcji w sekwencji wiązałoby się z wykonaniem osobnego szeregu filtrów dla każdej akcji? Czyli czy łańcuch filtrów to pomysł, który powinno się stosować przed wykonaniem łańcucha akcji, czy też dla każdej akcji w łańcuchu indywidualnie?

Podsumowując, chciałbym abyście podzielili się swoimi pomysłami na rozwiązanie problemu "interakcji łańcucha filtrów z łańcuchem akcji" i sprecyzowali miejsca obu wymienionych części we frameworku MVC.

[pies]

Jakiś czas temu razem z paroma osobami ze świata napisaliśmy (a oni dalej rozwijają) framework MVC -- Cake php (www.cakephp.org). Rozwiązanie problemu URLi ściągnęliśmy z RoR (www.rubyonrails.org).

Pomysł opiera się na przypisaniu adresów do konkretnych klas i metod, tak, że np. adres:

www.example.com/blog/view/55

odpowiada klasie BlogController (Controller to "C" w "MVC") i metodzie view() w tej klasie, a "55" przekazywane jest jako parametr do wywołania metody, czyli powyższe wywołanie przekształcane jest w:

Kod

print BlogController->view(55);

Reguły przypisania określane są przez mechanizm Router. Można dzięki niemu zmienić rozumienie wywołań w dość dowolny sposób:

Kod

$Router->connect('/', array('controller'=>'Pages', 'action'=>'view', 'home'));

...oznacza, że wywołanie strony głównej (/) uruchamia PagesController->view('home').

Kod

$Router->connect('/kupuj/:action/*', array('controller'=>'Shop', 'action'=>'kategoria'));

...oznacza, że wywołania adresów typu /kupuj, /kupuj/koszyk, /kupuj/kategoria/5, /kupuj/produkt/234/czerwony przekształcane są w wywołania, odpowiednio:

Kod

print ShopController->kategoria();
print ShopController->koszyk();
print ShopController->kategoria(5);
print ShopController->produkt(234, 'czerwony');

Jest do tego manual (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował pies 9.09.2005, 09:27:31

[Ociu]

pies: czyli dla każdego modułu musisz tworzyć nowy Controller ? Nie widze najmniejszego sensu.

Mam link w takiej postaci:
/pl/content/home/ - dla strony głównej portalu. Jeśli chce uruchomić np. blog to daje.
/pl/blog/home/

opcjonalnie mam link z parametrem /pl/blog/entry/view,13/ (przykład).

Request: (cząstka)

[PHP] pobierz, plaintext 
<?php
public function SimpleVirtualURL() {
	$iURL = (isset($_SERVER['PATH_INFO']) ? $_SERVER['PATH_INFO'] : THRORIN_LINK);
	$this->iURL = explode('/', $iURL);
}
?>
[PHP] pobierz, plaintext 

Czyli rozbija adres do tablicy. w Routerze jest analizowanie tej tablicy:

[PHP] pobierz, plaintext 
<?php
public function Analyse() {
	$this->request->SimpleVirtualURL();
	$this->lang = (empty($this->request->iURL[1]) ? THRORIN_LANG : $this->request->iURL[1]);
	$this->system=(empty($this->request->iURL[2]) ? 'content' : $this->request->iURL[2]);
	$this->module=(empty($this->request->iURL[3]) ? 'home' : $this->request->iURL[3]);
 
 
	if(!isset($this->request->iURL[4])) exit();
 
	$url = explode(',', $this->request->iURL[4]);
 
# czyszczenie tablicy iURL
	$this->request->iURL = array();
 
	$this->option=$url[0];
	$this->id=$url[1];
}
?>
[PHP] pobierz, plaintext 

Później Controller wywołuje odpowiednią akcję.
I tak dzięki 4 plikom (+view) mam uniwersalny silnik (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[pies]

pies: czyli dla każdego modułu musisz tworzyć nowy Controller ? Nie widze najmniejszego sensu.

Nie bardzo rozumiem co masz na myśli. Jeżeli moduł to pojedyncza funkcjonalność serwisu (np. newsy albo obsługa formularza) to w moim modelu moduł nazywa właśnie controller.

Później Controller wywołuje odpowiednią akcję.
I tak dzięki 4 plikom (+view) mam uniwersalny silnik (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Mój mechanizm działa bardzo podobnie, tylko dodatkowo jest konfigurowalny i ma obsługę błędów (zakładam, że Twój też). Nie wiem z ilu plików się składa, bo jest częścią frameworku i ma trochę zależności (m.in. logowanie błędów), ale ogólnie rzecz biorąc mam klasy Router (konfiguracja URLi) i Dispatcher (odczytuje konfigurację, ładuje potrzebne klasy, tworzy obiekt controllera i uruchamia go).

Konfigurowalność pozwala na dodanie m.in. krótkiego aliasu do jakiejś strony, na przykład

Kod

www.audi.com/a4

które działa tak jak

Kod

www.audi.com/products/view/a4

.

Robi się to tak:

[PHP] pobierz, plaintext 
<?php
$Router->connect('/a4', array('controller'=>'Product', 'action'=>'view', 'a4');
?>
[PHP] pobierz, plaintext 

Wywołana będzie metoda ProductController->view('a4').