URI, path info i budowanie linków, implementacja obiektowa - problem Opcje

[Beynar]

Od paru dni nie moge sie uporać z tym cholernym URI.

przychodzi rządanie do aplikacji:

http://www.example.com/jezyl/kontroler/akcja/parm0/parm1

Z ostatniego fragmentu adresu: home/index/parm0/parm1 powstaje obiekt routesPath czyli trasa routowania ktory ma za zadanie dostarczyć routerowi informacje jaki kontroler(klase) ma wybrac, jaka akcje(metode) i z jakmi parametrami(argumentami). Nalezy zatem napewno rozbic string "kontroler/akcja/parm0/parm1" i wyszczegolnic z niego tablice umozliwajac w ten sposob routerowi latwy dostep do elementow trasy routowania. Klasa routesPath ma umozliwiac rowniez szyfrowanie czyli przychodzi 7ji0/fj94/jv94/gj943/vjn84 a ja wiem ze chodzi o /pl/home/index/....

Drugim miejscem w ktorym korzystam z obiektu routesPath bedzie widok. Trzeba jakos zbudowac linki dla uzytkownika. Trzeba skorzystac z algorytmow szyforwania do budowania linkow wiec bedzie to ten sam obiekt reprezentujacy PATH INFO - rouestPage.

routesPath to obiektowy odpowiednik stringu PATH INFO

1. routesPage moze przesyla rowniez dane takie jak język, SESID itd. Jak to zalatwic podczasu budowania linku skoro nie znam tych danych? uzupelniac automatycznie? jak?

2. Za kazdym linkiem w widoku (a bedzie ich durzo) tworzyc obiekt routesPage aby umozliwic szyfrowanie linkow oraz latwe tworzenie linkow? Wydajnosc?

3. Tworzac nowy routePath robie to w ten sposob:

[PHP] pobierz, plaintext 
<?php
$o = new routePath("pl/news/show/19/35");
?>
[PHP] pobierz, plaintext 

zdrowy rozsadek podpowiadalby, zeby konstruktor odrazu go rozkladal i wyznaczal kontroler akcje itd.. ale po co jesli jest on tworzony w widoku i chodzi tylko o zaszyfrowanie go i wydrukowanie stringu. Lub paradoskalna sytuacja kiedy szyforwanie jest wylaczone to obiekt ten powienien zwrocic to samo co przyjol. Paradoks! gdzie tu wydajnosc?

Będę wdzięczny za wszelkie sugestie.

pozdrawiam, Kuba

Ten post edytował Beynar 18.05.2008, 22:04:22

[.radex]

1: Zawsze też się zastanawiałem, jak to zrobić i ogólnie tego nie potrzebuję, ale u mnie to wygląda tak:

adres_strony/lang/pl/cosinnego/wartosc/news/read/nazwa-newsa

Czyli tak:

Ustalona ilość par nazwa-wartość : kontroler : funkcja składowa : pozostałe dane

Jednak to rozwiązanie też bardzo utrudnia sprawę. Musimy z góry ustalić ile tego będzie. A jeśli będziemy gdzieś potrzebować więcej - co wtedy? Link będzie brzdko wyglądał.

Takie dane staram się jeśli to możliwe przesyłać w inny sposób.

[Strzałek]

Pisałem o Routerze na moim blogu: http://strzalek.net/blog/3/przyjazne-urle-piszemy-router

[Beynar]

Ja ustalilem, ze dziele PATH INFO na trzy grupy:
1. elementy globalne (sesid, język, region itp)
2. trasa routowania (kontroler/akcja)
3. parametry

przy budowaniu linków w widoku (jak-kolwiek by nie byly budowane) robi się to w ten sposob $url -> build("kontroler/akcja/parametr0/parametr1");

Wiec budowanie linków uzaleznia mi jedynie to, ze musze podac kontroler/akcja a pozniej parametry. Natomiast daje mi to niezaleznosc co do ilosci i kolejnosci elementow globalnych tj. sesid, język itp. bo dokladaniem ich do wyjsciowego URL zajmuje sie klasa url. mozliwa jest rowniez modyfikacja tych elementow poprzez odpowiednie wywolania obiektu url.

Temat: Jak traktowac obiekty

PS. Biore sie za czytanie tekstu Strzałka

pozdrawiam

Ten post edytował Beynar 19.05.2008, 21:34:21