![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Przyjaciele php.pl Postów: 742 Pomógł: 0 Dołączył: 14.12.2003 Skąd: Gdańsk, Trójmiasto Ostrzeżenie: (0%) ![]() ![]() |
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: Kod --- klient --- czy router powinien byc oddzielny analizowac dane z httpRequest i na tej podstawie stwierdzac, którą ma akcję uruchomic:--- HttpRequest i Router w jednym --- --- kontroler - pobiera nazwe akcji z Routera --- Kod --- klient --- ?--- HttpRequest --- --- Router - analizuje HttpRequest sprawdzająca jaka akcja ma byc uruchomiona --- --- Kontroler - pobiera z routera nazwe akcji --- 2. Jeżeli ta pierwsza opcja to gdzie tu powinien by generator linków? Przecież nie za bardzo pasuje on do HttpRequest |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) ![]() ![]() |
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 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 8.10.2025 - 15:36 |