Router to obiekt który rozbija żądanie i wyciąga z niego nazwę żądanej akcji, parametry itp. Router jest także generatorem linków (np nice urls)

HttpRequest jest obiektem, bedącym otoczką dla żądania http.

I teraz moje pytania:
1. Czy HttpRequest powinien by jednocześnie routerem:czy router powinien byc oddzielny analizowac dane z httpRequest i na tej podstawie stwierdzac, którą ma akcję uruchomic:?

2. Jeżeli ta pierwsza opcja to gdzie tu powinien by generator linków? Przecież nie za bardzo pasuje on do HttpRequest

a co bys chcial zeby HttpRequest robil (troche konkretniej)

no HttpRequest jest otoczką dla rządania http, ma metody pozwalające na wyciągnięcie danych POST GET COOKIE FILES.

Po prostu mam kilka argumentów jedne na to, żeby HR i Router były połączen drugie na nie i nie wiem co lepsze, więc pytam się Was:)

Ostatnio zainteresowałem się Mojavi. Tam HttpRequest i Ruter (w zasadzie nie wystepuje on jawnie) nie są w żadnym razie połączone.

Dla mnie ideałem jest:
1. HR jest odpowiedzialne za żądanie aplikacji (parametry POST, GET, ...) i posiada metody do manipulacji nimi.

2. Router w rzeczywistości służy tylko do pobrania nazwy akcji z żądania i przekazanie tej informacji do Kontrolera

3. Kontroler rozdziela zadania, na podstawie informacji od Rutera i to on powinien zawierać metody do generowania linków.

W modelu tym bez wachania mozna pominąć Ruter, gdyż jest tylko ogniwem przekazującym dane i nie wnosi nic do aplikacji. Dane z HR Kontroler może sobie sam pobrać bez przeszkód:

[PHP] pobierz, plaintext 
<?php
 
$objRequest->getParameter( 'actionName' );
 
?>
[PHP] pobierz, plaintext 

... czy jakoś tak. Kontroler wcale nie potrzebuje tutaj Rutera. Jeżeli miałby on się jednak znaleść to napewno cząść Kontrolera, ale z pewnością nie część HR.

Tak funkcjonuje framework Mojavi, który moim zdaniem jest baaardzo bliski ideałowi.

[PHP] pobierz, plaintext 
<?php
class Request { // abstract class Request
 protected $request = null;
 
  abstract public function get() {
  }
}
 
class httpRequest extends Request() {
  public function get() {
	if( in_null( $this->request ) ) {
	 return $this->request = $_SERVER['xxx']; // wybrac sobie klucz
	}
	return $this->request;
  }
}
 
class Router {
   /**
	 * @var object Request
	 */
   private $request;
   public function __construct( Request $request ) {
	 $this->request = $request;
   }
}
 
?>
[PHP] pobierz, plaintext 

Moze troche byc zle napisane bo nie oto chodzi.

Mysle ze imho tak to powinno wygladac, czemu?
Mozna dopisac sobie np request z lini polecen
ConsoleRequest
nie trzeba calosci przerabiac.

Mysle ze Router nie powinien dziedziczyc z request (podobnie request z routera) tutaj lepszym rozwiazaniem jest agregacja (zawieranie).

Request jest poto zeby z niego dziedziczyc.

Daje to jako taka swobode dzialania.

Jak ktos ma ciekwasze pomysly to z checia obejrze.

Router w tym ukladzie dostarcza informacji kontrolerowi co i jak...

Dokladnie o to chodzi i to jest siłą takiego rozwiązania.
Hierarchia może wtedy wyglądać tak: Class Request


W zasadzie, jak już wspomniałem, jest on zbędnym przekaźnikiem. Nie wnosi nic konkretnego poza kolejną warstwą przez którą sie trzeba przebić w poszukiwaniu danych o żądaniu aplikacji.

ak dla mnie może on istnieć jako część (metodda, lub jakiś mały obiekcik) Kontrolera. Ale najlepiej to by było, jakby go nie było
Przecią Kontroler sam może sobie dane pobrać z Requesta (a dokładnie z klasy dziedzczącej po nim).

