![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 382 Pomógł: 0 Dołączył: 29.11.2005 Skąd: :jestem(); Ostrzeżenie: (0%) ![]() ![]() |
Witam
problem opiszę na przykładzie : - mamy w bazie rekord który dla różnych profili użytkownika wyświetla inne kolumny Gdzie powinno się znaleźć zapytanie o rekord ? - czy w klasie ModelUserProfil dziedziczącej po klasie ModelUser (chyba nie) ? ( tutaj mamy tylko kod do operacji na danych użytkownika ) - czy w klasie ModelDane która odpowiada za dane które chcemy uzyskać (raczej tak) ? ( wtedy trzeba do ModelDane przekazać informacje o profilu bierzącego użytkownika ) - czy w klasie ViewDane który generuje odpowiedni widok dla bierzącego usera (zdecydowanie tak) ? ( przekazujemy informacje o profilu użytkownika do widoku i na tej podstawie wyświetlamy tylko własciwe dla użytkownika dane, ale pobieramy zawsze komplet danych ) 3 rozwiązanie chyba najlepsze, tylko w ModelDane zawsze byśmy pobierali te same dane, a nie każdy profil wymaga pobrania danych dla rekordu z 3 tabel (po np. jeden z profili wymaga danych z jednej tabeli) - co wtedy z wydajnością ? Jak rozwiązujecie to u siebie ? pzdr |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 382 Pomógł: 0 Dołączył: 29.11.2005 Skąd: :jestem(); Ostrzeżenie: (0%) ![]() ![]() |
Tworzenie DAO dla każdego użytkownika jest chyba najlepszym rozwiazaniem ( wg mnie najbardziej elastycznym w kontekscie zmian ). Rozumiem też, że w tej sytuacji trzeba będzie budować odrębne klasy prezentacji danych ( lub szablony ) (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) lub widok generować wspólny, ale każdy przycisk/link/cokolwiek w tym widoku (wywołujący kontroler/metodę/akcję) sprawdzać przed wyświetleniem uwzględniając właśnie uprawnienia użytkownika ... i może to że użytkownik jest jego właścicielem (np ja edytuję swój post więc button edit mi się wyświetli) (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) ?
W tej sytuacji tworzenie odrębnych widoków (bądź jego elementów) wydaje się dobry rozwiązaniem, chociaż wg mnie nie jest to najlepsze rozwiązanie (w przypadku zmian nie jest to już jeden szablon)
Skomplikowane moze być pobieranie danych w aspekcie jakiegoś lokalnego wydarzenia zależnego od parametru dla wskazanej funkcji w kontrollerze tzn. jestem moderatorem jakiegoś subforum na forum, i w moim subforum do przycisku usuń_posta uprawnienia mają już trzy osoby (user do swojego posta oraz moderator i administrator do każdego posta)...więc procedura spradzenia czy przycisk usuń_linka może odbiegać od innych. Obecnie walcze z uzyskaniem zgrabnego rozwiązania dla generowania widoków (zależnych od uprawnień) i dynamicznym przydzielaniem uprawnień . Wnoisek : mamy dla kontrollera DAO zależne od profilu użytkownika...czy z widokiem zrobić tak samo ? Poradzicie coś ? (IMG:http://forum.php.pl/style_emoticons/default/aarambo.gif) //////////////////////////////////////////////////////////////////////////////////////// Pozwolę sobię odświeżyć El Temato (IMG:http://forum.php.pl/style_emoticons/default/worriedsmiley.gif) Napisałem klasę wykorzystującą wzorzec Composite View, jest to jedna klasa która przyjmuje tablicę z danymi i nazwę szablonu - po czym podstawia zmienne,wykonuje kod php w szablonie i wyświetla lub przechowuje wynik uruchomienia szablonu.
Co zrobić z uprawnieniami do np. opcji w menu dostępnych tylko dla moderatora. Schemat działania widoku jest prosty - przyjmuje on już przygotowane przez kontroler dane....tzn że w kontrolerze zadecydujemy czy button USUŃ ma się wyświetlić bieżącemu userowi ? Kolejnym rozwiązaniem jest przekazanie danych o uprawnieniach do klasy View....tylko wtedy ta klasa powinna mieć możliwość komunikacji z modelem żeby w oparciu o uprawnienia odpowiednie dane pobierać. Czy ktoś potrafi przedstawić wstępny zarys działania takiej implementacji ? Można... - napisać 5 różnych szablonów tego samego widoku i ładować odpowiedni w zależności od uprawnień ? Nie mam już innego pomysłu ..... ------------------------------------------------------------------------- Może się komuś przyda (dla prostych wywołań typu CI czy VFrame) : - bieżący uzytkownik (zalogowany czy nie) ma jakiś tam profil (administrator/moderator czy Anonymous) - do szablonu widoku przekazujemy obiekt użytkownika - zanim wyświetlimy jakiś link lub przycisk sprawdzamy czy user ma uprawnienia do akcji wywoływanej przez ten link - sprawdzić instancję użytkownika można podczas wywołania kontrollera w jednej z jego metod lub w konstruktorze KLASA UŻYTKOWNIKA
KONTROLER
Czekam na słowa krytyki... Ten post edytował jastu 23.07.2007, 11:43:34 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 3.10.2025 - 08:27 |