Właśnie zaimplementowałem proste sprawdzanie typów w PHP5. Oczywiście, nie jest to C++, gdzie kontrola ta jest bardziej ścisła, ale myślę że w wielu wypadkach starczy. Jest to o tyle wygodne, że łatwiej nieco będzie wykrywać nieścisłości (zresztą, po to jest sprawdzanie typów).

Przykład kodu:

class Test
{
  protected $properties = array(
    'var1' => array('tralala', 'string'),
    'var2' => array(3, 'integer'),
    'var3' => array(array('tralala', 'bulcykcyk), 'array')
  );
  public function __set($key, $value)
  {
    if (!array_key_exists($key, $this->properties)) {
      throw new Exception(sprintf('"%s" property doesn\'t exists.', $key));
    }
    if (gettype($value) != $this->properties[$key][1]) {
      throw new Exception(sprintf('"%s" property must be an "%s" type, is "%s".',
          $key,
          $this->properties[$key][1],
          gettype($value)
      ));
    }
    $this->properties[$key][0] = $value;
  }
}

Najtrudniejszym elementem jest tutaj każdorazowe ustawianie właściwej konstrukcji zmiennej $properties, ponieważ ta tablica ma konkretny format:

$properties = array(
  'nazwa_zmiennej' => array('wartość', 'typ')
)

Jako ‘wartość‘ wstawiamy tam wartość właściwości (obojętnie, czy obiekt, int, string, tablicę czy coś innego), a jako ‘typ‘ - wartość zwracana przez funkcję getttype() wywołaną na przechowywanym obiekcie. Dla napisów będzie to wartość ‘string‘, dla liczb całkowitych: ‘integer‘, a dla obiektów: ‘object‘.

Ta kontrola typów jest o tyle uproszczona, że nie sprawdza, czy przechowywany obiekt jest instancją danej klasy (tej która ma być przechowywana), oraz czy tablica przechowuje żądany typ obiektów. O ile pierwsze czasem warto, i łatwo zrobić za pomocą is_a() czy też get_class(), o tyle drugie może być trudniejsze i wymagać funkcji dodatkowych (jeśli sprawdzanie ma być niezależne od ilości zagłębień tablicy).

Przykład użycia:

$a = new Test;
try {
  $a->var1 = 'asd';               //ok
  $a->var2 = 1;                   //ok
  $a->var3 = array(1, 2, 3);  //ok

  //$a->var1 = 1;              //exception!
  //$a->var2 = 'a';             //exception!
  //$a->var3 = 1;              //exception!
} catch (Exception $e) {
  echo $e->getMessage();
}

W moim wypadku najlepszym rozwiązaniem było utworzenie klasy ‘Test‘ jako abstrakcyjnej (’abstract‘) i tworzenie kolejnych klas jako dziedziczących z niej. Każde z dzieci musi oczywiście mieć swoją wersję tablicy ‘$properties‘.


Całkiem niezła biblioteka, podoba mi się jak na razie bardzo. Oczywiście, nie jest bezbłędna, ale takie rzeczy nie istnieją. Zgłosiłem bugreporta, zobaczymy czy i jak szybko zarezgują ;)

Generalnie wrażenia jak najbardziej pozytywne. Używa się całkiem przyjemnie, trochę ułatwiają pracę w stosunku do FT (heh, całkiem dużo…). Jeszcze nie mam biegłości w posługiwaniu się OPT-ami, ale dokumentacja jest pięknie opisana, zarówno po polsku jak i po angielsku, co całkiem dobrze mówi o twórcach :)

Wspomniany wcześniej błąd dotyczy instrukcji {foreach}, a konkretnie części {foreachelse}, która powinna wykonywać się gdy tablica przekazywana jako parametr jest pusta. Aplikacja po prostu się wysypuje, gdy dyrektywa {foreachelse} występuje w kodzie szablonu… No nic, bywa.

A teraz czas spać…

AKTUALIZACJA
Nie jest źle. Wczoraj bugreport, w tej chwili sprawdziłem FlySpraya, poprawka tymczasowa podana na tacy, i obietnica naprawy w najnowszym RC ;)


Prace nad Core osiągnęły pewien punkt zwrotny (w żadnym wypadku nie zostały przerwane, choć może cisza w repozytorium mogłaby to sugerować). Stwierdziliśmy z larkiem że trzeba przeorganizować i przepisać całe Core, aby móc je efektywnie rozwijać. Co też zaczeliśmy czynić. Przepisywanie zaczeliśmy od tego, od czego powinniśmy: od gadania :)

Postawiliśmy sobie prywatne wiki, gdzie spisujemy koncepcje i pomysły na to jak ma to działać i wyglądać. Zmieni się dosłownie wszystko - poza założeniami: ma być lekkie i szybkie. Będzie oczywiście miało dotychczasową funkcjonalność, będzie miało też obiecywaną dla wersji 0.5.0 funkcjonalność (galerie etc).

