1. Jaka jest ich wlasciwie koncepcja? Staram sie dojsc z czase mdo tego, ze prefilt wykonuuje sie przed wykonaniem ackji w celu przygotowania odpowiednich danych poczatkowych lub warunkow jakie ma spelniac sygnal wejsciowy i after filtr, wlsnie po co? Ja rozumiem zwalniac pamiec w C itd... ale jezeli skrypt sie wykonuje i wszystkie dane, zmiennie i wartosci gina po zakonczeniu skryptu (oczywiscie bez sesji i cookie itd) to wlasnie nie rozumeim zastosowania tego zbytnio.

2. Drugie moje pytanie/problem. Czy warto nadawac priorytety? Doszedlem do wniosku, jako ze wywolanie niektorych filtrow zalezy bezposrednio od wartosci wykonania i stworzenia danych za posrednictwem innego filtra, to trzeba je w jakis sposob zsynchronizowac. Ale czy to jest dobre rozwiazanie, a moze ja sie po calosci myle? Moze Filtry maja byc niezalezne (ale wtedy nie moglbym osiagnac tego czego oczekuje) .

Moglby ktos to skomentowac/wytlumaczyc (filtry "po" i zwiazki miedzy nimi) ?

IMO :
- filtry powinny być niezależne od siebie, ale korzystać z context ( request, response, ja mam jeszcze configuration oraz currentUser )
- jeśli chodzi o kolejność wywoływania to u mnie jest to dość proste rozwiązanie, który pierwszy dodam ten pierwszy się wykonuje
- można wiele rzeczy dodać do filtrów, np. benchmark, banowanie, start sesji ( czasem nie wystarczy samo session_start(), ale zależność od session_id()), osobiście posunołem się dalej i zrobiłem także zamyaknie połączeń z bazą danych oraz DispacherFilter ( przed wysłaniem do użytkownika headera zamykam połączenie z bazą danych )

Filtry służą do modyfikacji żądania, które nie zawsze może być spełnione. W zasadzie cały łańcuch wykonania powinien wyglądać w uproszczeniu tak:

żądanie użytkownika -> utworzenie kontekstu (dispatcher) -> pre-filtry -> łańcuch akcji -> post-filtry -> zwrócenie odpowiedzi na żądanie

Filtrowanie przed łańcuchem akcji służy najczęściej przygotowaniu bibliotek oraz sprawdzaniu czy akcja może zostać wykonana w danym kontekście (uprawnienia użytkownika itp.).

Po łańcuchu akcji możemy pozamykać wszystkie połączenia, a także zająć się obróbką danych wyjściowych. Osobiście traktuję w swoich projektach widok jako post-filtr.

Nie powinieneś wiązać ze sobą filtrów. Priorytety - zależy jak je rozumiesz. Najprostszym rozwiązaniem jest kolejka.

Myslac o priorytetach chodzi mi bardziej o okreslenie kolejnosci wykonania. Jezeli chodzi o zamykanie polaczenia z baza, to robie to odrazu po wykonaniu zapytania. Bo to jest chyba bardziej efektywne niz trzymanie otwartego polaczenia.

No tak, top nie bylo by problemow. Ale gdy mam filtr ladujacy configuracje aplikacji, kolejny, ustawia costam, a nastepny sprawdza dostep uzytkownika korzystajac przy tym z configuracji ktory zaladowal 1 filtr. I teraz problem pojawilby sie w momencie gdy w katalogu te pliki byly by inaczej ustawione (data modyfikacji itd) tak wiec zastosowanie priorytetu (kolejnosci wywolania byloby ok) tylko te slowa... zeby ich nei wiazac. To kiedy w takim razie powinienem zaladowac configi a kiedy uwierzytelnic i sprawdzic dostep uzytkownika, a kiedy inne pre.akcje

Moze nie dotarlem do takiego problemu zeby sie zaglebic w zastosowanie pre.filtorw. Ale jezeli baze zamykam po swojemu,a widok odpalam standardowo poprzez akcje, to nie widze dalej konkretnych zastosowan. Moglby sprobowac mi ktos przyblizyc jeszcze pare?

Wszystko musisz robić po kolei, dlatego zasugerowałem moje rozwiązanie - kolejkę. Wiązania ze sobą, rozumiałem raczej przez usunięcie zależności pomiędzy klasami filtrów. Co do działania, to jeden filtr może opierać się na efektach działania poprzedniego.

Nie wiem czy trzymanie otwartego połączenia ma jakiś większy wpływ na wydajność aplikacji.

Nikt nie każe używać filtrów. Jak każdy wzorzec, został stworzony, aby zwiększyć elastyczność aplikacji. To jest dyskusja w stylu programowanie proceduralne vs. obiektowe. Wszystko można napisać proceduralnie, tylko czy później będzie Ci wygodniej nad tym pracować... Jeżeli umiesz to porządnie wykonać bez filtrów, to nie widzę przeszkód w pominięciu tego wzorca.