Czemu wiec request jako klasa abstrakcyjna a nie interfejs?
wtedy klasa httpRequest moglaby implementowac metody wspolne dla wszystkich mozliwych rodzajow requestow z interfesu Request i metody specyficzne dla tego protokolu jak implementacja interfejsu HTTP

Sam zastanawiam się teraz nad tym problemem. U mnie cala operacja wygląda tak:

Mam klasę HttpRequest, która implementuje interfejs iHttpRequest.
W konstruktorze klasy HttpRequest mam takie coś:

[PHP] pobierz, plaintext 
<?
$this->GetParametersContainer = new GetParametersContainer;
$this->PostParametersContainer = new PostParametersContainer;
?>
[PHP] pobierz, plaintext 

i tak dalej dla Cookie, Files, itp.
Klasa GetParametersContainer wygląda tak:

[PHP] pobierz, plaintext 
<?php
 
	class GetParametersContainer extends ParametersContainer
	{
		public function __construct()
		{
			foreach( $_GET as $sKey => $mValue )
			{
				$Key = new String( $sKey );	
				$Value = new String( $mValue );
 
				if( is_numeric( $mValue ) )
				{
					$Value = new Integer( $Value );	
				}	
 
				$this->addParameter( new Parameter( $Key, $Value ) );
			}	
		}	
	}
 
?>
[PHP] pobierz, plaintext 

Teraz najlogiczniejszym IMO umiejscowieniem routera będzie klasa GetParametersContainer i nowa klasa HttpRequest. Np. tworzę sobie klasę RoutedGetParamterersContainer, która będzie odpowiednio rozszyfrowywala PATH_INFO. Potem tworzę sobie klasę RoutedHttpRequest rozszerzającą HttpReqest i imlpementującą interfejs iHttpRequest, która w konstruktorze zawiera zamiast:

[PHP] pobierz, plaintext 
<?php
$this->GetParametersContainer = new GetParametersContainer;
?>
[PHP] pobierz, plaintext 

to

[PHP] pobierz, plaintext 
<?php
$this->GetParametersContainer = new RoutedGetParameteresContainer;
?>
[PHP] pobierz, plaintext 

Dzięki temu do zmiennych Get mogę odwolywać się tak jak zawsze mimo, że przechodzą one przez router.

Dla mnie funkcje requesta to:
- wymuszanie, żeby dostęp do danych POST, GET itd był tylko przez tą klasę
- nie można zmieniać np. danych POST, bo request na to nie pozwala
- można wymienić klasę requesta i np. wczytać wszystkie dane z pliku XML (dobre do testowania)
- można dołożyć jakieś filtry na requesta, np. odtegować magic_quotes_gpc
- jest to dobre miejsce do jakiejś analizy danych wejściowych

Funkcje routera: tylko jedna, ale bardzo ważna: zamiana URLi na nazwy akcji i z powrotem. Mojavi nie zawiera routera, i przez to schemat URLi musi być zakodowany na sztywno w kontrolerze.

Router i request powinny być IMHO rozdzielone, bo zadania mają inne.

Jeszcze co do requesta: Jest to bardzo praktyczna i wygodna rzecz. Gdyby ktoś zrobił request w ramach SPL, to wziąłbym go bez zastanawiania się. Problem w tym, że ciężko dojść do porozumienia, jakie dokładnie metody powinien zawierać, i jest to zawsze kawałek kodu, który nie jest niezbędny. Więc chyba najlepiej jest go zaimplementować tak, żeby narzut czasowy i ilość kodu były minimalne.

Tak to wygląda w Mojavi, (kawałek klasy WebController)