Zmieni się system szablonów (największe szanse w tej chwili ma system Open Power Template, w skrócie OPT). W tej kwestii jedno jest pewne: na pewno nie będzie to smarty, ponieważ obydwaj z larkiem posiadamy na smartowstręt :)

Zmienią się też wymagania systemowe (jak zresztą niketóre osoby, sprawdzające OPTy, mogły zauważyć) dla Core. Podstawą będzie: PHP 5.0 + PECLowe PDO lub też wersja PHP 5.1.x, gdzie PDO jest wbudowane.

Innym wymaganiem będzie wersja MySQL - od teraz wymagać będziemy wersji >= 4.1. Choć mam chrapkę na 5.0 ;) Widoki i triggery etc.. mniam… Niestety, o ile PHP 5.0.x jest coraz popularniejsze na komercyjnych serwerach, o tyle MySQL w tejże wersji niestety jest zbyt daleko w tyle. Szkoda.

Nie wiem na ile się uda, ale chciałbym móc puścić nowe Core na UTF-8 (to, jak dla mnie, jedna z ważniejszych przyczyn przejścia na MySQL 4.1.x, które intensywniej wspiera to kodowanie).

No i oczywiście korzystanie z PHP 5.x nie jest podyktowane tylko modą i PDO - które przecież też można mieć do wersji 4.x. Większym problemem jest tutaj duuuuża różnica w “obiektówce” tychże wersji PHP. W PHP 5.x model obiektowy został przepisany od nowa, zaimplementowany w zupełnie inny sposób, i chcielibyśmy skorzystać z jego dobrodziejstw. Co też zaczęliśmy już robić… :)

Jeszcze jednym powodem do przepisania całości jest to, że stara wersja, wraz ze starym systemem szablonów, kiepsko się nadaje do dodania obsługi pluginów do systemu. A w nowej będziemy starali sie to robić tak, żeby tą obsługę mozna było jak najszybciej dodać - umożliwi to niec łatwiejszy rozwój całości systemu.


Wczoraj, w ramach nauki phpdoc udokumentowałem, najlepiej jak potrafiłem, str_nl2br(). Poprawiłem i zmieniłem kilka rzeczy (changelog pod powyższym adresem), i udostępniam światu :)

Dokumentacja nie jest jeszcze najświeższa, bo nie mogę uruchomić chwilowo phpdoca pod linuksem (w sensie: zainstalować) ale to się nadrobi.

Przy okazji zmienił się adres. Obecny: http://urzenia.net/proj/misc/nl2br/. Zapraszam :)

UPDATE:

str_nl2br() przekształcił się w klasę mParser dostępną w moim repo.


W ramach walki z więzieniem, zrobiłem sobie funkcję do php. W sumie klasę, ale korzystać z niej inaczej jak w stylu funkcji chyba nie ma sensu :) Chyba że ktoś chce dziedziczyć z niej… :)

Funkcja jest idealnym (jak dla mnie) zamiennikiem dla wbudowanego nl2br(). Oryginał wstawia przed każdy znak nowej linii znak <br />, co dla mnie jest mało wygodne. bo jeśli puści się jej kod:

<ul>
  <li>cos</li>
  <li>cos
innego</li>
</ul>

to zrobi z niego:

<ul><br />
  <li>cos</li><br />
  <li>cos<br />
innego</li><br />
</ul>

a ja chciałbym:

<ul>
  <li>cos</li>
  <li>cos<br />
innego</li>
</ul>

W sumie działa nawet nieźle, ale jest jeden problem: wsadzany do mojej funkcji materiał musi być walidującym się XML-em. Prawdopodobnie później dorobię wsadzanie całego tekstu w jakiś znacznik, wymyślony, bo moim zamierzeniem jest używanie tejże funkcji tylko do HTML.

Gdyby ktoś chciał się zaznajomić: str_nl2br() nowy adres: str_nl2br().

Warto zwróciś uwagę na właściwości $safe, $safe_tree i $closed. Pierwsza zawiera tablicę znaczników, wewnątrz których (ale nie dotyczy to dzieci tych znaczników) tekst nie jest parsowany (nie są zamieniane znaki nowej linii na <br />). Druga jest również tablicą, ale zawiera znaczniki, których cała zawartość nie ma być parsowana, włącznie z “dziećmi”. Trzecia z tablic zawiera znaczniki, które nie mają w XHTML znacznika zamykającego. Chyba włożyłem tam wszystkie znaczniki które takowego zamknięcia nie mają ?


Jako, że zachciałem sobie dodać pixelarta z PageRank-iem, to moj RandomPixelart musiał zyskać zdolność rozpoznawania zdalnych adresow w bazie. No i zyskał ;)

Przeróbka dotyczy linii 87, gdzie zamiast:

$pixelart_home,

