2015-06-30 8 views
6

proszę o wyjaśnienie, proszę, koniecznie.Nawigacja między rodzicami i dziećmi w wielu zakładkach

Tło systemowe: Tworzę system nawigacji parenting-> child dla zaplecza CMS. Buduję adresy URL takie jak: [domain.ext]/[moduleName]/[objectName]/[actionName]/[ID #1]/[ID #2].

URL wyjaśnione (np example.com/PageManagement/Page/Modify/7/13)

  • moduleName: Nazwa modułu obiektu należy do (na przykład "PageManagement")
  • objectName: Nazwa obiektu (np. "Strona")
  • actionName: nazwa akcji (np. "Modyfikuj")
  • ID # 1: albo identyfikator rekordu działanie jest wykonywane na, lub identyfikator rodzica obiektu
  • ID # 2: identyfikator rekordu, w którym wykonywana jest czynność, , ale tylko jeśli identyfikator nr 1 jest wypełniony rodzica ID

Nawigacja odbywa się przez analizowanie adresu URL jego składników, zmniejszanie nazw do identyfikatorów systemu itp., A następnie pobieranie pól i danych, które mają być wyświetlane na stronie.
Aby zapewnić, że adres URL pozostanie czytelny i logicznie zrozumiały, nie dodaję wielu warstw identyfikatorów nadrzędnych do adresu URL, ale raczej zachowam kilka ostatnich identyfikatorów nadrzędnych w tablicy PHP $_SESSION, dzięki czemu mogę określić w nawigacji czy inny identyfikator rodzica musi zostać dodane.

Przykład: obraz mamy obiekty Page->Extension->Field, które mają wszystko w module PageManagement i wychowywane od lewej do prawej. Teraz załóżmy, że mamy stronę z identyfikatorem 2, rozszerzenie o ID 8 i pole z identyfikatorem 17. Adres URL edycji pola będzie example.com/PageManagement/Field/Modify/8/17, ponieważ edytujemy pole 17, które ma rozszerzenie 8 jako obiekt nadrzędny. Adres URL do edycji rozszerzenia to example.com/PageManagement/Extension/Modify/2/8, ponieważ edytujemy rozszerzenie 8, które jest nadrzędne. Edytowanie strony byłoby po prostu example.com/PageManagement/Page/Modify/2, ponieważ nie ma rodzica.

Problem: Wszystko to działa idealnie. Jednak, jeśli wiele kart jest otwartych, mają one ten sam numer $_SESSION, więc nawigacja w jednej zakładce może zrzucić historię nadrzędną dla drugiej zakładki. Nadal działa poprawnie w każdym przypadku, ale fakt, że I może spowodować, że jest zły (ponieważ ktoś może dodawać/usuwać/edytować dane, nie wiedząc, że są one rzeczywiście na niewłaściwej liście nadrzędnej).

Co potrzebne: Muszę sposób, z każdym żądaniem, aby ustalić, która karta okazało, najprawdopodobniej poprzez generowanie jakąś formę UID na karcie i wysyłanie, że z każdym żądaniem. Mój system może następnie przechowywać historię nawigacji na karcie zamiast na sesję.

Rozpatrywane rozwiązania

  • generowania UID na sesję strony i zapisywanie tego w Window.sessionStorage (który zostanie zresetowane za każdym nowym oknie/karcie). To pozwoliłoby mi wygenerować jedną, jeśli żadna nie jest jeszcze ustawiona (czyli nowa zakładka), a tym samym mieć inną zapisaną (i zapamiętaną) sesję na stronę.
    • Problem: nie wiem, jak mogę, że UID wysyłane do serwera z każdego żądania. Pliki cookie sesji wydają się być wspólne dla wszystkich kart (ma to sens, ponieważ udostępniają sesję).
  • Generowanie UID na sesję strony i dołączanie jej do adresu URL jako ciągu zapytania.
    • Problem: równie dobrze mogę nie mieć ładne adresy URL, a jeśli ktoś (przypadkowo) edytuje/usuwa go, będzie to nadal nie działa. Skopiowanie/wklejenie adresu URL może stanowić problem.
  • Generowanie UID na sesję strony i poprzedzanie tego adresu URL przed moduleName.
    • Problem: To jest nadal widoczny/edytować/usuwać, a jeśli robią to nadal nie działa. Skopiowanie/wklejenie adresu URL może stanowić problem.

Jeśli ktoś może rozwiązać problemów wymienionych roztworach powyżej, lub pochodzić z zupełnie nowego rozwiązania, które byłoby niesamowite. Oczywiście wolałbym wprowadzić jak najmniej zmian w systemie URL, ale jeśli to jedyne rozwiązanie, to niech będzie ...

+1

Twoje adresy URL są fundamentalnie błędne. Zamiast polegać na kontekście serwera, żądanie złożone z adresu URL i BODY powinno zawierać wszystkie informacje potrzebne do wykonania operacji. Kontekst serwera powinien być używany do sprawdzania poprawności/autoryzacji, nie więcej. – Amit

+0

@Amit Więc zasadniczo mówisz, że ja ** powinien ** mieć wszystkie identyfikatory rodziców w adresie URL, bez względu na to, ile może być? Czy byłbyś bardziej skłonny do "example.com/PageManagement/Field/Modify/2/8/17" (czyli co już mam, tylko wszyscy rodzice dodali), czy wolisz 'example.com/PageManagement/Page/2/Extension/8/Field/17/Modify' (całkowicie zrestrukturyzowany, aby mieć nazwę i identyfikator każdego obiektu oraz akcję na końcu)? – Byson

+0

Dodam do tego, że samo zapytanie http (adres URL, nagłówek, treść) powinno opisywać działanie. Myślę, że używanie adresów URL, takich jak 'example.com/PageManagement/Page/2/Extension/8/Field/17/Modify', nie wymaga objaśnień i jest łatwe do utworzenia. – Mat

Odpowiedz

1

Istnieje podstawowa luka w projekcie żądania, która powoduje, że wszystkie kłopot.
System powinien dążyć do uwzględnienia wszystkich istotnych informacji w jednym wniosku, gdy tylko jest to możliwe. W twoim przypadku oznacza to porzucenie mechanizmu, który "pamięta" wcześniejsze żądania (stan ..) w $_SESSION i zamiast tego przekazuje wszystkie informacje w żądaniu. Może znajdować się w adresie URL ("adres" i/lub ciąg zapytania), w razie potrzeby w nagłówkach (zwykle przy użyciu plików cookie. Prawdopodobnie niewłaściwy w tym przypadku) lub treści (w taki sam sposób, jak formularze POSTed przekazują dane).

Istnieje wiele powodów, aby wybrać tę drogę, aby wymienić tylko kilka z nich:

  1. Poprawa rejestrowanie.
  2. Łatwe debugowanie.
  3. Włącz proste, oparte na adresach URL łączenie (przy użyciu tylko adresu URL dla żądań).
  4. Ogranicz ryzyko nieprawidłowego buforowania (lokalnego lub zdalnego).
  5. Obsługa wielu jednoczesnych „wnioski” -> pomoże przezwyciężyć obecną problem :-)

Jak zawsze, nie reguła idzie bez wyjątków. W takim przypadku najczęściej stosowaną informacją, której NIE można uwzględnić w każdym żądaniu, są informacje uwierzytelniające (nazwa użytkownika, hasło itp.).

Podsumowując, należy zdecydowanie rozważyć rekonstruowanie swoich żądań, tak aby wszystkie wymagane informacje są dostępne.

Powiązane problemy