[PHP] pobierz, plaintext 
<?php
public function genURL( $url = null, $parameters = array() )
{
	if ($url == null)
	{
		$url = $_SERVER['SCRIPT_NAME'];
	}
 
	if (MO_URL_FORMAT == 'PATH')
	{
		// use PATH format
		$divider  = '/';
		$equals   = '/';
		$url	 .= '/';
	} else
	{
		// use GET format
		$divider  = '&';
		$equals   = '=';
		$url	 .= '?';
	}
 
	// loop through the parameters
	foreach ($parameters as $key => &$value)
	{
		$url .= urlencode($key) . $equals . urlencode($value) . $divider;
	}
 
	// strip off last divider character
	$url = rtrim($url, $divider);
 
	// replace &'s with &amp;
	$url = str_replace('&', '&amp;', $url);
 
	return $url;
}
?>
[PHP] pobierz, plaintext 

Stała MO_URL_FORMAT jest definiowana w pliku konfiguracyjnym, a możliwość rozszerzenia tej funkcji ogromne. Więc niby zaszyte ale nie tak bardzo sztywno



O.T. Przepraszam za nieustanną propagandę Mojavi ale jakoś mnie ten framework zafascynował, jest bardzo przejrzyście i ładnie napisany. I dlatego można go sobie w banalny sposób przebudować i dostosować do swoich upodobań.

Pewnie ma jakieś wady, ale nie znalazłem jeszcze większych/rażących

Wiem, sam uważnie studiowałem Mojavi . Nie chcę tutaj go krytykować, bo to bardzo dobry framework. I może się nieprecyzyjnie wyraziłem. Chodzi o to, że Mojavi oferuje dwa schematy kodowania URLi. Problemy są dwa:
1) Jak chcę, żeby mój URL wyglądał inaczej, to muszę grzebać w kodzie samego frameworka. Co praktycznie wyklucza taką możliwość.
2) Zwiększanie liczby opcji też nie jest dobre, bo php będzie musiał parsować np. kilkanaście różnych if...else parsujących URL, kiedy przez cały czas używana jest tylko jedna opcja - niepotrzebny kod.

Przyznają rację - jest to niedogodność.

P.S. Zauważyłeś jeszcze jakieś bugi/biedogodności w Mojavi. Bo ja chyba tylko jeszcze jedną. Ale to rozmowa na inny temat lub na PW.

Nie zanieczyszczajmy wątku bo schodzimy z tematu

Ale wciąż mam wątpliwości co do tego Routera. Jeśli mamy linki postaci:
index.php/module/test/action/test/p1/blah/p2/test
To HttpRequest nie będzie mial żadnych zmiennych w tablicy $_GET, a IMO powinien mieć. Powinien rozszyfrować ten url i mieć 4 zmienne: module, action, p1 i p2. Router zaś powinien chyba zapytać HttpRequest o zmienne module i action i podać je kontrolerowi. Albo powinien mieć możliwość zmiennych GET klasy HttpRequest, tak, aby w dalszej części skryptu byly normalnie dostępne przez HttpRequest.

Nie powinien mieć. To router powinien wiedzieć, że nie szukamy zmiennych w tablicy GET, tylko bierzemy REQUEST_URI (czy jak to się nazywało) z SERVER i tniemy na kawałki. Request powinien tylko dostarczać wszystkie te dane tak, jak były one ustawione przez serwer http, bez interpretowania ani szukania w nich module/action.

W każdym razie takie jest moje zdanie. Nigdzie nie jest napisane, że nie może być inaczej, ale tak wydaje mi się lepiej. Wtedy zmiana schematu URLi == zmiana routera, a request zostaje bez zmian.

A dajmy na to w Phiend2, Router mialby być ladowany przed BasicHttpRequest (i czytać bezpośrednio z tablicy $_SERVER), czy po i przyjmować jako argument instancję klasy implementującej iHttpRequest i z niej pobierać informacje z tablicy $_SERVER?
A co jeśli mamy caly URL w techinice NiceURL, czyli dajmy na to:
index.php/a/1/b/2/c/3
HttpRequest ma nie wiedzieć o tym, że te dane z PATH_INFO są zastępstwem zwyklych danych z tablicy $_GET? W takim razie jak w innej części kodu mamy pobrać wartość zmiennej a, b lub c? Mi się wydawalo najrozsądniej w kodzie wyciągnąć z kontekstu (Context) instancje iHttpRequest i poprosić ją o te zmienne. A jak Ty to widzisz?

