Na forach dyskusyjnych zadawane jest bardzo wiele pytań dotyczących działania kodu. Często bywa po prostu tak, że „młodzi” koderzy PHP gubią się we własnym kodzie nieumiejętnie posługując się nazewnictwem zmiennych, a co za tym idzie – złe (lub brak) działania skryptu. PHP daje możliwość dowolnego nazewnictwa zmiennych, dlatego postaram się przybliżyć nazewnictwo wiedeńskie.

Jak wiadomo w PHP wyróżniamy kilka typów zmiennych (danych), które mają swoją nazwę. Nazewnictwo wiedeńskie wyjaśnię na przykładzie $sTytul. Zmienna rozpoczyna się małą literą, która przedstawia typ danych w niej zawartej („s” w tym przypadku to string, ciąg znaków). Następnie cała nazwa zmiennej rozpoczyna się wielką literą. Zmienne, które złożone są z wielu wyrazów nazywamy według gustu i wygody, np. $sMojTytulPosta, lub $sMoj_Tytul_Posta. Osobiście preferuję pierwszy sposób, jest najczęściej używany przez programistów, czytelność kody staje się klarowniejsza.

Typy danych i ich prefiksy dla zmiennych (prefix, typ danych, wyjaśnienie, przykład):

• s, string, ciąg znaków, $sZmienna
• i, integer, liczba, $iZmienna
• a, array, tablica, $aZmienna
• b, boolean, wartość logoczna (true/false), $bZmienna
• o, object, obiekt, $oZmienna
• r, resource, identyfikator zasobów, $rZmienna
• m, mixed, nieokreślony typ, $mZmienna (wykorzystywany przy z góry nieokreślonym typie danych, np zmienna może przyjąć wartość logiczną lub tablicę)

Jak wiadomo, typ istnieje również typ NULL, który definiuje zmienną nie nadając jej wartości. Przy definiowaniu zmiennych najlepiej z góry przypisać jej typ, jednak PHP nie wymaga sztywnego przypisu typu wartości zmiennych (całe piękno tego języka). Jeżeli ktoś jest uparty i chce utrzymać typy danych dla każdego należy przypisać odpowiednie sposoby ich deklarowania (typ danych, przykład zadeklarowania):

• string, $sZmienna = ''; lub $sZmienna = "";
• integer, $iZmienna = 0;
• array, $aZmienna = array();
• boolean, $bZmienna = false; lub $bZmienna = true;
• object, $oZmienna = null;
• resource, $rZmienna = null;
• mixed, $mZmienna = null;

Aby sprawdzić typ danej zmiennej, skorzystaj z funkcji var_dump ( mixed expression [, mixed expression [, …]] ).

UWAGA! do sprawdzenia danego typu zmiennej nie należy używać funkcji gettype():

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Dostałem maile i komentarz na blogu odnośnie sprawdzania ciastek usera. Dyskusja wynikła z artykułu „Online counter + cache”, w którym takowe były wykorzystywane. Jeden z internautów zapytał czy jest możliwe sprawdzenie, czy da się sprawdzić, czy użytkownik ma włączoną obsługę ciastek i podjąć jakieś działania. Inny zaś zapytał, czy jest to do wykonania z poziomu JavaScript. Na oba pytania mogę śmiało odpowiedzieć: TAK.

Logika zachowania skryptu w obu przypadkach (PHP i JS) jest taka sama: wysyłamy użytkownikowi ciastko, a następnie sprawdzamy jego wartość. Jeżeli wartość jest błędna, lub nie istnieje, wówczas możemy wyciągnąć śmiały wniosek, iż takowy cookies nie został prawidłowo przesłany – user ma wyłączone cookies, bądź ich wysyłanie jest błędnie interpretowane.

Kod ze strony PHP, który ma wbudowaną funkcję setcookie() i odczyt z poziomu tablicy $_COOKIES (odnoszę do manuala)

PLAIN TEXT

PHP:

1. function CheckUserCookies()
2. {
3. setcookie('testcookie', 'test', (time() + 60));
5. if(isset($_COOKIE['testcookie']))
6. return true;
8. return false;
9. }
11. if(CheckUserCookies())
12. echo 'ok, user ma włączone cookies';
13. else
14. echo 'proszę, włącz swoje cookies!';

JS nie ma wygodnej sytuacji, musi w jakiś sposób utworzyć cookies, zostały stworzone funkcje createCookie() oraz readCookie() (skorzystałem z gotowego rozwiązania). Aby ułatwić pracę, funkcja ustawiająca ciastko otrzymała takie same trzy pierwsze parametry, jak jest w przypadku PHP.

PLAIN TEXT

JavaScript:

1. function CheckUserCookies()
2. {
3. createCookie('testcookie', 'test', 60);
5. if(readCookie('testcookie') == 'test')
6. return true;
8. return false;
9. }
11. function createCookie(name, value, timestamp)
12. {
13. if (timestamp)
14. {
15. var date = new Date();
16. date.setTime(date.getTime()+(timestamp));
17. var expires = "; expires="+date.toGMTString();
18. }
19. else var expires = "";
20. document.cookie = name+"="+value+expires+"; path=/";
21. }
23. function readCookie(name)
24. {
25. var nameEQ = name + "=";
26. var ca = document.cookie.split(';');
27. for(var i=0;i <ca.length;i++)
28. {
29. var c = ca[i];
30. while (c.charAt(0)==' ') c = c.substring(1,c.length);
31. if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
32. }
33. return null;
34. }
36. /**
37. * Usable...
38. */
40. setTimeout("alert(CheckUserCookies())", 100);

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Wielu programistów zastanawiało się nad optymalizacją skryptu, który podlicza ilość gości na stronie i ustawia usera w tabeli online, bowiem należy wykonać aż cztery podstawowe zapytania:

• usunięcie wygaśniętych sesji z bazy danych
• sprawdzenie, czy użytkownik posiada swoją sesję w bazie
• w zależności od pkt 2: ustawić nową sesję, bądź updateować istniejący rekord (nowy czas wygaśnięcia)
• ostateczne podliczenie istniejących rekordów (sesji) w bazie danych = ilość online

4 Zapytania? Plus połączenie do bazy danych? NIE. Można to w prosty sposób zoptymalizować. Przygotowałem mały artykuł dla tych, którzy nie są świadomi, że nawet ilość osób online można zcacheować

Krok 1. Zapis użytkowników online w atrybucie klasy

Po podliczeniu ilości online warto by było zapisać ją do atrybutu klasy (nie trzeba będzie podliczać od nowa ilości osób online przy ponownym wywołaniu metody $oOnline->count() ). To jest pierwszy krok, który należałoby wykonać, nie rozwiązuje on jednak problemu częstego odświeżania strony...

Krok 2. Zapis ilości online w ciastku

Możemy zapisać ilość online userów w ciastku, expire ciastka jest równe expire naszej sesji online. Jeżeli użytkownik posiada ciastko, dane na jego temat nie będą w ogóle analizowane (update). Dopiero po wygaśnięciu ciasteczka user ponownie wyśle żądanie do serwera, iż jest online. Jeżeli ciastko wygaśnie, a on nie będzie poruszał się po stronie, znaczy to że jego sesja online wygasła razem z ciastkiem i nie jest aktywny na stronie.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...

Singleton jest chyba pierwszym z “wzorców projektowych” jaki wszyscy poznaliśmy. Prosty w implementacji, jeszcze łatwiejszy w użyciu, ale pociągający za sobą stos negatywnych konsekwencji.

W poszukiwaniu informacji i zdań o singletonie w polskim internecie trafiłem na Wikipedię, gdzie znalazłem zdanie, które podsumowało to czym jest tenże “wzorzec”:

Singleton jest też uznawany za antywzorzec, gdyż często jest tylko eufemizmem dla zmiennej globalnej.

W książce “Refaktoryzacja do wzorców projektowych” padają kolejne dwa ważne zdania:

Singleton to przede wszystkim wykorzystanie mechanizmów chroniących języka programowania do ochrony tylko jednego aspektu: jednostkowości. Prawdziwym problemem z singletonami polega na tym, że są doskonałą wymówką, aby lekko potraktować kwestię widoczności obiektów.

Główną przesłanką do stosowania singletonu jest to by mieć tylko jedną instancję danej klasy, ale czy nie da się załatwić tego w inny sposób? Oczywiście, że da się. Problemem jest tylko to by poświęcić więcej czasu na projekt, po prostu pomyśleć. W chwili gdy mamy połączenie z bazą danych i tak jest ono tworzona w jakimś miejscu, zwykle jest to jakiś kontroler bądź inny przyczółek w którym koncentruje się “władza”. Jest to miejsce w którym i tak musimy daną instancję skonfigurować. Co to znaczy? Ano to, że cały ten singleton i tak nie jest autonomiczny, ponieważ jest zależny od czynników zewnętrznych. Idąc dalej - czy nie lepiej by było dalej pchnąć stworzony już obiekt dalej? Oczywiście, ktoś powie, że wydłużą się definicje metod i tak dalej. Fakt, to może być problem, ponieważ metody, które przyjmują powyżej 4 argumentów stają się “ciężkie”. Ciężkie również pod względem zapamiętania ich wywoływania. Nie można tu również zapominać o tym, że nie musi być przymusu przekazywania za każdym razem danej instancji. Mamy do dyspozycji konstruktory jak również kompozycję, ogólnie pojętą fazę “konfiguracji”. Zaletą unikania singletonów jest bardzo duży plus - obiekt nie jest widoczny tam gdzie nie powinien. Jest to znacznie lepsze podejście tym bardziej, że globalnie dostępny obiekt lubi kusić, kusić łatwością dostępu. Zawsze gdy myślisz o tym by użyć singletonu myśl o nim jak o zmiennej globalnej, bo tym w gruncie rzeczy się wkrótce stanie, elementem, który będzie powodował, że kod stanie się nieczytelny a kontrola dostępu do instancji wbrew pozorom, zamiast trudniejsza, jeszcze łatwiejsza.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...