Czasami przychodzi ten dzień, że mamy dość naszego poczciwego PHP. Czasami nawet nie mamy go dość ale chcielibyśmy spróbować coś innego, albo po prostu w pracy chcą, żebyśmy coś napisali w jakimś innym języku. W mojej pracy magisterskiej mam między innymi porównać wydajność dwóch języków (vel interpreterów języków) skryptowych – PHP i Pythona w typowych zastosowaniach (pobieranie rekordów z bazy, parsowanie xml etc).

Stanąłem więc przed wyzwaniem nauczenia się Pythona, a co więcej podpięcia go apache-a, aby generował jakieś strony. Artykuł ten będzie krótkim tutorialem, o tym jak skonfigurować Pythona i Apache-a oraz odpalić prostą PHP-like aplikacje. Mam nadzieje również, że ten artykuł przerodzi się w jakąś dłuższą serię o tym jak zrobić to samo w obu językach .

Taka mała uwaga odnośnie tekstu, zakładam, że czytający ten tekst znają podstawy pythona umożliwiające napisanie prostego skryptu “Hello World”, jeżeli nie, to polecam “Zanurkuj w Pythonie” – dobry wstęp/tutorial.

Setup.

Zakładam, że wszyscy mają skonfigurowanego Apache-a w celu tworzenia aplikacji PHP-owych.  Pierwszym krokiem jaki będziemy musieli uczynić to ściągnięcie odpowiedniej paczki instalacyjnej Pythona (najlepiej wersji 2.6).

Jako, że pracuje na Windowsie, ściągałem pierwszą z góry paczkę. Jest to fajny instalator, który po kilku kliknięciach zainstaluje i skonfiguruje nam Pythona, nie ma tu żadnych specyficznych opcji więc nie będę się zagłębiał.

Drugim krokiem będzie ściągnięcie mod_wsgi, jest tam kilka paczek dla Windowsa i Linux-a, specyficznych dla konkretnych wersji interpretera, my ściągamy tą dla wersji 2.6. Ściągnięta paczkę rozpakowujemy i kopiujemy do katalogu rozszerzeń apache-a (katalog_apache/modules).

Następnie otwieramy plik httpd.conf i dodajemy następujące linie.

LoadModule wsgi_module modules/mod_wsgi-win32-ap22py26-3.0.so
<IfModule wsgi_module>
WSGIScriptAlias /py D:/python_test/index.py
</IfModule>

Gdzie oczywiście mod_wsgi-win32… jest nazwą pliku modułu, który skopiowaliśmy. Natomiast dyrektywa WSGIScriptAlias mówi apache-owi, że cały ruch, który przychodzi na adres http://localhost/py ma przekierowywać do skryptu znajdującego się w ścieżce D:/python_test/index.py .

Gdy już powpisywaliśmy wszystko do httpd.conf, zapisujemy plik i restartujemy apache-a. Jeżeli wszystko poszło gładko to nie powinno być żadnych błędów logu błędów apache-a. W razie błędów, polecam Wiki projektu mod_wsgi. Tam znajdziecie odpowiedzi na większość pytań związanych z instalacją.

Nasz pierwszy web-owy skrypt.

Każda aplikacja działająca na mod_wsgi musi stosować się do specyfikacji WSGI (Web Server Gateway Interface), która została opisana w jakimś tam mądrym dokumencie Pythonowym. Jest on długi i nudny więc bez większych ceregieli powiem to co ważne.

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

Zwiń
Czytaj na blogu autora...

Ostatni wpis dotyczył postgresa i zgadnijcie czego będzie dotyczył ten. Otóż dzisiaj chciałbym napisać o instrukcjach warunkowych i pętlach. Sprawa może się wydawać banalne, ale oczywiście nie musi. Dlaczego? Ponieważ instrukcje warunkowe to nic jak najzwyklejsze IF … ELSE IF … ELSE. Oprócz tego postgres udostępnia nam inne opcje warunków które możemy wykorzystać w zapytaniach sql a mowa tutaj o CASE. A teraz dwa słowa o pętlach. Te bynajmniej ni w ząb ni w pietruchę nie są podobne do niczego. Składnia zwykłego LOOP w postgresie to powiedzmy samo LOOP … END LOOP, ha a gdzie warunki co? Otóż do tego zaraz przejdziemy.

Instrukcje warunkowe

Ten dział będzie poświęcony po prostu warunkom. Otóż jak wyżej wspomniałem w postgresie możemy stosować różnego rodzaju warunki, począwszy od IFów poprzez CASE skończywszy na COALESCE lub nie. Popatrzmy na przykład użycia IFa w funkcji:

CREATE..... RETURNS VOID AS $BODY$
  BEGIN
    SELECT
      ....
    FROM
      ...
    WHERE ....;
 
    IF NOT FOUND THEN
      -- coś tu robimy jak nie znaleziono
    ELSE
      -- w innym wypadku co innego lub kończymy RETURNem
    END IF;
  END;
