//DEVGURU

Nie raz pewnie spotkaliście się z problemem debugowania skryptów PHP wywoływanych przez AJAX. O ile w jednorazowych przypadkach wystarczy FireBug w Firefoxie (linia czasowa sieci w Safari) w połączeniu z dumpem interesujących nas zmiennych, to w przypadku zapytań zwracających kod JSON lub XML pojawia się problem. Gdy dopiszemy coś do zapytania, format zwracanej treści przestanie być już poprawny i nasz skrypt JS może nie zadziałać poprawnie.

Rozwiązaniem tego problemu jest właśnie FirePHP. Jest to z jednej strony dodatek do Firefoxa, który rozszerza funkcjonalność znanego wszystkim FireBuga, a z drugiej strony biblioteka PHP umożliwiająca przesyłanie informacji do konsoli FireBuga. Jak to się dzieje? PHP dodaje nagłówek X-FirePHP-Data w którym znajduje się obiekt JSON z informacjami dla konsoli. Dodatek do przeglądarki informacje te przechwytuje i wyświetla.

Szczegółowe informacje o zastosowaniach FirePHP wraz z przykładami znajdują się na stronie. Warto jednak najpierw zajrzeć na stronę Wiki, ponieważ tam znajdują się informacje o dodatkach implementujących wykorzystanie FirePHP w takich frameworkach jak Zend, CodeIgniter, Kohana czy CakePHP. Niektóre z nich – np. Zend pozwala na przesyłanie profilera bazy danych do FirePHP.

Więcej o zastosowaniu FirePHP można było przeczytać również w listopadowym numerze php|architect.

Zalety korzystania z Hoptoada, jako “narzędzia do obsługi wyjątków w railsowych aplikacjach” wychwalał już na devguru Bartosz. Od niedawna, nie jest on jednak ograniczony do aplikacji Railsowych. Rich Cavanaugh zakodował w PHP obsługę błędów i wyjątków korzystającą z API Hoptoada.

Choć sam autor wspomina, że nie jest to jeszcze wersja finalna, postanowiliśmy skorzystać z niej na Flakerze. Jak na razie, sprawuje się na prawdę dobrze i z czystym sumieniem możemy ją polecić innym programistom PHP.

Jak zintegrować Hoptoada z naszą aplikacją PHP?

1. Wymagania

Do działania potrzebujemy Horde_Yaml i HTTP_Request.

pear channel-discover pear.horde.org
pear install horde/yaml


pear install HTTP_Request

2. Plik Hoptoad.php, który znajdziemy w repozytorium.
Do pliku musimy dodać ładowanie wspomnianych pluginów, czyli np:
require_once "HTTP/Request.php"
require_once "Horde/Yaml.php"

3. Ustawienie klucza API i przypisanie Hoptoada do obsługi błędów i wyjątków. Może to wyglądać na przykład tak:
require_once('Hoptoad.php');
define("HOPTOAD_API_KEY", "YOUR_HOPTOAD_API_KEY");
set_error_handler(array("Hoptoad", "errorHandler"));
set_exception_handler(array("Hoptoad", "exceptionHandler"));
Oczywiście poziom raportowania możemy zmienić dodając drugi parametr do set_error_handler.

Na jakie problemy, możemy napotkać?
Autor wspomina na swojej stronie o możliwych nieścisłościach w wynikach zwracanych przez metodę Hoptoad::tracer() – która generuje informacje o miejscu w którym wystąpił błąd. Na razie jednak wszystkie wyniki, które otrzymałem były precyzyjne, stąd trudno będzie problem ten potwierdzić.

Dodatkowe informacje o licencji i samym pluginie można znaleźć na stronie repozytorium.

Podczas pisania iBlipa natrafiłem na dość ciekawy problem: Gdy chciałem użyć funkcji eval() do parsowania obiektu JSON który otrzymałem z API otrzymywałem Parse Error. Wyjaśnienie tego problemu znalazłem, ale zajęło mi to dość dużo czasu, zatem warto się nim podzielić .

Kolejna prezentacja z cyklu FridayTalks – tym razem na temat uniwersalnego API do tworzenia widgetów od Netvibes.

| View | Upload your own

Jaki wniosek nasuwa się po obejrzeniu prezentacji? Z pewnością entuzjazm jaki towarzyszył ukazaniu się pierwszej wersji API był uzasadniony. Zbudowanie środowiska uniwersalnego, które będzie obsługiwane przez różne urządzenia i platformy jest czymś bardzo cennym. Uwagi można jednak mieć już do samej zasady działania API.

Widgety napisane w Netvibes są zależne od działania serwerów Netvibes. Najpierw serwer parsuje kod i dopasowuje do wybranej platformy, a następnie wszystkie zapytania ajaxowe tworzone zgodnie ze specyfikacją przechodzą za każdym razem przez Netvibes. Wady takie rozwiązania mogą być wielorakie:

- gdy serwer Netvibes pada – co miało miejsce podczas ostatniej migracji na nową wersję – nasz widget też zamiera

- zapytania poprzez Ajax trwają dłużej, gdyż muszą być jeszcze obsłużone przez momentami bardzo obciążony serwer Netvibes

- przeglądarki internetowe blokują często zapytania do serwera Netvibes – gdyż naruszają one zabezpieczenia (odwołując się do domeny innej niż macierzysta)

Odrębne problemy sprawia to, iż API Netvibes ciągle nie zostało jeszcze ukończone. W dokumentacji czytamy o brakach w obsłudze preferencji, itp… Sprawia to problem gdy chcemy stworzyć ciut bardziej skomplikowany widget i musimy rezygnować z pewnych rozwiązań z powodu braków w API.

Kolejny zarzut jaki się pojawia to niedopasowanie widgetów do poszczególnych platform, np. Windows Vista nasz gadżet będzie miał nadal szerokość taką jak inne gadżety w Netvibes i na pasku gadżetów się nie zmieści. Za to w Dashboard w Mac OS X musimy najpierw ściągnąć widget pośredniczący, do którego dopiero wklejamy URL właściwego widgeta…

Najprościej byłoby nie korzystać z API Netvibes i zadowolić się np. Google Gadgets – gdyż jak pokazują statystyki popularnosć Netvibes jest znikoma. Co zrobić jeżeli jednak musimy korzystać z Netvibes?

Rozwiązaniem jest z pewnością zastosowanie <iframe> – możemy stworzyć prostą stronkę, którą będzie parsował serwer Netvibes – a w niej iframe z właściwym widgetem, do którego już Netvibes zaglądać nie będzie (możemy zatem użyć np. jQuery). Takie rozwiązanie pozwala nam też zrezygnować z Netvibesowych zapytań AJAX – możemy zatem stworzyć własny plik proxy w PHP przez którego będą przechodziły wszystkie zapytania. Pozwoli to nam “oszukać” przeglądarkę w kwestii zabezpieczeń XSS i przyspieszyć uzyskiwanie odpowiedzi.