W phiend2 (dokładnie: w phiend.mvc) router jest po request. Przyjmuje jako argument i wyciąga takie dane, jakie chce.

Co do wyciągania później zmiennych, widzę 2 sposoby:
1) router może zwrócić nazwę akcji + parametry, więc jedna implementacja routera może przepisać te parametry z tablicy GET, a druga na podstawie PATH_INFO

2) sama akcja może odwołać się bezpośrednio do requesta i wyciągnąć potrzebne parametry

Ale tutaj widzę pewien problem, i pewnie o to Tobie chodziło: jeżeli schemat URLi dyktuje nie tylko, jak wyciągać z URLa nazwę akcji, ale także, jak uzyskać inne parametry potrzebne konkretnej akcji, akcja nie powinna odwoływać się bezpośrednio do requesta, bo nie wie, jak są te parametry zakodowane. W tej sytuacji widzę 3 wyjścia:
1) zrobić requesta, który potrafi w ograniczonym zakresie przetwarzać dane wejściowe (nie szuka nazwy akcji, ale przepisuje parametry z PATH_INFO do GET, jeżeli trzeba), i podmienić zamiast BasicHttpRequest

2) zrobic routera, który będzie w stanie zorientować się, że dana akcja potrzebuje parametrów, i wyciągnąć je zgodnie z przyjętym schematem URLi

4) router zawsze bierze wszystkie dodatkowe parametry GET (lub wszystko, co zostaje w PATH_INFO) i podaje akcji jako parametry, a akcja niech sama się martwi, które z nich naprawdę były jej potrzebne

Dokladnie o twoją 1 propozycję chodzilo mi w tym poście. Osobiście wolę przerzucić wyciąganie potrzebnych parametrów na akcje niż pchać je na silę przez Router
IMO najlepszym wyjściem jest po prostu tworzenie nowej klasy implementującej interfejs iHttpRequest, a router ograniczyć do pobierania od tej klasy informacji o bieżącej akcji/module.

Ponieważ każdy widział kod phiend2, to wszystko będzie pod jego "logike" tak by łatwiej było się dogadać :]


W zaleznosci ktory Request wybierzemy, rozbija on podane URLe na tablice:


Akcje pobieraja sobie te dane bezpośrednio:

[PHP] pobierz, plaintext 
<?php
 
$request->getParam(1); // zwroci 'param1'
$request->getParam(2); // zwroci 'param2'
 
?>
[PHP] pobierz, plaintext 

I teraz podstawowe pytanie... gdzie w cały schemat klas umiejscowić Router (Jak zwał tak zwał) bym mógł szybko generować URLe dla dowolnego schematu. Przypuśmy że w kodzie TPL potrzebuje zrobić:

Albo w kodzie akcji:

[PHP] pobierz, plaintext 
<?php
 
$response->redirect(tworz_url(array('m'=>modul2,'a'=>akcja2,1=>param1)));
 
?>
[PHP] pobierz, plaintext 

Więc jak tu dobrze umiejscowić ROuter by móc się do niego wygodnie odwoływać z Szablonów czy też akcji w celu stworzenia URLa ?!

Żeby to dobrze działało, router i request musiałyby być "zsynchronizowane". Tzn jeżeli request bierze parametry z GET, to router tworzy urle wykorzystując GET. A to mi śmierdzi, bo dwa komponenty muszą mieć wspólny sposób obsługi. Zgodnie z prawem Murphiego... Jakieś pomysły?

@hawk: nie koniecznie, Request może rozbijać PATH_INFO by np. obsłużyć pokazany wyżej url1, a Router będzie tablicę podaną w parapetrze join-ował ze znakiem '/'. Tylko mnie chodzi o to, jak połączyć Router z innymi klasami, by łatwo było go wymieniać, ale i łatwy był dostęp z TPL czy z akcji do niego. Kompletnie nie wiem pod co pasuje ficzer "generowania urli" tym bardziej ze jest to potrzebne w wielu miejsach