$BODY$ LANGUAGE 'plpgsql';

Jak widać składnia IFa jest trochę podobna do tej której znamy z innych języków z tym że tutaj mamy słowo kluczowe THEN, które nie w każdym języku jest (bodajże w pascalu było ale mi się szukać nie chce). Kończywszy IFa musimy użyć składni END IF; Jak widać nie mamy tutaj żadnych klamer, dlatego ważne jest by stosować wcięcia przy kodowaniu by się samemu nie pogubić w zagłębieniach kodu. Taki kod od razu staje się czytelniejszy.

Jak widać dzięki takim rozwiązaniom ograniczymy się do wywołania tylko jednej funkcji z kodu php, dzięki temu i kod staje się czytelniejszy, w ten sposób można przerzucić pewną cześć logiki aplikacji na bazę danych, co w znacznym stopniu ułatwia pracę (ale i też może utrudnić, o tym później). Nie chce też znowu wałkować manuala, dlatego link do instrukcji warunkowych znajdziecie na dole, ale co jest ważne, konstrukcja musi zwrócić wartość BOOLEAN, ale to jest chyba oczywiste. W postgresie nie mamy znaku porównania tak jak w innych językach, a chodzi mi o podwójny znak równa się ==, tutaj jest tylko pojedynczy znak równa się. No i teraz, kiedy rozróżnić oba te znaki? Otóż bardzo prosto, porównanie jest tylko i wyłącznie w konstrukcjach warunkowych, użycie znaku równa się w postaci:

"_someVar" = "someVar2";

Jest niczym innym jak przypisaniem, i tak samo jak w każdym innym języku programowania jest l-value i r-value, ale o tym już kiedyś wspominałem, także nie będę tego przytaczał ponownie. Jest także inna konstrukcja która pozwoli nam przypisywać wartość zmiennej. Może ktoś z Was kojarzy język “Prolog”? Jak nie to nie ważne, ale w nim jest użyty taki przełącznik warunkowy “:-” a w postgresie mamy “:=” jako alias do “=” z tym że jest to tylko i wyłącznie przypisanie wartości do zmiennej. Także zachęcam Was do używania takiej oto konstrukcji przypisywania:

"_someVar" := "someVar2";

Jest ona czytelna, i oczywista, z niczym innym się kojarzyć nie może jak z przypisaniem.

Wracając do konstrukcji warunkowych to pozostało nam do opisania jeszcze CASE, jest to po prostu cudowna rzecz, coś wspaniałego, gdyż używanie IFów w SELECTcie jest po prostu mało czytelne i niewygodne. Dlatego dostaliśmy CASE, taki postgresowy switch. Do rzeczy, składnia CASE jest dwojaka:

CASE WHEN condition THEN result
     [WHEN ...]
     [ELSE result]
END

albo:

CASE expression
    WHEN value THEN result
    [WHEN ...]
    [ELSE result]
END

W zależności od potrzeb, używamy jednej z nich, ale mała podpowiedź kiedy którą wybrać, otóż gdy mamy warunek na danej kolumnie to lepiej wybrać wariant drugi, podając tą kolumnę jako expression, gdy mamy parę warunków na różnych kolumnach łatwiej jest wtedy operować nimi na pierwszym przykładzie, przykłady w manualau, a ja dwa słowa o wyniku z THEN, otóż podana fraza w THEN zostanie bezwzględnie dorzucona do wyniku zapytania, czyli dzięki temu w THEN możemy podać np nazwę kolumny jaką byśmy chcieli pobrać w zależności o warunku, który zostanie spełniony. nie sprawdzałem ale pewnie też z tego poziomu można by wywołać funkcję. Warto spróbować kiedyś.

To by było tyle na temat CASE i IF, oprócz tego mamy jeszcze takie funkcje jak NULLIF, COALESCE, GREATEST i LEAST. Krótko o tych funkcjach:

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

Zwiń
Czytaj na blogu autora...

Jak pewnie niektórzy zdążyli się dowiedzieć, miałem okazję gościć na konferencji PHPCon 2010. Minął ponad tydzień od zakończenia, pora podzielić się subiektywnymi wrażeniami.

Oficjalną relację opublikuję na łamach Wortalu PHP.pl niebawem, tymczasem zapraszam do lektury notki.

Tekst będzie raczej należał do tych dłuższych, zostałeś ostrzeżony(a).

Spośród wszystkich popełnionych przeze mnie wpisów na temat Zend Framework, kilka w jakiś sposób nawiązywało do ajaxa. Nie opisałem jednak sposobu w jaki ZF pozwala obsługiwać requesty ajaxowe.