Dlatego moze wlsnie chcialem rozwinac troche ta dyskusje o programowaniu proc vs obkt. Bo moze ja nie widzie pewnych zastosowan, i dlatego chcialbym zebysmy sprobowali rozwinac ten problem, jezeli nie bylo to poruszane na forum juz w dosc obszerny sposob.

Ah, Ludvik to musielismy sie zle zrozumiec, bo mi nie chodzilo o zaleznosci typu ze jeden korzysta z drugiego czy cos, tylko wlasnie o wyniki dzialania jednego a kolejne korzystaja z tych wynikow, ale jak wlasnie piszesz potrzebna jest kolejka (u mnie priorytety).

Dyskusja była poruszana, ale nie rozwinęła się za bardzo.

Może powiesz, jak u Ciebie wygląda:
- utworzenie połączenia z bazą
- autentykacja, autoryzacja
- wybór widoku (nie chodzi o szablon, tylko o sposób wyświetlania - np. html, xml, rss)

Najprawdopodobniej robisz to w kontrolerze i akcjach. Przy zastosowaniu tego wzorca sam kontroler nie interesuje się, co robią filtry, w związku z czym nie ma potrzeby grzebania w jego kodzie. Jeżeli inicjujesz i zamykasz połączenie z bazą (lub robisz coś innego) w akcjach, to zamykasz sobie drogę do wymiany sterownika bazy bez modyfikowania kodu akcji. Akcje powinny operować na danych, a nie zajmować się rutynowymi czynnościami, takimi jak te, które przed chwilą wymieniłem.

Moje polaczenie z baza polega na utworzeniu obiektu i stworzeniu polaczenia , wykonaniu zapytania i autmatycznemu zamknieciu polaczenia. Nie ma nic wspolnego z kontrolerem, a jedynie z modelami ktore poberaja dane i je przetwarzaja.

Autoryzacja pobiera config (no wlasnie sie zastanawiam, narazie jest na sztywno, ale chce walnac go co filtra ladujacego configi)

[PHP] pobierz, plaintext 
<?php
class pre_login {
 
var $oDebug;
var $oConfigs;
 
 function run($oAction) {
	 
	$this->oDebug =& Debugger::getInstance();
	$this->oConfigs =& Configs::getInstance();
		 
	$Logged =& userLogin::getInstance();
 
	if ((!$Logged->isLogged() AND $oAction->oGet->getParam(1)!='login') OR 
		($Logged->oAccess->access<=0 AND $oAction->oGet->getParam(1)!='login')) {
 
		header("Location: ".MAIN_DIR."panel.php?login");
 
	} elseif ($oAction->oGet->getParam(1)!='login') {
 
		$oAction->oView->assign('user',$_COOKIE['login']);
		$oAction->oView->assign('access',$Logged->oAccess);
 
		$Logged->login($_COOKIE['login']);
 
	}
}
 
}
?>
[PHP] pobierz, plaintext 

A wyswietlanie za pomoca SMARTY (html), przekazuje nazwe widoku i po prostu odpalam.

No i ostatecznie zgodze sie z Toba. I racja jest ze kontroler nie interesuje sie filtrami, jak pisalem wyzej , wg mnie one maja przygotowac jedynie, dane potrzebne do analizy przed wykonaiem akcji. Jeszcze to idzie dosc prosto zrozumiec, lecz problem pojawia sie w zastosowaniach after.filtrow? Bo co jak co, ciezko mi sie doszukac jakiegos konkretnego zastosowania (no oprocz tworzenia widoki, jak napisane bylo wyzej)

Czyli przy 5 zapytaniach 5 razy się łączysz i 5 razy robisz close? przeciez nawiązanie połączenia zajmuje najwięcej czasu

Mogę Ci podać przykład, który od dawna chodzi mi po głowie - cache. Zapis do cache odbywa się w post-filtrze, a odczyt w pre-filtrze. Zastosowań jest wiele, niekoniecznie są one zawsze potrzebne.

Ludvik pomysle, narazie zrobilem jedynie cache zapytan do bazy ale to tak zostawie i nie sa one w filtrach. Ale rozmyslam nad cachowaiem klas i reszty porzebnych plikow alpikacji do includowania.

ActivePlayer, no wlasnei mnie zagiales. Jakis czas temu czytalem taka madra ksiazke i tak mi sie cos ubzduralo ze widzialem wlasnie takie podejscie do funkcji mysql_close() jak uzylem u siebie, i nie wiem czy mi sie to przewidzialo (ale raczej nie, bo jakos wpadlo mi to do glowy) I moze chodzi oto ze utrzymujac polaczenie z baza przez czas trwania calego skryptu zuzywamy zasoby servera php, a laczenie i rozlaczanie natychmiastowe wykorzystuje to tylko wtedy gdy jest to potrzebne. Nie jestem tego pewnien. A z drugiej strony w takim badz razie po co stosowac mysql_close() jezeli polaczenie i tak zostanie zamkniete na koniec skryptu, nawet jezeli polaczenia sa wielokrotne.