//DEVGURU

Some time ago, when I was young and unexperienced (ok, it was an hour ago…), I’ve found out that my image upload form is not working on IE. No errors, but no image either.

Here is what i came to  after an hour of debug:

the model has following validation rule:

validates_attachment_content_type :content, :content_type => ['image/jpeg', 'image/png', 'image/gif']

but IE sends false image header (god knows why?) so you need to add:

‘image/pjpeg’, ‘image/x-png’

to get it going again.

Works like a charm.

Jakis (dość już długi) czas temu, znajomy pokazał mi rozszerzenie do Firefoxa o nazwie Firebug. Wtedy byłem nim zachwycony i ten zachwyt choć z małymi przerwami nie przestał mnie opuszczać aż do dziś. Ciężko sobie wyobrazić w obecnej chwili webdevelopment bez użycia tego narzędzia, co można zresztą zobaczyć chociażby w poprzednim poście.

I choć jest to niesamowicie przydatne narzędzie ma ono jedną poważną wadę – jak sama nazwa wskazuje będzie działać tylko w Firefoxie.  Część przeglądarek udostępnia nam podobne, mniej lub bardziej przydatne narzędzia (np. Web Inspector w Safari czy Chrome) ale pozostaje jeden duży problem – co z Internet Explorerem 6?

W IE6 oczywiście takie narzędzie przydało by się najbardziej, ze względu na niesamowitą ilość błędów interpretacji CSS’a, czy dość specyficzne (innaczej mówiąc złe) podejście do interpretacji JavaScriptu. Z pomocą może nam przyjść IE Developer Toolbar, jest to jednak narzędzie przygotowane przez sam MS co niech świadczy o jego jakości – co za tym idzie nawet do niego nie zalinkuje.

Dlaczego? Bo z odsieczą przybywa nam DebugBar – i to już jest bardzo poważne narzędzie, którego autorzy większość czasu spędzają prawdopodobnie patrząc na samego Firebuga i myśląc w czym by tu jeszcze go naśladować.

I tak DebugBar udostępnia nam wszystkie najważniejsze funkcjonalności jakie oferuje Firebug, w prawdopodobnie maksymalnej jakości jaką sie da wyciągnąc z IE. Dostajemy dostęp do prawdziwej działającej konsoli JS i prawdzej działającej przeglądarki zasobów http(s) i prawdziwego działającego inspektora elementów strony. Wszystko jest w ogóle prawdziwe i działające, a development w IE6 nagle przestaje być taki straszny.

Ahhh… (westchenie kodera CSS któremu development w IE nagle przestał być taki straszny).

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.

Safari ciągle ma mały udział na rynku przeglądarek (2.7% użytkowników wg w3c na wrzesień 2008), lecz można śmiało powiedzieć, że w przypadku nowoczesnych aplikacji sieciowych ten procent jest większy. Ekipa odpowiedzialna za silnik WebKit ułatwiła nam ostatnio problem zadbania o poprawne wyświetalnie stron dzięki nowej wersji Web Inspectora – który stał się wbudowanym odpowiednikiem Firefoksowego Firebuga.

Dla pełnej listy zmian polecam przeczytać post na blogu WebKit – ja opiszę najważniejsze (z mojego punktu widzenia) ze zmian.

(more…)