zazwyczaj do akcji przekazuje sie request i response wiec teoretycznie pasowalby on do requesta. Można też zrobic coś takiego: $oRequest->getRouter();, lub Router::getInstance(); jak używałem kiedyś:]

A może coś takiego, że Router jest przezroczysta warstwą dla Requesta? Bo w sumie Request nigdy się nie zmieni, to Router jest wymienialny, w zalezności od linków, więc może on np rozszerzac Request.

Co do dostępu do routera (znowu mówię w kategoriach phiend2):

[PHP] pobierz, plaintext 
<?php
//w kodzie akcji:
$url = PluginLoader::getInstance()->getPlugin('router')->createURL('niepamiętamco');
?>
[PHP] pobierz, plaintext 

Jeżeli jest dostęp z akcji, to również z template. Można np. przekazać do smarty.

Natomiast request przekazywany jest do akcji jako parametr - dokładnie przekazywany jest IHttpContext, i wystarczy zrobić $context->getRequest().

@Vengeance: Ja się martwię tym, że request musi rozbijać wg PATH_INFO, a router łączyć slashami. A jeżeli ktoś weźmie inny router? Nagle mu się rozjedzie sposób tworzenia URLi ze sposobem dekodownia URLi. Więc wolałbym trzymać obie te funkcje tylko w routerze. Tylko że jak pokazał matid, to rodzi pewne problemy .

@aleksander: Jeżeli router będzie rozszerzał requesta, to będę miał przy moim podziale na pakiety lekkie zamieszanie. Bo request nie potrzebuje MVC i może być teoretycznie używany bez tego. A router już jest częścią MVC, bo na wyjściu daje nazwy akcji.

edit: a gdyby tak dodać do routera metodę getParam($request, $paramName) ? Router już będzie wiedział, jak co wyciągnąć z requesta, a w ten sposób request nie musi nic analizować i przetwarzać.

@hawk: btw, ja bym w phiendzie dorzucil do filtrow i pluginow cos co ja nazwalem PluginAccessor:

function __get($plugin) {
return PluginLoader::get($plugin);
}

co skraca uzycie do $this->router->costam();

Co do routera, wydaje mi sie ze najlepszym rozwiazaniem jest przekazywanie z routera do request sparsowanej tablicy z parametrami sparsowanego urla. Czemu tak? A bo wtedy wyciagamy dane wylacznie z requesta nie martwiac sie o to jak zostaly sparsowane. Fakt faktem ze musimy wtedy stworzyc w miare uniwersalny format tych danych w tablicy: np [ 0(nazwa akcji) -> test, 1(pierwszy parametr) -> 10 itd] Wprowadza to pewne ograniczenia ale i korzysci...

Majac w indeksowanej tablicy parametry sparsowanego urla mozemy latwo tworzyc schematy urli. Przyjmujemy ze 1 parametr to zawsze nazwa akcji, a potem juz akcja decyduje czym sa kolejne parametry.

Wg mnie nie powinnismy nigdy wyciagac bezposrednio z routera danych. To co router sparsuje powinno zostac polaczone z danymi z request z priorytetem na dane routera. W koncu router przydaje sie wylacznie przy zapytanaich typu HTTP i ewentualnie do sprawdzenia ip klienta / przegladarki itp.

Przy requestach ala xml-rpc czy soap, router jest praktycznie zbyteczny.

Pozdrawiam

Ja mam trochę jak w Cocoonie Znaczy definiuję w config request w którym są akcje, tak:

[XML] pobierz, plaintext 
<request match="foo/bar/?/*" />
[XML] pobierz, plaintext 

? oznacza wszystko oprócz /, a * każdy znak. A router już sobie dopasowaję to przekształcając na RegExpy

Stąd mój udzial w tym wątku, bo mam te same rozterki :]

