Cześć.

Mam do napisania spory system CMS. Nie wiem jak się do tego zabrać tzn jaką logikę zrobić.

W systemie ma być sporo modułów z wieloma pod modułami np:

Produkty
Kategire
Produkty
Asortyment
Dane techniczne
Konfiguracja

Sklep
Klienci
Koszyk
Promocje
Rabaty

Użytkownicy
Uprawnienia
Lista
....

Wcześniej robiłem CMS ale dość małe robiłem sobie klasy dla każdej kategorii (tylko nie było podkategorii). Nie wiem czy robić dla każdej głównej kategorii duże klasy, czy dla podkategorii mniejsze klasy. Ładowanie modułów jakoś zautomatyzować czy klepać z palca wszystko (tzn wczytywanie i tworzenie obiektów). Zastanawiam się czy ładować wszystko ajax'em czy jechać normalnie. Niestety nie znam żadnego frameworka na tyle żeby się wziąć i pisać w nim (wynikło by z tego więcej złego niż dobrego).

Może macie jakąś inną koncepcje do tego albo jakieś sugestie jak to zrobić.

Znacznie prościej było by ci to napisać przy użyciu jakiegoś FW. Nie wiem do końca co oznacza pytanie małe czy duże klasy, przecież rozmiar ciała klasy zależy od tego jakie zadania ma ona realizować. Co do ładowania 'modułów' ja to mam zrobione na zasadzie, listy 'load_always' i tylko w razie potrzeby w danym widoku doładowuje potrzebne mi w tym momencie. Co do ładowania wszystkiego ajaxem to też nie moge tego polecić w 100%, jest to dobra technika ale stosowana z umiarem, potem wprowadza masę ograniczeń i komplikacji. Co do elementów które na pewno warto AJAXem zrealizowac to jakieś data_grid'y i walidacja formularzy.
Mimo wszystko pytanie jest zbyt ogólne i rozbite żeby jakos sensownie na nie odpowiedzieć niestety.

Przez duże czy małe klasy rozumiem że dla jak by zrobić klasę dla np produktów to będzie ona dość spora natomiast jak by robić klasy dla podkategorii to już będą one o wiele mniejsze. Wiem ze FW by znacznie ułatwił sprawę, no ale niestety nie znam żadnego dobrze a złym pomysłem było by się go uczyć i robić ten system.

Powiedzmy że mamy główne menu i odbiegając od pomysłu robienia wszystkiego ajax'em:

Produkty | Sklep | Strony | Użytkownicy

po wybraniu jakiejś kategorii i podkategorii np produkty->asortyment do url'a wskakuje jakaś zmienna GET, następnie ładujemy moduł widok .... tylko własnie pytanie jaka klasa czy klasa Produkty czy np produkty_asortyment. Natomiast wszelkie zmiany typu zmiana produktu czy zapis... leeciało by postem

myślałem zrobić jakąś klasę która by zarządzała ładowaniem modułów w zależności od uprawnień.

Ja zazwyczaj dzielę to na większe klasy odpowiadające opcją w menu, czasami jednak robię wyjątki dla jakichś niezwykle dużych sekcji, przykładowo 'szukaj' jest tam milion różnych opcji, szukania zaawansowane, ustawienia, historia, etc. etc. ale wszystko to i tak leży w Twojej gestii, zrobisz je tak duże jak uznasz za słuszne, nigdy nie przeprowadzałem jakichś niesamowitych testów wydajnościowych na moich skryptach ale wszystko działa wyśmienicie, klienci są zadowoleni, dlaczego to zmieniać

Drugie pytanie to co da ci ładowanie modułów w zalezności od uprawnień, masz zamiar wczytywać przy każdym requeście wszystkie moduły administracyjne gdy uzytkownik ma zapisane w sesji iż posiada uprawnienia administratora ? Chyba raczej nie. Osobiście nie uważam że autoładowarka nie jest fajnym wymysłem (sam oczywiście korzystam z jej dobrodziejstw) ale nie dajmy się zwariować, włos nam z głowy nie spadnie jeżeli w kilku miejscach w kodzie sami wczytamy potrzebne nam klasy, mimo wszystko nawet wtedy używam przygotowanego kodu który po wczytaniu klasy przerzuca mi uchwyt do jej nowej instancji do odpowiednich miejsc i ustawia całą reszte parametrów.

Co do samego systemu uprawnień to ja mam go zazwyczaj rozpisanego w pliku z mapą routingu dla wszystkich akcji, mam tam mapowanie aliasów akcji do faktycznych metod klas, jest to podyktowane pewnymi preferencjami które są dla mnie dosyc istotne, no i dokładnie w tamtym pliku trzymam także zapis wymaganego poziomu uprawnień do obsłużenia danej akcji, dla zbyt niskiego poziomu uprawnień router zwraca po prostu w wyniku akcje błędu uprawnień

No w sumie racja 2 linijki w te czy w tamte co za różnica. To jak byś proponował zrobić sprawdzanie czy user ma uprawnienia do danej opcji. Przy logowaniu pobrać tablice i trzymać ja w sesji i tam sprawdzać czy ma dostęp czy nie, żeby za każdym razem nie pchać się do bazy?

