PHP: Kategoria poświęcona w całości technologiom server-side, a w szczególności PHP. Uwaga: starsze wpisy o tej tematyce znaleźć można także w "Programowaniu", ponieważ ta kategoria jest relatywnie nowa.
PHP: Kategoria poświęcona w całości technologiom server-side, a w szczególności PHP. Uwaga: starsze wpisy o tej tematyce znaleźć można także w "Programowaniu", ponieważ ta kategoria jest relatywnie nowa.
Pisanie tekstu w czystym HTML-u jest na dłuższą metę niewygodne, dlatego na stronach internetowych stosowane są najrozmaitsze parsery, które pozwalają tworzyć artykuły i wiadomości w przystępnej formie, a na swoje barki biorą przetworzenie ich na postać czytelną dla przeglądarki. Używałem różnych systemów, począwszy od BBCode, poprzez parsery wiki z Text_Wiki na czele, własne produkcje (Dzienniki zyxowe), jednak z tego wszystkiego ostatnio wybił się Markdown.
Obecnie w PHP dostępne są dwa rodzaje stałych: globalne oraz klasowe. Programiści coraz częściej wybierają te drugie, lecz ja dotąd pozostawałem nieco sceptyczny wobec zapewnień twórców o ich "większej wydajności", zwłaszcza że robione na szybko pomiary wskazywały mi coś zupełnie innego. Postanowiłem dzisiaj definitywnie sprawę rozstrzygnąć.
Rekurencja definiowana jest jako odwoływanie się funkcji lub definicji do samej siebie. Od strony programisty jest bardzo wygodnym narzędziem upraszczającym wiele algorytmów, lecz dla komputera oraz interpreterów stanowi niezły pożeracz zasobów. W tym wpisie pragnę skupić się na języku PHP, gdyż od pewnego czasu "odrekurencyjniam" Open Power Template'a, w związku z czym mam świeży materiał badawczy :).
Przeglądając ostatnio forum php.pl natknąłem się na kolejny już temat, w którym autor miał problemy z układaniem ścieżek dostępu do plików w dość rozbudowanej strukturze katalogowej swego projektu. Sprawa niby wydaje się banalna: ot, wpisać ścieżkę i tyle. Gdy jednak dodamy do tego sprawy związane z rozwijaniem kodu oraz systemu plików (katalogi robocze i te sprawy), okaże się, że bez przemyślanej strategii i jakiegoś zarządcy po prostu zginiemy. Co tu dużo mówić - przyjemny temat na artykuł.
Dzisiaj pragnę przedstawić małą kwestię związaną z hermetyzacją danych w PHP, a konkretniej jawnym dostępem do danych prywatnych jednego obiektu z poziomu innego obiektu. Myślę, że może się to komuś przydać, gdyż dokumentacja wspomina o tym tylko pośrednio (podobnie jak typowa książka o PHP) i czytelnik przy pierwszej lekturze niekoniecznie musi się natychmiast zorientować, co naprawdę oznaczają zawarte tam słowa.
Pod koniec zeszłego roku montowałem sobie silnik w PHP, lecz prace nad nim wstrzymałem z powodu OPT. Postanowiłem go wczoraj uruchomić na nowopostawionym FastCGI ot tak, żeby sprawdzić, jak się trzyma. Okazało się, że kod się niesamowicie sypał. Nie działało wykrywanie środowiska pracy, translacja adresów w routerze oraz kilka innych rzeczy. Szybki rzut oka wystarczył, by zorientować się, że "awaria" dotknęła wszystkich komponentów, które opierały swoje działanie na dostarczonych z serwera danych o żądaniu.
Z powodu porządków na stanowiskach pracy postanowiłem dla próby zainstalować sobie Lighttpd zamiast Apache'a. Z serwerem tym miałem już wcześniej do czynienia podczas stawiania serwera, lecz z powodu braku niektórych możliwości musiałem wtedy z niego zrezygnować. Natomiast na domowy komputer - czemu nie, tym bardziej że pamiętałem łatwość, z jaką uruchamia się na nim FastCGI.
Nie cierpię używać gotowych skryptów innych, niż biblioteki, wszędzie tam, gdzie potrzebuję dwujęzycznej strony WWW. Niemal całe tego typu oprogramowanie jest napisane przez Anglosasów, a oni z racji, że ich język ma dominującą pozycję w Internecie, mają o tym ZEROWE pojęcie. W sumie nie dziwię im się - jak robią jakiś projekt, wystarczy, że zrobią stronę po angielsku i już mają ustrzelony zarówno rynek krajowy, jak i narodowy. A tymczasem co ma w tej sytuacji zrobić Polak?
Opracowanie rozwiązań mających służyć przez długie lata bez konieczności wprowadzania większych zmian lub wywalania dotychczasowych osiągnięć na śmietnik jest czasochłonne. Niezbędna jest umiejętność planowania oraz przewidywania. Obecnie tworzę taki właśnie skrypt, który ma z założenia wytrzymać w użyciu dłużej, niż rok. Nie poprzestaję jedynie na elastycznej strukturze, lecz staram się także wdrożyć rozwiązania przyszłościowe bądź dostępne wyłącznie tzw. "garstce wybrańców". W tym wpisie pragnę omówić kilka z nich.
Domyślne rozwiązania zaimplementowane w systemie szablonów OPT powinny w zupełności wystarczyć większości jego użytkowników. Mogą oni po prostu skopiować kilka plików do swojej struktury katalogowej i zacząć kodować. Są jednak sytuacje, kiedy trzeba pokusić się o lekkie zmodyfikowanie działania OPT tak, aby dostosować je do naszych potrzeb. Niedawno sam znalazłem się w takowej, gdyż zaszła konieczność takiego zmodyfikowania mechanizmu wybierającego szablony, aby przeszukiwał kilka katalogów, a nie jeden zdefiniowany domyślnie w dyrektywie root.
