[MVC] Pytań kilka... Opcje

[NuLL]

Witam,

Rozdzielenie czesci administracyjnej od czesci uzytkownika

Chyba nic trudnego w stworzeniu dla kazdej akcji prostego configu z opisem do ktorej czesci aplikacji nalezy (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Pozdr.

[Vomit]

Ano nic trudnego, ale nie chce poprostu aby w folderze ktorym trzymane sa moduly byl takze trzymany admin a tpl'ki od admina lezaly w folderze reszty strony.

Niby blahy problem, ale nie chce robic w rodku Frontcontrollera if'a if ( $module == 'admin' ) to odczytuj z innego folderu ;p

[NuLL]

Vomit - nie rozumiem twojego podejscia - moze napisz sobie osobna aplikacje administracyjna (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif)

[mariuszn3]

front controler to raczej same if'y i switch'e, więc co zaszkodzi dodać jeszcze jeden (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
Reasumując jeśli nie możesz go zastąpić apachem to chyba nie ma miejsca na inne rozwiązanie.

[Denver]

Ja, gdy chcę mieć pewność, że uruchomine zostaną tylko i wyłącznie te moduły, które chcę, sprawdzam zawsze, czy mam je zapisane w jakiejś tablicy. Przykładowo:

[PHP] pobierz, plaintext 
<?php
$arrModules = array ('kontakt', 'galeria', 'rekrutacja', 'uslugi');
$arrAdminModules = array ('admin');
 
// Zmienna $strModule została nam przekazana z jakiegoś kontrolera, który odczytał
 ją ze zmiennych GET/POST
if (in_array ($strModule, $arrModules))
{
	// Uruchom dane akcje modułu
}
elseif (in_array ($strModule, $arrAdminModules))
{
	// Uruchom panel administracyjny
}
else
{
	throw new Exception ('Ten moduł nie jest obsługiwany');
}
?>
[PHP] pobierz, plaintext 

Oczywiście w panelu administracyjnym należy sprawdzić uprawnienia użytkownika do danych sekcji. Ja zazwyczaj trzymam uprawnienia w bazie, więc każdy moduł sprawdza sobie dane flagi przypisane konkretnemu użytkownikowi. Jeśli dostęp powinien być zabroniony, wyrzucam wyjątek i cześć.

[squid]

Rozdzielenie czesci administracyjnej od czesci uzytkownika. Poczynajac wlasnie od kontrolera. Rozwiazanie ciekawe, ale wymaga jak juz napisał dostepu do Apache'a.

Ja nie rozdzielam, nie wydaje mi sie aby to byl dobry pozmysl rozdzielac cos co z zasady ma byc jedno. Po co rozdzielac kontroler aplikacji skoro on ma kontrolowac przeplyw miedzy innymi czesciami aplikacji i w zasadzie na tym koniec. Dostajesz zapytanie ?action=x i kontroler przekazuje sterowanie do odpowiedniej metody i nie martwi sie o to co to jest x, moze sprawdzic czy istnieje ale to wszystko.

[Ociu]

Może poprostu pobawić się uprawnieniami ?

[bigZbig]

Ja nie wydzielam czesci administracyjnej. U mnie administrator widzi ten sam widok co zwykly user z tym wyjatkiem ze tam gdzie trzeba administratorowi pojawiaja sie jeszcze np. linki edit, delete, add itp. Wymaga to uzycia paru ifow, ale jest bardzo wygodne podczas pracy. Ogladajac cos jako uzytkownik nieraz zauwazam ze cos trzeba zmienic. W takiej sytuacji nie musze sie zastanawiac gdzie to mam w panelu administracyjnym. Zwyczajnie loguje sie jako admin (nie musze nawet przechodzic pomiedzy stronami bo skrypt logowania przekierowuje mnie spowrotem w miejsce z ktorego wyszlo zadanie logowania) i pojawia mi sie odsylacz edit. Prosto i wygodnie. Nie trzeba robic osobnych tplkow poza formularzami.

[Denver]

Popieram przedmówcę - to bardzo wygodne rozwiązanie. Logowanie przekierowuje do strony, która nas do ostatnio oglądanej strony, i te 2 IF-y w szablonach nie mają wpływu na wydajność skryptu. Szablon sprawdza mi uprawnienia danego użytkownika (odwołując się do obiektu User w którym przechowuję te uprawnienia) i jeśli np. użytkownik ma uprawnienie edycji newsów, to koło nagłówka wiadomości pokazuje się link do jej edycji.
Prosto i przyjemnie (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[br-design.pl]

Ja nie wydzielam czesci administracyjnej. U mnie administrator widzi ten sam widok co zwykly user z tym wyjatkiem ze tam gdzie trzeba administratorowi pojawiaja sie jeszcze np. linki edit, delete, add itp. Wymaga to uzycia paru ifow, ale jest bardzo wygodne podczas pracy. Ogladajac cos jako uzytkownik nieraz zauwazam ze cos trzeba zmienic. W takiej sytuacji nie musze sie zastanawiac gdzie to mam w panelu administracyjnym. Zwyczajnie loguje sie jako admin (nie musze nawet przechodzic pomiedzy stronami bo skrypt logowania przekierowuje mnie spowrotem w miejsce z ktorego wyszlo zadanie logowania) i pojawia mi sie odsylacz edit. Prosto i wygodnie. Nie trzeba robic osobnych tplkow poza formularzami.

Wszedlem na forum zeby wlasnie zadac to pytanie, super rozwiazanie, ALE, przeciez nie mozna wszystkiego tym rozwiazac, sa inne rzeczy niz tresc strony (np. administracja uzytkownikami, czy np. zamowienia w sklepie) , ktorych user nie widzi, wiec bez panela sie nie obejdzie.

Tak czy siak wracamy do problemu jak rozdzielic panel w MVC. Ja sklaniam sie do zrobienia osobnego frontcontrollera w katalogu admin (w glownym pliku htaccess dac regule ze przekierowania z domena.com/admin kierowac do katalogu admin gdzie czeka juz inny front controller niz domyslny), wtedy controllery, widoki trzymac w osobnych podkatalogach, ale z drugiej strony panel admina powinien moc korzystac z tych samych modeli co controllery glowne (userowe ze tak powiem).

Co o tym myslicie?

Ten post edytował br-design.pl 26.08.2006, 22:02:07

[bim2]

Po co rozdzielac. Pisali Ci juz poco? Dajesz w akacji metode np. add_item() i w add_item() dajesz if($admin==ok) ;P itp. Nie rozdzialaj a dodaj kolejne akcje (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[br-design.pl]

No przeciez pisze ze nie wszystko jest "add_item" chocby sprawdzenie zamowien w sklepie internetowym czy np. sprawdzenie platnosci itd. To rzeczy ktorych nie mozna zrobic sensownie ifem, musi byc jakis panel.

[bim2]

Nie o to mi chodzi :|
mam cos takiego:

[PHP] pobierz, plaintext 
<?php
class SklepAction {
function defaults() {} //domyslna akcja
function add_item()
{
		 if($admin)
		 {
				  formularz dodania pliku
		 }
}
function show_zamowienia()
{
		 if($admin)
		 {
				  spis zamówien
		 }
}
}
}
?>
[PHP] pobierz, plaintext 

I ja wywołałbym to tak: action=sklep&view=show_zamownienia (zmienan view tlkyo tak, mozna zmienić) I w czym problem?

PS. Pisałem z głowy ale powinno działac jeśli masz podobnie zbudowany Kontroller (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

Ten post edytował bim2 27.08.2006, 16:08:51

[br-design.pl]

A nie uwazasz ze zbytnio generalizujesz? Taka klasa jak sklepAction ktora oprocz obslugi sklepu bedzie miala jeszcze akcje do zarzadzania np. zamowieniami, uzytkownikami itd zrobi sie mocno przepasna.

Moim zdaniem zamowienia powinny byc osobnym kontrolerem gdzies wlasie w panelu, a jak nie w panelu to przynajmniej powinna byc jakos zabezpieczona przed dostepem.

i wtedy mozna zrobic osobne akcje dla pokzywania zamowien, zmiany statusu, edycji itd.

A dzieki osobnemu front controllerowi (dla panelu) ktory przyjmie obowiazek sprawdzania autoryzacji na siebie, nie musimy sie o to martwic w kontrolerach administracyjnych.

[bim2]

Nie wiem... może i tak. Tylko teraz jak to zrobić? Osobny kontroller? No nie wiem, ja by dał w starym kontrollerze nową metodę. Np executeAdmin() itp. i ona zajeła by się prawami i czytała akcję np, newsA.action a modele newsA.model.php itd. Może bardziej zaawansowani cos powiedzą (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) No albo zrobić osobny kontroller (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[altruista]

tak mnie meczy, w koncu odwazylem sie zaptac...

1.

Jest obiekt "pracownik" - dziedziczy z klasy GenericObject (odwzorowujacej tabele w bazie na obiekt) dodakowo sklada sie z innych obiektow dziedziczacych z GenericObject (np "opinia" - pracownik ma swoje opinie).


Pytanie 1:
Tworzac widok oparty na szablonie smarty, wypada przekazywac mu obiekt np typu "pracownik" zeby szablon sam siegnal do jego metod i powyciagal potrzebne dane (imie, nazwisko, opinie) czy lepiej dla widoku przekazac juz tablice asocjacyjna z wczesniej przygotowanymi danymi (to co w pierwszej propozycji wyciaga smarty, wyciamy wczesniej)... (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif)


2.

kontroler.
1. odwiedzam strone wpisujac http://strona.pl/?action=showPracownicy w celu wyswietlenia wszystkich pracownikow
2. glowny kontroler, analizujac parametr "action" includuje klase showPracownicy.class.php, (kazda klasa zaladowana przez kontroler, ma okreslony interfejs), tworzy obiekt tej klasy i wywoluje jego metode 'exec(HTTPReq $req)' (obiekt 'req' grupuje paramtery przeslane od uzytkownika, w tym wypadku nie jest konieczne przeslanie)
3. Funkcja 'exec(HTTPReq $req)' pobiera model (klasa ktora zawiera wszystkie operacje na pracownikach 'dodaj', 'usun', 'pobierz' 'wyszukaj' itp) i wywoluje jego funkcje 'pobierzWszystkichPracownikow()'; funcka zwaraca tablice/kolekcje obiektow typu 'pracownik'

Pytanie2:
Lepiej bedzie utworzyc widok w metodzie 'exec(HTTPReq $req)' obiektu klasy showPracownicy (jak tworzyc to poprzednie moje pytanie), przypisac wszystko do szablonu i go wyswietlic, czy tez zwrocic nazad do kontrolera nazwe widoku + w jakis sposob opakowane dane potrzebne do wyswietlenia, i niech glowny kontroler (ten z ktorym laczy sie uzytkownik i ten ktory stworzyl obiekt typu showPRacownicy) sobie podopisuje zmienne do szablonu i go wyswietli?



Nie wiem czy dobrze rozumuje cala koncepcje tworzenia oprogramowania, ale wole zapytac niz zaczynac pisac i uczyc sie zlych nawykow...

Watpliwosci:
3. czy rozwiazanie typu http://strona.pl/?action=nazwaAkcji jest prawidlowe? (powstanie pewnie bardzo duzo plikow a katalogu /actions/

Myslalem ze mozna np zrobic (pewnie tak sie robi) http://strona.pl/modul/funkcja/parametry i wtedy glowny kontroler bedzie ladowal klase 'modul' (zawiera wszystkie funkcje jakie sa dostepne dla modulu) i wywolywal jego metode 'funkcja' przekazujac jej 'paramtery' + tablice _REQUEST. Rozwiazanie daloby umieszczenie w jednym miejscu wszystkich funkcji zwiazanych z jednym modulem (kolejny problem to czy modulem moze byc "pracownicy" wraz z wszystkimi funkcjami czy to jest zla idea)


4. Czy mozna uzyc stwierdzenia 'model' w stusunku do klasy operujacych (zawiera wszystkie funckje jakie mozna wykonac z obiektem, np wyszukiwanie, itp) na obiektach 'pracownik'?

[LBO]

Ja nie wydzielam czesci administracyjnej. U mnie administrator widzi ten sam widok co zwykly user...

Gdzie wpisujesz te if'y? W pliku widoku (template'cie)? Czy w akcji zmieniasz templaty? Jeżeli, w pliku widoku jak radzisz sobie ze złożonymi zależnosciami? Na przykład: zwykły user, może tylko oglądać. Moderator oglądać i edytować. Administrator oglądać, edytować i kasować. Jak?

Pytam się, bo mam z tym problem i jestem za robieniem osobnej aplikacji administracyjnej.

[Apo]

Gdzie wpisujesz te if'y? W pliku widoku (template'cie)? Czy w akcji zmieniasz templaty? Jeżeli, w pliku widoku jak radzisz sobie ze złożonymi zależnosciami? Na przykład: zwykły user, może tylko oglądać. Moderator oglądać i edytować. Administrator oglądać, edytować i kasować. Jak?

Pytam się, bo mam z tym problem i jestem za robieniem osobnej aplikacji administracyjnej.

Ja to rozwiązałem tak że każda akcja ma swój konfig a w nim wymagane grupy, czy ma być publiczna, czy dostępna po zalogowaniu oraz akcje domyślne w razie braku uprawnien.
Mam główną klase Access która kożysta z klas pomocniczych:
Config - czyta ustawienia z tablicy i udostępnia Api do ich obsługi,
Groups - sprawdza czy dany użytkownik należy do jakiejś grupy lub czy jest zalogowany etc...

W przypadku braku uprawnien do wykanania akcji jest ona forwardowana na domyślną z configu (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
A w samych akcjach mamy dostęp do klasy user która trzyma jego dane i łatwo możemy sprawdzać uprawnienia itp.

[LBO]

Ale jak to wygląda w praktyce? Masz różne widoki dla różnych grup? Czy w samym widoku ustawiasz co ma być widoczne dla poszczególnej grupy?

Wydaje mi się, że najbardziej zgodne z wzorcem MVC są osobne widoki.

Ten post edytował LBO 15.09.2006, 21:22:52

[Apo]

Ale jak to wygląda w praktyce? Masz różne widoki dla różnych grup? Czy w samym widoku ustawiasz co ma być widoczne dla poszczególnej grupy?

Powiedzmy że mam za zadanie wyświetlić dodatkowe dane dla moderatora forum (przycisk: usun, edytuj, przenies) czyli w pliku widoku robi za pomocą Apletu (który ma dostęp do HttpContext, klasy Usera, Modelu) warunek:

plik widoku post.php

Kod

<h1>{$title}</h1>
<?php
if($this->user->hasGroup('moderator'))
{
echo '<a>Edutuj, zmien, usun</a>';
}
?>

dalsza czesc szablonu ....

Aplet 'user' ma metoda hasGroup która sprawdza czy user ma daną grupe:

[PHP] pobierz, plaintext 
<?php
 
Aplet user extends Apos_View_Aplet {
 
public function hasGroup($name)
{
  return $this->user->hasGroup($name);
}
}?>
[PHP] pobierz, plaintext 

Ten post edytował Apo 15.09.2006, 21:34:02