qBlog Quadina w świecie PHP

24gru/090

Podział folderów

Temat szeroki jak rzeka, ale dobry układ folderów  w naszych przyszłych projektach to bardzo ważna rzecz. Nie mówię tutaj oczywiście, że jest to kluczowy element projektu, ale wystarczająco poważny aby poruszyć go w pierwszej kategorii.

Myślimy sobie... ale po co takowy podział? Oczywiście, dla projektów typu "wizytówka" gdzie znajdować się będzie statyczny tekst (ewentualnie mała obsługa bazy danych na plikach) podziału szczególnego mieć nie musi. Jednakże wyjdziemy trochę w przyszłość i pomyślimy jak skonstruować układ folderów tak aby na przyszłość nie musieć się już martwić przebudową.

Co oznacza "układ folderów"? Wiemy, że każda aplikacja dzieli się na różne moduły, każdy moduł na akcje, które korzystają z różnych bibliotek, a te z kolei z jeszcze innych, albo z silnika naszej strony. Każdy z nich musi mieć dostęp do danych konfiguracyjnych domeny, no i powinniśmy oddzielić kod HTML od PHP w jak największym stopniu.

Problemy opisane akapit wyżej sprowadzają nas do przemyślenia gdzie chcemy mieć jakie elementy. Weźmy na początek układ nadużywany przez początkujących programistów:

/web/config
/web/ajax
/web/css
/web/js
/web/lib
/web/images

Podstawową wadą takiego rozwiązania jest możliwość otworzenia praktycznie każdego pliku i próba wykonania na nim jakiejś akcji. O ile nie jest to problemem dla plików typu "index.php", które chcemy aby użytkownik uruchomił, to może się zdarzyć, że pokombinuje odpalić coś w folderze /lib, albo co gorsze w /config. Zagrożony jest oczywiście folder /ajax, gdzie przecież bez problemu można przeprowadzić atak wysyłający dane metodą GET i POST. Kolejną wadą jest konieczność używania oddzielnych plików jako moduły i akcje, co jest nie optymalne z różnych powodów. Przede wszystkim powoduje konieczność używania nie intuicyjnego systemu szablonów i praktycznie wyklucza możliwość skutecznego oddzielania kodu HTML i PHP.

Kolejnym układem plików z jakim się spotkałem jest pomysł już lepszy, ale problematyczny przy rozbudowanym układzie stron. Układ folderów wygląda następująco:

/config
/templates
/lib
/web/images
/web/ajax
/web/css
/web/

Pomysł ten jest o tyle fajny, że oddziela nam bibliotekę od szablonów oraz nie udostępnia folderu konfiguracyjnego na zewnątrz w żaden sposób. Widoczne publicznie są wciąż takie foldery jak /css /images i /ajax co powoduje, że skrypt jest w miarę bezpieczny. Ale co w wypadku, gdy chcemy oddzielić zupełnie HTML od PHP i to w dodatku w taki sposób, aby móc bezpieczne korzystać z ajaxa?

Z pomocą przychodzi pomysł podziału folderów na moduły, później akcje i na końcu szablony. W taki sposób, zawsze będziemy mogli się odwołać nawet do szablonu (czy też partiala) w zupełnie innym module.

Partial - element który zachowuje się jak normalny szablon, przygotowując dane z PHP do wyświetlenia jako HTML. Partiale używane są do wyświetlania powtarzających się elementów bez konieczności kopiowania wciąż tego samego urywka kodu HTML, np. wyświetlenie zdjęcia w galerii (wtedy szablon wykonuje danego partiala tyle razy ile jest zdjęć)

Obecnie utrzymuje się przy dość prostym a skutecznym układzie folderów. Jest on o tyle fajny, że sprawdza się i na minimalnych projektach i na projektach bardzo rozległych. Oto on:

/apps
/apps/%module/%action/templates <- nazwy poprzedzone% są nazwami odpowiednich modułów i akcji
/config
/lib
/lib/model   <- w tym folderze przechowuje pliki z funkcjami i obiektami obslugującymi model bazy danych
/web/css
/web/js
/web/images
/web

Układ ten został zaczerpnięty z frameworka Symphony na którym przez kilka lat pracowałem mieszając go innymi i wydaje mi się obecnie najskuteczniejszy. Przede wszystkim dlatego, że mamy jawny i mocny podział modułów i akcji. Do każdego z nich przyporządkowany konkretny szablom (templates), który umożliwia bardzo skuteczne i wygodne rozdzielenie kodu HTML od PHP. W bibliotece dodatkowo rozdzieliłem pliki biblioteki główne od tych odpowiedzialnych za model danych. Głównie z powodu takiego, że obiekty modułu danych są często powtarzane. W folderze /web umieszczam tylko jeden jedyny plik index.php, który odpowiada za wywołanie odpowiedniej akcji. W ten sposób nie muszę się martwić nawet o dodatkowe elementy związane z zabezpieczeniem AJAXa. Dzieje się tak dlatego, że AJAX i tak wywołuje się przez mój index.php, który dobrze zabezpieczony obsłuży wszystko.

Istnieją również inne podziały proponowane przez zenda, czy nawet google, które są innymi wersjami prezentowanych przeze mnie rozwiązań. W mojej ocenie wyciągnąłem najlepsze rozwiązania z wszystkich znanych mi pomysłów i połączyłem je w jeden. Jeżeli macie jakieś sugestie czy pytania, proszę o komentowanie.

Zakres tematyczny: Programowanie Dodaj komentarz
Komentarze (0) Trackbacks (0)

Brak komentarzy.


Leave a comment

Brak trackbacków.