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.

Wielokrotnie czytając wpisy na rozmaitych blogach, zauważyłem w komentarzach niezrozumienie idei interfejsu. Jest to dość ważny koncept i poniekąd klucz do implementacji większości wzorców projektowych.

Czy to ptak ? Czy samolot ? Nie ! To interfejs !

Interfejs to przede wszystkim dokumentacja. Interfejs opisuje role jaką ma odegrać pewien twór.

Najprościej jest to sobie wyobrazić na prostym przykładzie gniazdka elektrycznego. Specyfikując problem transferu prądu pomiędzy dwoma elementami sieci elektrycznej definiujemy interfejs “podłączalny”. Zawiera on opis żeńskiego gniazdka elektrycznego w rodzaju: “Gniazdko składa się z dwóch otworów oddalonych od siebie o X centymetrów zakończonych metalowymi końcówkami, napięcie wynosi 230V a częstotliwość prądu 50 Hz”.

Dzięki temu, że zdefiniowaliśmy interfejs “podłączalny” i jest on powszechnym standardem w Europie to gdziekolwiek byśmy nie pojechali na wakacje w UE, będziemy mogli korzystać z naszych urządzeń elektrycznych. Co więcej, dzięki temu, że mamy jasno określony interfejs, to w przypadku, gdy np posiadamy urządzenie, które nie spełnia tego interfejsu, a chcemy je podpiąć do prądu, możemy zbudować adapter, który umożliwi dostosowanie się obu interfejsów ( urządzenia i gniazdka ) do siebie.

Wspomniałem wcześniej, że interfejs definiuje role obiektów, przyjrzyjmy się temu bliżej. Załóżmy, że konstruujemy telewizor. Jako producentowi telewizora, zależy nam na tym, żeby można było go podłączyć do prądu oraz obsługiwać z pilota.

Nasz telewizor będzie implementował więc dwa interfejsy “podłączalny” i “pilotowalny”, dzięki którym będzie spełniał oczekiwania nasze i klientów .

Z powyższego opisu widać, że generalnie interfejs określa protokół komunikacyjny między dwoma obiektami. Tak też należy go stosować. Dzięki interfejsom, nie musimy martwić się o implementacje. W końcu co to byłby za świat, gdyby tylko jedna firma produkowała gniazdka elektryczne.

Mam nadzieje, że powyższy artykuł w sposób przystępny przybliżył zagadnienie interfejsów. Jeżeli mielibyście jakieś pytania zapraszam do wpisywania ich w komentarzach