Wg mnie, taki złożony system jechać tylko na Frameworku, bo w przyszłości (nie mówię, że na pewno) mogą się pojawić pewne problemy, a jeśli będziesz to w jakiejkolwiek formie odsprzedawał, to wine ponosisz w 100%, gdybyś pracował na FW to tylko częściowo, zawsze możesz zgonić na dany FW z którego skorzystałeś. Poza tym, to bez różnicy jak duże będziesz miał klasy - czy to będą klasy z dwoma metodami, czy 43, ważne by jedna klasa była odpowiednikiem jednego, konkretnego obiektu i robiła tylko operację dla tego obiektu.

Co do nazewnictwa - poczytaj troszkę sobie, np klasy się piszę wszystko wielką literą (przynajmniej powinno - taka umowna zasada): NazwaMojejKlasy a metod od małej: mojaPierwszaMetoda().

I na prawdę rozważ użycie jakiegoś FW. Jeśli masz wystarczająco dużo czasu i chęci, to nawet zalecam - przyda sie na pewno na przyszłość, a nauka FW, jeśli Ci dobrze wchodzi nauka do głowy to mniej niż miesiąc i będziesz znał troszkę więcej niż podstawy - aczkolwiek zależy to od złożoności FW bo nie warto porównywać szybkości nauki CodeIgnitera do Symfony2.

No tak tylko ja nie potrzebuje aż tak dokładnych uprawnień wystarczy czy ma dostęp do danej kategorii i podkategorii

Chęci są żeby zagłębić się w jakiegoś FW kiedyś liznołem troche Zenda. teraz niestety nie mam czasu na nauke nowego bo mam 4 miechy na postawienei strony i cms :/ dlatego nie chce eksperymentować z czymś czego prawie nie znam.

A powiedzcie mi jeszcze co sądzicie na temat przekazywania parametrów do klas dokładnie $_POST i $_GET? bo gdzieś czytałem że lepiej przekazać do klasy i w niej trzymać pod inna nazwą ale nie jestem do końca przekonany na ten temat, przecież zmienne te to zmienne globalne zawsze jest do nich dostęp

Ja naprawdę przepraszam za offtopic ale:

Może jeszcze musi pisać dokładnie na 2 spację wcięcią i nazywać foldery w projekcie wg. ściścle określonych zasad. Ludzie nie dajmy sie zwariować. To tak samo jak z frameworkiem MVC/H. To jest tylko szablon który określa jakąś idee tworzenia kodu której możesz (nie musisz) się trzymać. Mój własny FW nie trzyma się standardu MVC w wielu miejscach. I co z tego ? Ano nic, jeżeli miałem implementowac coś co tylko zagmatwało by kod w imie idei utrzymania zasady MVC to nie miało to sensu, strzał w stope dla wydajności i czytelności kodu w imie czego ? Szablonu ?
A wracając do tematu (poniosło mnie troszkę), co za różnica czy napiszę:
OtoMojaKlasa
_OtoMojaKlasa
Oto_Moja_Klasa
oto_moja_klasa
OTO_MOJA_KLASA
etc. etc.
Więcej wariantów nie chce mi się wymyślać.

EDIT:
Co do przekazywania parametrów do kontrolerów, ludzie często tworzą struktury typu $_REQUEST_PARAMETERS i tam je trzymają, przyjmuje się także że raczej nie operuje sie w kontrolerze na $_GET i $_POST. Choć to bez różnicy tak po prawdzie. To tak samo jak z opisywaniem absolutnie każdej klasy w settery i 'get'y, otrzymujemy odrobine przyjaźniejsza składnie kodu w zamian za kolejne spadki wydajności (nikłe ale zawsze) już o redudancji kodu nie wspomne, bo przecież w czym lepsze jest:

[PHP] pobierz, plaintext 
$class->set("name","adam");
[PHP] pobierz, plaintext 

od

[PHP] pobierz, plaintext 
$class->name = "adam";
[PHP] pobierz, plaintext 

NO tak.
Ja teraz robiłem tak , że nie do konstruktora nie dawałem $_POST ani $_GET tylko w funkcji w której dane były mi potrzebne robiłem

[PHP] pobierz, plaintext 
$post = (object)$_POST
[PHP] pobierz, plaintext 

nie wiem czy takie rozwiązanie jest słuszne ale na pewno ułatwia pisanie i jest czytelniejsze (przynajmniej dla mnie)

Jeżeli odpalisz powiedzmy rekurencyjnie 10k razy te funkcję (załóżmy że była by taka potrzeba) to stworzysz 10k razy zmienną $post z całą zawartościa talbicy $_POST. Niestety, trzeba zawsze przewidywac najgorsze ewentualności. Czmu nie możesz trzymać tego $post jako atrybutu głównego kontrolera, przeciez i tak pewnie przekazujesz tam jego instancję lub też uruchamiasz metode z jego wnętrza.