Witaj, Gościu O nas | Kontakt | Mapa
Wortal Forum PHPEdia.pl Planeta Kubek IRC Przetestuj się!

Projektowanie aplikacji w PHP. Część pierwsza.

Struktura katalogów.

Struktura katalogów i nazewnictwo plików to sprawy, o których często się zapomina podczas tworzenia aplikacji. Nierzadko zdarza się, że umieszczamy wszystkie pliki w publicznie dostępnym katalogu, pomimo tego, że wiele z tych plików(jak np. configi) nigdy nie powinny być dostępne z poziomu przeglądarki. Często także można zaobserwować przechowywanie plików o innych typach plików konfiguracyjnych, logów, bibliotek, klas - w jednym głównym katalogu, lub jednym podkatalogu.

Na dodatek, pliki mają tendencję do posiadania całkowicie przypadkowych nazw, które niezupełnie oddają cel ich istnienia pomyślmy, co się stanie jeśli plików tych nie umieścimy w jednym katalogu, którego nazwa opisuje zawartość tych plików? W miarę powiększania się projektu, coś z pozoru nieistotne w tym przypadku struktura katalogu okazać się prawdziwym koszmarem podczas konserwacji.

W tym przykładzie, public_html jest katalogiem dostępnym z przeglądarki, a webapp jest naszym głównym katalogiem aplikacji. Folder public_html (nazwa domyślna dla katalogu sieciowego w systemie Red Hat) będzie zawierał pliki, których użytkownik będzie używał bezpośrednio z przeglądarki WWW, np. index.php. W odpowiednich podkatalogach będziesz przetrzymywał także pliki CSS, JavaScript i obrazki. Muszą one bowiem być dostępne bezpośrednio dla przeglądarki.

Katalog na najwyższym poziomie w tym wypadku webapp, jest miejscem gdzie będą się mieściły wszystkie inne pliki, do których nie jest wymagany bezpośredni dostęp. Katalog classes będzie użyty do przechowywania klas,config będzie zawierał pliki konfiguracyjne, biblioteki, logs; z kolei będzie mieścił logi, a templates będzie miejscem, gdzie będą przetrzymywane szablony HTML dla naszej aplikacji.

Powinno się stosować do kilku prostych aspektów dotyczących bezpieczeństwa podczas planowania struktury katalogów dla Twojej aplikacji po pierwsze(o czym już wspomnieliśmy) trzymanie plików niedostępnych w folderze niedostępnym dla przeglądarki. Inne aspekty obejmują m. in. zapobieganie tworzenia listingów katalogów, foldery dostępne tylko po poprawnym zalogowaniu poprzez plik .htaccess. Uwierzytelnianie przy pomocy plików .htaccess używa standardowe uwierzytelniania HTTP i jest jedyną możliwa metodą na uzyskanie dostępu do katalogu po podaniu hasła.

Informacje na podobny temat:
Wasze opinie
Wszystkie opinie użytkowników: (7)
Pętla
Czwartek 07 Luty 2013 2:13:59 pm - mayu11 <kontakt_at_mariuszolszowski.pl>

Ym.. z tą pętlą to może lepiej:

for( $i = count( $arr ); $i > 0; --$i )
{
foo( $i );
}

Przy nieobowiązkowej dobrej kolejności, chyba jest ok ;) I nie trzeba trzech zmiennych.

Typo
Sobota 11 Grudzień 2010 11:58:48 am - mambax7

Zamiast:

function suqare($number)

powwino byc:

function square($number)

petla for
Środa 23 Styczeń 2008 6:36:47 pm - xiann

Do dobrze, ale dlaczego:
for ($i = 0, $ii = count($myArray); $i < $ii; $i++) {
print $myArray[$i];
}

skoro mamy:

foreach ($myArray as $v) {
print $v;
}

??

Referencje
Sobota 18 Sierpień 2007 5:36:39 pm - kkasprzak