Można ew. tworzyć nową klasę Request, która w konstruktorze stworzy instancję Routera i pobierze od niego rozszyfrowane dane z PATH_INFO. Jak ktoś będzie chcial stworzyć nowy url, to albo pobierze sobie Router (np. $request->getRouter(); albo zmapuje się funkcję generowania URL-a do requesta (trochę mniej mi się to podoba).
W takiej sytuacji możemy sobie spokojnie wymienić Router i zmienia się zarówno sposób kodowania, jak i dekodowania, ale możemy także zmienic klasę Request.
A w Phiendzie wystarczyloby zostawić BasicHttpRequest w phiend.context a RoutedHttpRequest wraz z Routerem wrzucić do phiend.mvc. I tak BasicHttpContext dostaje iHttpRequest w kostruktorze, więc nie ma problemu ze znajdowaniem się tych klas w różnych pakietach. (i tak instancja BasicHttpContext będzie tworzona najprawdopodobniej we kontrolerze, który jest częścią phiend.mvc).

matid: pamietaj ze router nie zawsze jest potrzebny. Niezlym rozwiazaniem byloby $request->setData($router->getTranslated());

Ale właśnie sposobow na powiazanie Request i Router sa tysiace i kazdy dobry... to juz rozwiazal kazdy z nas

Pytanie jak zorganizowac generowanie URLa bo jak dla mnie
$request->GetRouter()->CreateURL(array()); jest troche logicznie glupie :]

$request->getRouter() mi nie pasuje. Bo zwykły request nie wie, co to jest router i nie powienien się tym zajmować. A jeżeli napiszemy RoutedHttpRequest extends BasicHttpRequest, to nagle okaże się, że cała idea z wymienialnym requestem wzięła w łeb, bo potrzebne są nam nowe metody w RouterHttpRequest. I nic nie da się z tym zrobić, bo AdvancedRoutedHttpRequest extends AdvancedHttpRequest, RoutedHttpRequest jest niedozwolone.

@serafin: $request->setData() jest niebezpieczne, bo nie tylko router może użyć tej metody. Niemodyfikowalny request ma swoje zalety. Czasami może to być przydatne, ale w ten sposób nie mielibyśmy możliwości zablokowania tego.

@bela_666: problem nie polega na tym, jak dopasować akcję, ale co zrobić z pozostałymi parametrami podanymi w URLu. AFAIK, Cocoon też nic sensownego z nimi nie robi. Dopasowuje i tyle.

Pozostałe? Dla mnie nie ma pozostałych, są tylko właściwe, akcja używa jakiś parametrów i juz A jakich to wybierasz przez {1}, {2} etc.

a takie rozwiązanie:

Kontroler z routera pobiera nazwę akcji i wszystkie parametry, a następnie parametry przekazuje w argumencie do akcji:

[PHP] pobierz, plaintext 
<?php
interface Action
{
	public function Perform( IHttpRequest $oRequest, IHttpResponse $oResponse, $aParams );
}
?>
[PHP] pobierz, plaintext 

albo przekazywac cały Router do akcji

[PHP] pobierz, plaintext 
<?php
interface Action
{
	public function Perform( IHttpRequest $oRequest, IHttpResponse $oResponse, IRouter $oRouter );
}
?>
[PHP] pobierz, plaintext 

Router z kolei ma funkcje do pobierania parametrów.

Jest to moim zdaniem rozbicie odpowiedzialności ($_GET lub PATH_INFO idą przez Router, reszta przez Request) ale nic sensowniejszego nie wymysliłem

Nie lepiej wladowac dane z router'a do request-u :?:

[PHP] pobierz, plaintext 
<?php
//...pola klasy
class request
{
public function __contruct()
{
$this->post_data=$_POST;
$this->get_data=adressRouter::translateURL();
//..itd
}
}
 
?>
[PHP] pobierz, plaintext 

@bela_666 a jak masz powiedzmu w url'u zakodowane jak posortowac jakas liste i wg jakiego pola to akcja moze sie spokojnie odwolywac do parametrow ale trzeba to jeszcze zamienic na url potem