AjaxContext podobnie z resztą jak ContextSwitch, który jest jego bardziej ogólną wersją, umożliwia obsłużenie w jednej akcji różnych żądań i w zależności od kontekstu takiego żądania, zwraca dane w odpowiednim formacie. Typ żądania można rozpoznać po wartości zmiennej format, przesłanej w adresie. Zazwyczaj zmienna ta odpowiada typowi danych jaki chcemy zwrócić. Jedną z wielu zalet korzystania z AjaxContext jest to, że w razie wywołania akcji z parametrem format wskazującym na ajaxowy kontekst nie poprzez ajax (np bezpośrednie wpisanie adresu do przeglądarki), wówczas kontekst nie zostanie użyty, a do renderowania widoku użyty zostanie standardowy widok.

Skoro już przy widokach jesteśmy, to należy wiedzieć, że każdy kontekst posiada swój własny plik widoku z odpowiednim prefixem, który dodawany jest przed rozszerzeniem pliku. W przypadku AjaxContext jest to .ajax. Wówczas w katalogu scripts znajdą się dwa pliki widoku, jeden o nazwie np index.phtml i drugi index.ajax.phtml. Funkcjonalność AjaxContext nie jest dostępna od razu dla każdej akcji. Sami musimy wskazać, która akcja z niej korzysta. Najlepiej zrobić to w metodzie init klasy kontrolera.

public function init()
{
	$ajaxContext = $this->_helper->getHelper('AjaxContext');
	$ajaxContext->addActionContext('index', 'html')
				->initContext();
}

Teraz wykonując request ajaxowy, wystarczy, że w adresie podany zostanie parametr format o wartości html. Poniżej kod jQuery

$.ajax({
	url: "/index/index/format/html",
	type: "POST",
	data: "zmienna1=wartosc1&zmienna2=wartosc2",
	success: function(html) {
		$("#ajax-content").append(html);
	}
});

W ten oto prosty sposób można stworzyć dwa różne skrypty widoku dla jednej akcji, wyświetlane w zależności od tego, czy mamy do czynienia z ajaxem, czy nie. Co ciekawe, w przypadku requestu ajaxowego, automatycznie wyłączany jest layout.

To jeszcze nie wszystko. Zmienna przypisana do widoku jest widoczna zarówno w skrypcie “normalnym” jak i ajaxowym. Co więcej, można wykryć, czy mamy do czynienia z ajaxem i zmodyfikować zawartość niektórych zmiennych, dodać nowe lub usunąć już istniejące.

public function indexAction()
{
	$this->view->jakasZmienna = 'zawartosc zmiennej';
	if($this->_request->isXmlHttpRequest()) {
		$this->view->jakasZmienna = 'zawartosc tylko w ajax';
	}
}

Na pewno część z was zastanawia się do czego może się przydać taka funkcjonalność. Najlepszym przykładem będzie paginacja i sortowanie danych w tabeli. Kolumna, po której dane mają być sortowane oraz numer strony do wyświetlenia, przechodzą przez ten sam kod w tej samej akcji, dzięki czemu nie trzeba pisać dwóch identycznych skryptów. Ponadto jeśli okaże się, że z jakiegoś powodu nie działa javascript, strona po prostu się odświeży, poprawne wyświetlając dane.

Więcej informacji na temat AjaxContext możecie znaleźć w manualu. Polecam również zajrzeć do działu poświęconego ContextSwitch.

Przykładową aplikację znajdziecie w repozytorium.

Codeplex wzbogacił się o kolejną ciekawą bibliotekę – Bing Search Library dla języka PHP. Umożliwia ona korzystanie z API wyszukiwarki Bing z poziomu kodu PHP. Biblioteka została wydana na licencji BSD.

W najprostszej postaci kod PHP korzystający z Bing Search Library wygląda następująco:

$o = new MsftBingSearch($myBingAPPID);
$o->setQuery('Microsoft')
  ->setWebCount(10)
  ->setSource('Web');

$raw = $o->search();
$result = json_decode($raw);
foreach($result->SearchResponse->Web->Results as $value) {
	printf('%s', $value->Url, $value->Title);
}

Więcej informacji można znaleźć na stronie projektu.

źródło

Na blogu mozilla labs pojawiła się informacja, że “Wave Sync” opuścił fazę laboratorium i został dodany do roadmap. Ponadto zmianie uległa nazwa tej funkcjonalności i od teraz nazywa się Firefox Sync. W chwili obecnej funkcjonalność ta dostępna jest jedynie jako rozszerzenie do przeglądarki, pojawi się jednak jako element przeglądarki w następnym dużym wydaniu.

Firefox Sync jest funkcjonalnością pozwalającą na synchronizowanie między różnymi komputerami zakładek, historii przeglądania, zapisanych haseł oraz ustawień. Wszystkie dane są zaszyfrowane i przechowywane są na serwerach Mozilli. Dostęp do nich można uzyskać po zalogowaniu się na swoje konto.

Więcej informacji o tej funkcjonalności znajdziecie na oficjalnej witrynie Firefox Sync.