pojawił się posty regex, sprawdzający czy czasem URL obrazka nie zaczyna się od ‘http | https | ftp’:

preg_match(’#^(https?|ftp)://#i’, $pixelart_position[0]) ? ” : $pixelart_home,

dzięki czemu do adresów tych nie jest dodawany URL samego WP.

UWAGA: w regexpie powyżej WP automatycznie zamienił znaki ftp na pisane wielką literą - w źródłach samego pluginu te trzy znaczki są wpisane małymi literami (choć, uwzględniając fakt literki i w regexpie, nie ma to większego znaczenia…).


Jednak mi się dziś chciało. Zrobiłem skrypta do konwersji całości Wordpressa z ISO-8859-2 na UTF-8. Oczywiście może też posłużyc do konwersji całkiem innych kodowań, wystarczy zmienić argumenty w wywołaniu funkcji iconv(). Skrypt znajduje się pod adresem: urzenia.net/wp-content/iso2utf/. Można go dowolnie zmieniać i wykorzystywać do własnych potrzeb, zgodnie z zasadami GPLv2.

Skrypt zmienia tylko zawartość bazy, te tabele i pola które uznałem że trzeba zmienić, reszta (przynajmniej w wersji WP 1.5.1.2 nie musi być konwertowana.

Skrypt nie zmienia za to collation w wersjach MySQL wyższych niż 4.0, więc do tego potrzeba ręcznie pogrzebać w bazie danych. Mi zajęło to jakieś 30 minut, ale nie chciałem tego robić automatem. Poza tym wszystko działa :)

Po zakończeniu działania skryptu, w katalogu w którym on się znajduje będzie utworzony plik converted.sql, który trzeba ręcznie wrzucić do bazy - również tego nie chciałem żeby robić automatem - nigdy nie miałem do nich zaufania ;)

Oczywiście nie biorę odpowiedzialności za złe działanie skryptu (za dobre zresztą też nie), etc etc. Używasz go na własną odpowiedzialność :)

Jeśli gdzieś ktoś dojrzy na diary jakieś problemy z pl-znaczkami, to proszę o info.


Tak, właśnie takie coś sobie wymyśliłem jak siedziałem wczoraj w sądzie więzieniu. Do dyspozycji miałem:

  • tradycyjny interfejs proceduralny mysql_*
  • nowy w php5 interfejs mysqli_ (proceduralny)
  • j.w. mysqli, ale obiektowo (OOP)
  • uniwersalny interfejs (w wersjach PHP < 5.1.0 dostępny poprzez PECL) PDO

Niestety, o ile w wersji Windows-owej w pracy miałem wersję PHP 5.1.0beta3 (z wbudowanym PDO), o tyle w domu i na serwerze na którym stoi urzenia jest starsze, stabilne PHP 5.0.5, na którym wersja PECL-owa PDO nie chce mi działać. Ale też jakoś specjalnie nie walczyłem, żeby zadziałało. Nie chce mi się :)

Wyniki, wraz z testami online, można obejrzeć pod urzenia.net/wp-content/mysql_test/, a żródła plików: urzenia.net/wp-content/mysql_test/sources/.

Dostępne tam są, na dole, 3 linki do wyników jakie uzyskałem na 3 kompach, na których chciało mi się bawić w testy. Najbardziej mnie zszokowało porównanie z P4 2.4 GHZ i AMD64… heheh. Nie ma to jak 64 bity :) Do każdego z linków jest którki opis, na jakim sprzęcie były wykonywane testy, jaki soft etc.

Moje podsumowanie: nie ma znaczenia, którego z interfejsów się użyje. Różnice w wydajności między nimi są tak niewielkie, że imo pomijalne. Dla mnie najwygodniejszy chwilowo się wydaje MySQLi, choć zdecydowanie PDO zasługuje na uwagę. Niestety, na tą chwilę PHP5 (nie mówiąc o wszechdostępności PDO, związanej z nieistnieniem wersji stabilnej/końcowej PHP5.1 i nie działaniem - u mnie - wersji PECL-owej) nie jest jeszcze tak rozpowszechnione jak bym chciał, ze względu na niekompatybilność części softu, dostosowanej do możliwości i błędów ;) starszej wersji, tj. PHP4. Choć w wolnych chwilach prawdopodobnie zacznę przerabiać Core CMS na ‘międzymordzie’ (interfejs) MySQLi… :)

Niedługo też zostaną wznowione prace nad telefonami, które też może doczekają się przejścia na MySQLi, jako że następny hosting będzie u providera, który oferuje PHP5 :) Które to PHP coraz bardziej podbija moje serce (w stosunku do PHP4, nie w ogólności, gdzie python króluje… :) ).

Wszelkie uwagi i ew. zgłoszenia błędów procedury testowej proszę zostawiać w komentarzach - postaram się nimi zająć tak szybko jak się da :)