@hawk blokujemy zapis danych typu $_SESSION $_COOKIE w Requescie to jak chcesz dodac nowe dane do ciasteczka albo serializowac w sesji obiekt koszyka uzytkownika to jak chcesz to rozwiazac??

Co do genracji linków - może zrobić tak :?:

[PHP] pobierz, plaintext 
<?php
 
class linkGenerator
{
public static function generate(&$data)
{
return router::generateLink($data);
}
}
 
?>
[PHP] pobierz, plaintext 

linkGenerator byłby poprostu osobną klasą w systemie, bo wg. mnie nie nadaje się on ani do requestu ani do routera.

Co Wy na to :?:

No wedle tego co tu powiedziano glownym zadaniem rutera jest odszyfrowywanie akcji z url'a oraz zamiana potem na url'e wiec jak nie pasuje to routera?

Dobre pytanie czy ja muszę sie słuchać tego co powiedzieli inny :?:

Pozatym wpadłem goże godzinę temu na inne rozwiązanie. Najpierw zmieńmy lekko definicję routera. Router - klasa/komponent/itp która jest odpowiedzialna za 'obsługę ruchu' w aplikacji - if u know whats I mean.

Router dzielimy na dwie klasy: UrlTranslator oraz LinkGenerator. Teraz wydaje mi się, że wszystko się trzyma do kupy

Hmmm :?:

U mnie to nawet nie sa 2 klasy a dwie metody: encodeUrl i decodeUrl

jesli router mialby sie zajmowac kodowaniem i dekodowaniem url znaczy ze do widoku musi przekazac wszystkie zakodowane URL'e. A gdyby tak przekazywac do widoku odpowiednie parametry i widok z nich skladal by sobie url'e? Ma to jakies ograniczenia (to rozwiazanie)?

Ja gdy korzystam z czego ala router, robie w szablonach po prostu

<?php echo $tpl->URL('index.php?param1=a&param2=b');?>

ewentualnie dla maniakow smarty

{url href="index.php?param1=a&param2=b"}

Hmm u mnie np. linki genrowane są w... pluginie systemu szablonów. Tj. pobieram z konfiga aplikacji router (np. NiceUrl) który implmentuje interfejs IRouter, w tym interfejsie deklrauję IRouter::buildUrl() , którą wykorzystam w pluginie.
Do plugina wrzucam w ten sposób (używam savanta)



gdzie news to zmienna page czyli moja akcja/widok , a to co w tablicy to parametry...

No to właśnie u mnie jest to samo :] Ale dla przejrzystości używam standardowego URLa php który potem konwertuje do tablicy przez parse_url()

Po co kombinować w jakieś parametry widoków :]

OK.
Wrocmy na chwile do Requesta, jedna z jego podstawowych f-cji jest przefiltrowanie wszystkich zmiennych/tablic jakie skrypt dostaje na wejsciu. Np dla $_GET:

[PHP] pobierz, plaintext 
<?php
foreach ( $_GET as $key => $value )
		{
			if ( ctype_alnum ( $key ) and ctype_alnum ( $value )  )
			{
				$this->HttpGetVars[$key] = $value;
			}
		}
?>
[PHP] pobierz, plaintext 

zakladam ze zarowno klucze jak i wartosci moga byc [a-zA-Z0-9] dla tablic $_GET, $_POST, $_SESSION, $_COOKIE i wtedy sa bezpieczne wartosci. Czy moze sie zdazyc w ktorejs z tablic ze beda potrzebne inne dozwolone wartosci? W $_GET i $_POST wg mojej filozofii nie ale $_SESSION i $_COOKIE ?

Po za tym takie przefiltrowanie to dla akcji za malo bo na arzie wiemy ze wartosci sa bezpieczne ale nie wiemy czy sa poprawnego typu bo np. $_GET['id'] dla akcji powinien byc wartoscia calkowita a $_POST['author'] powinien zawierac tylko [a-zA-Z]. Czy kontrole poprawnosci typu zostawic Requestowi? czy tez moze lepiej zeby akcja sie tym zajela ale skoro akcja to po co na poczatku filtrowac wszystko jak i tak nie przeszlo by to przez filtr poprawnosci typu danych akcji.

