Jak już pisałem nieraz, głównym założeniem mojego frameworka był minimalizm. Minimum kodu, minimum plików. W sumie to chyba zdrowy objaw, bo im więcej kody tym więcej możliwości popełnienia błędów i więcej potencjalnych dziur. Poza tym jestem leniwy i nie lubię utrudniać sobie życia :)
Czasami zdarza mi się przeglądać cudzy kod, np. podczas wprowadzania zmian czy poprawek na jakiejś stronie. Spotykam się czasami z czymś takim, że plik zawiera tylko jedno polecenie, mianowicie includowanie innego pliku. Do dziś nie rozgryzłem celu takiego działania. Zakładam, że to może być tymczasowa proteza i kiedyś w tym pliku będzie coś innego. Ale mogę się mylić.
Nie wiem, jak takie wielokrotne includowanie fizycznie realizują serwery, ale z doświadczenia programistycznego wiem, że operacje na plikach należą do jednych z najwolniejszych (dostęp do dysku, odczytanie nazwy pliku, znalezienie pliku, odczytanie go itp.). Być może piszę teraz głupoty, ale wydaje mi się, że jeden większy plik (zawierający nawet funkcje aktualnie nieużywane) zostanie przetworzony szybciej niż kilka małych. Stąd najważniejsze operacje i dane zawarłem w kilku plikach realizujących następujące zadania:
Te kilka plików includowanych jest zawsze w panelu admina i po stronie usera.
Połączyłem też wykonywanie akcji (np. z formularzy) z samymi stronami zawierającymi formularz. Domyślam się, że to się kłóci z większością zasad programowania, ale wkurzało mnie ciągłe przeskakiwanie między plikami. Wolę sobie przewinąć źródło o ekran czy dwa niż skakać między oknami. Kwestia wygody. No i nie mam bałaganu w plikach. Żeby zabezpieczyć stronę przed ponownym wysłaniem formularza (np. po odświeżeniu strony) wprowadziłem dodatkową zmienną z losową wartością, która jest sprawdzana przed akcją związaną z formularzem. Przed przetworzeniem formularza jest ona porównywana z ciastkiem, po wykonaniu zapisywana do ciastka. Istniejące ciastko nie pozwoli na ponowne wykonanie formularza. Oczywiście zamiast ciastka można użyć zmiennej sesyjnej, co kto lubi.
Jak wiadomo najbardziej podatnym miejscem na włamania jest przekazywanie parametrów, zwłaszcza przez GET. Dlatego istotne jest, żeby przekazywać ich jak najmniej i najlepiej, żeby to były liczby. Przy liczbach bowiem najtrudniej przemycić złośliwy kod. Wystarczy zastosować rzutowanie (int)$_GET["zmienna"] i już mamy czystą liczbę. Im więcej dodatkowych parametrów da się odczytać z bazy lub jakoś obliczyć, to należy się tego trzymać. Dlatego w przyjaznych adresach istotna jest liczba, z której system odczytuje odpowiednią podstronę.
To proste. Każdy rekord danych ma swój typ: page, news, galeria, artykuł itp. Jeśli dla danego typu danych istnieje szablon, jest on odczytywany. Jeśli jakiś typ nie ma przypisanego szablonu (np. menu) wczytywana jest strona błędu 404. Można też zastosować kolumnę zawierającą nazwę szablonu.
Przykładowa kolejność odczytywanych plików:
Dzięki temu po utworzeniu wspólnych sekcji serwisu można skoncentrować się już tylko na samych szablonach wyświetlających konkretną treść.
