![]() |
![]() ![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 2 291 Pomógł: 156 Dołączył: 23.09.2007 Skąd: ITALY-MILAN Ostrzeżenie: (10%) ![]() ![]() |
Witam powoli koncze swoj framework brakuje mi 2-3 bibliotek do napisania, zrobic mini dokumentacje, i poprawic sama hermentyzacje projektu bo gdzie niegdzie zle ja stosowalem i ogolnie jakies mniejsze poprawki bo wszystko wyjdzie najaw jak postawie na nim pierwsza strona(czyli strone domowa fw (IMG:style_emoticons/default/biggrin.gif) ).
Chodzi mi o to ze zanim bede konczyl fw(przynajmniej wersje beta bo napewno znajda sie jakies poprawki w czasie kodzenia) nie wiem czy nie dodac do niego wyzej wymienionych rzeczy, sam admin generator mnie dreczy od samego poczatku tego projektu a idea ACL przeleciala mi przez mysl w ostatnim tygodniu. O ile sam ACL nie wiem czy mi sie przyda to admin generator tak, a dlaczego: -Bo po pierwsze po postawieniu strony mamy juz gotowy "PA" w ktorym sa juz zaimplementowane podstawowe czynnosci. -Nie trzeba bedzie pisac dodatkowego komponentu/pluginu jesli defaultowy PA wystarczy do zarzadzania strona. -Duzo zaoszczedzonego czasu. Co mialby robic ten Admin Generator, jako ze nie wiem jak dziala ten z ZF(a tam chyba jest) bo nie sprawdzalem, chcialbym by mial takie akcje jak: Cytat -Wyswietlanie konfiguracji -Dodawanie,Usuwanie komponentow/pluginow z podstron -Calkowite odinstalowywanie komponentow/pluginow z systemu -Instalacja komponentow/pluginow/filtrow online, krotko mowiac upload archiwum, lub pojedynczyc hplikow(tzn nie spakowanych poprzez multiupload) -Dodawanie filtrow na dany komponent/plugin Wszystko dzialaloby za pomoca malej konfiguracji PA ktory poprostu bedzie automatycznie generowal wszystkie dane(pola formularzy) do zarzadzania komponentami/pluginami i filtrami Mysle ze do podstawowego zarzadzania strona wystarcza jak znajdzie sie potrzeba mozna napisac PA jako dodatkowy komponent/plugin dla systemu. Teraz kwiestia ACL, u mnie mam normalna autoryzacje i autentyfikacje na podstawie lewelu user'a od 0 do 5 czyli guest,user,vip,mod,admin,superadmin tak samo kazdy komponent i plugin maja w katalogu widokow(views) podkatalogi z nazwa grupy(te podane wyzej) i sam system po podaniu mu nazwy widoku do wczytania pobiera z jakie grupy ma byc widok i w jakim jezyku. Wiem ze nie jest to super elastyczne ale jesli chodzi o jakies podstawowe roznice pomiedzy stronami dla danych grup jest wygodne np linki do usuwania,edytowania news'ow to pesta bez zbednych komplikacji na poziomie kontrolera, tylko w czasie wywolania akcji do np: usuwania news'a sprawdzyamy czy user ma dana grupe i tyle, proste i schludne jedyny minus to to ze jest wiele plikow z prawie takimi samymi widokami. Sam system jako tako zostanie. Ale co jesli bede mial potrzebe zrobic tak by user oprocz tego ze bedzie mogl czytac i komentowac news'y mogl tez je pisac i ewentualnie edytowac. Wiec tak obmyslalem swoj sposob taki pseudo ACL a moze i nawet acl nie wiem. Wiec wiem ze mam grupy takie jak guest,user,vip,mod,admin,superadmin. Moge zrobic tak ze moge tworzyc podgrupy isniejacych juz grup i wszystko zapisac w nowej tabeli role z kluczem obcym hash z tabeli users ktory identifikuje danego uzytkownika. Np podgrupa Newsman, napisalbym tak klase ze poprostu za pomoca jakiegos formularza i/lub recznie molgbym do bazy dodac nazwy dodatkowych akcji ktore moze wykonywac user z dana podgrupa oprocz tych do ktorych ma prawa kazdu USER. Np przy napisania news'a w akcji AddNews() mialbym w warunki:
Funkcja allow robila by zapytanie do bazy z unikalnym id user'a z sesji po czym sprawdzala by czy akcja w url(www.cos.pl/index.php/Home,Index,AddNews) czy user posiada dostep do danej akcji. Co o tym myslicie? Sorki za taki dlugi post jednak sa to dosc wazne elementy systemu dlatego pytam oczywiscie wczesniej poczytalem troche na PRO i Arch. PRO. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 23.08.2025 - 11:08 |