Zapomniałes o tablicach :] W szczególności w POST często się je stosuje

POST stosuje tablice? nie rozumiem.
Ale wlasnie sie zreflektowalem ze mze i dla wszystkich kluczy takie rzumowanie jest dobre ([a-zA-Z0-9]) ale w poscie moze byc juz cokolwiek i do tego polskie znaczki.
$_GET bym zrobil tak jak pokazalem ale na $_POST juz trzeba cos lepszego np.:

[PHP] pobierz, plaintext 
<?php
foreach ( $_POST as $key => $value )
		{
			if ( ctype_alnum ( $key )  )
			{
 // teraz albo na podstawie jakies mapy oczekiwanych wartosci robie filtracje
// wartosci zmiennej ale zostawiam dalszy ciag sprawdzania akcji 
				$this->HttpPostVars[$key] = $value;
			}
		}
?>
[PHP] pobierz, plaintext 

Sa dwie rzeczy, ktore mi nie pasuja:
1. Chcialbym utrzymac konsekwencje w dzialaniu i jesli $_GET przefiltruje w calosci za pomoca metod Requesta to z innymi tablicami chcialbym robic to samo w tym samym miejscu zeby zapobiedz balaganowi w aplikacji.
2. Chcialbym uniknac powtarzania kodu np. w kiedy akcja ma sprawdzic poprawnosc typu $_GET['id'] i zrobi to tak:

[PHP] pobierz, plaintext 
<?php
 
if (is_int($this->HttpGetVars['id']))
{
//... costam
}
else
{
 // jakis wyjatek
}
?>
[PHP] pobierz, plaintext 

i tak w kilku akcjach to mamy mnostwo powtarzalnego kodu

GET: index.php?tablica[klucz1]=wartosc1&tablica[klucz2]=wartosc2
POST:
<input type="checkbox" name="tablica[]" value="wartosc1"/>
<input type="checkbox" name="tablica[]" value="wartosc2"/>

@Vengeance juz rozumiem o co Ci chodzilo ale nie stosuje czegos takiego bo nie wiem po co zwlaszca ze wprowadza troche zamieszania. Potrafisz mi podac przyklad gdzie uzycie czegos takie jest najprostrzym sposobem na uzyskanie czegos?

<input type="checkbox" name="wybrane[]" value="mysql"/>
<input type="checkbox" name="wybrane[]" value="sqlite"/>
<input type="checkbox" name="wybrane[]" value="oracle"/>

takie pola formularza (mozliwosc szybkiego dodania wiekszej ilosc) + w razie bledu w jakims innym polu, zazaczone pola maja byc zapamietane i zaznaczone automatycznie

Przy wykorzystaniu tablic w POST, mozesz szybko i bezbolesnie cos takiego zrealizowac, jedna petelka i juz :]

Z walidacją ciężka sprawa... ja jeszcze dorzucę, że request powinien "odtegowywać" magic_quotes_gpc.

A co do rozbijania routera na 2 klasy: właśnie po to jest to jedna klasa, żeby nie było ryzyka, że kodować będziemy tak, a dekodować inaczej. I cała aplikacja padnie.

No dobra - zachowajmy tą nową definicję ale zamiast tego będą dwie metody w klasie - wiadomo do czego. Sam router będzie posiadał wczytany na początku schemat URL który najpierw odczyta o potem będzie tworzył

zalozmy na chwile ze nasza apikacja moze byc wywolywana w rozny sposob najczesniej przez rzadanie HTTP albo z lini polecen. Jak rozpznac jakie wywolanie nastapilo zeby wlaczyc odpowiedni Request? Czy sprawdzanie poprzez apache_request_headers() czy jakies naglowki HTTP zostaly odebrane to dobry pomysl?