Niestety autor artykułu mija się trochę z rzeczywistością jeśli chodzi o referencje w PHP4. Używanie referencji nie zawsze prowadzi do oszczędności pamięci wręcz w pewnych przypadkach prowadzi do zwiększenia jej zużycia. Referencje jak sugeruje autor nie zostały też stworzone po to aby oszczędzać pamięć ale po to żeby można było operować na oryginalnym obiekcie a nie na jego kopii w metodach klasy czy funkcjach. Samo przekazanie instancji klasy do funkcji nie prowadzi do stworzenia jego kopii jak stwierdza autor - nadal działa mechanizm przekazywania przez wartość. Kopia obiektu jest tworzona w momencie gdy wywołamy jedną z metod klasy lub nadpiszemy wartość któregokolwiek z atrybutów klasy w tej że funkcji/metodzie. Zauważmy jednak że odczyt atrybutów klasy nie wymaga już tworzenia kopii obiektu, dlatego też php4 tego nie robi. Dlatego też możemy bezpiecznie przekazywać obiekty przez wartość dopóki wykorzystujemy obiekt jako obiekt przenoszący dane (DVO) z jednym zastrzeżeniem, że czytamy bezpośrednio z atrybutów klasy a nie poprzez gettery. Każde wywołanie jakiejkolwiek metody na rzez obiektu prowadzi do stworzenia jego kopii!!!

Referencja nie jest żadnym wskaźnikiem do wyimaginowanego miejsca w pamięci, jest to tylko inna nazwa jednego z kontenerów zmiennych. Po prostu w tablicy symboli jedna lub więcej nazw wskazuje na ten sam kontener.

Przeanalizujmy poniższy przykład:

<?php

function suma(&$v) {
return array_sum($v);
}

$a = range(1, 1000000);
$b = $a;

$c = suma($a);

?>

Wierzcie lub nie ale ,,dzięki'' temu, że tablica do funkcji jest przekazywana przez referencję zmusiliśmy php do stworzenia dodatkowej kopii tablicy $a i stało się to dokładnie w momencie wywołania funkcji suma(). Dlaczego....? Dlatego, że php próbuje być sprytne i nie tworzy kopii zmiennej dopóki nie musi. W naszym przypadku gdy przypiszemy $b = $a nie jest tworzona kopia tablicy oba symbole wskazują na ten sam kontener zmiennej. Jednak gdy do gry wchodzi referencja php musi stworzyć dodatkową kopię ponieważ w przypadku gdy dokonalibyśmy modyfikacji zmiennej przekazanej przez referencję zmiany widoczne by były zarówno w zmiennej $a i $b.

Zainteresowanych szczegółami mechanizmu referencji i zmiennych w php4 odsyłam do jednego z numerów phparchitect lub lepiej kodu php.

Pozdrawiam
Karol Kasprzak

Ciekawe informacja z petla for
Niedziela 04 Luty 2007 12:56:04 am - andrews_p <andrews_p_at_o2.pl>

Zaciekawiła mnie informacja na temat pętli for i obliczania długości tablicy w pierwszej części fora.

for(i=0, dlugosc=count(array); i<dlugosc; i++)
{
//kod
}

Ciekawe rozwiązanie co faktycznie zmniejsza ilość obliczeń. Chodź nie istotne przy małym projekcie ale gdy na stronie jest kilkadziesiąt osób może dać duże rezultaty.

Mały błędzik
Piątek 22 Wrzesień 2006 1:54:25 pm - arqon <lilika_at_wp.pl>

W poddziale standarty kodowania , w trzecim listingu powinno być print $myNumberSquared; aby wyświetlał rezultat metody :)
Super artykuł...

Klamry zbyt rozwlekłe
Piątek 14 Kwiecień 2006 4:42:54 pm - akubiczek

Wszystko fajnie, chociaż klamry w osobnych liniach wydają mi się zbyt rozwlekłym rozwiązaniem, już lepiej trzymać się tego co proponuje pear, czyli klamra otwierająca w tej samej lini:

function foo() {
//do some
}

Nie nie traci się na czytelności, a wprost przeciwinie - może być bardziej czytelnie, bo więcej kodu da sie objąć wzrokiem.

Mentax.pl    NQ.pl- serwery z dodatkiem świętego spokoju...   
O nas | Kontakt | Mapa serwisu
Copyright (c) 2003-2017 php.pl    Wszystkie prawa zastrzeżone    Powered by eZ publish Content Management System eZ publish Content Management System