DeBlog

Podejrzewam, że nie wszyscy wiedzą, że Firebug ma małą pomocną funkcjonalność “poboczną”, którą niedawno przypadkiem odkryłem. Jak wiadomo, gdyby nie Firebug to debugowanie zapytań ajaxowych byłoby w ogóle masakrą. Dzięki FB jakoś dajemy radę. Można sobie w funkcji zrobić var_dump’a, albo print_r’a i w konsoli FB wyłuskać wynik. Ale ze względu na wyświetlenie w konsoli html’a jako tekstu, var_dump praktycznie odpadał. Ale jeżeli ktoś czuje się bardziej związany emocjonalnie z var_dump’em ;) to w końcu dochodzimy do tego co znalazłem - jeżeli w odpowiedzi na zapytanie w konsoli FB mamy wysyp kodu html, można na nim kliknąć MMB/wałkiem, a Firefox otworzy nam go w nowej karcie, zinterpretowanego i pokolorowanego :)

That’s all, folks :) Mała rzecz, a cieszy ;)

ps. Tylko że nie zawsze to działa… ;P

Ot ciekawostka, choć przydatna.

Wszyscy wiedzą, że przy ładowaniu arkusza stylów można (a raczej “należy”) podać atrybut media=”all/screen/print/jeszcze_parę_innych”. Pewnie wiele osób, ale może już nie wszyscy, wiedzą że wewnątrz arkusza można też używać deklaracji “@media all/screen/print/itp”. Ciekawostką może być połączenie obu metod - np. mamy arkusz css do wydruków ukrywający nawigację, ale chcemy mieć popup’a z “podglądem” wydruku.

Robimy więc sobie dwa arkusze stylów, jeden standardowy, drugi do wydruku - ukrywający niepotrzebne elementy (nagłówek, nawigację, reklamy itp) lub czyszczący obrazki z tła. Do dokumentu dołączamy oba w sekcji , np:

Teraz bardzo prosto możemy wyświetlić coś, co można traktować jako prosty podgląd wydruku (bez podziału na strony, czy marginesów) - np. dodać do strony link do podglądu kierujący na obecną stronę plus parametr GET’em np ‘?preview=1′. Wystarczy sprawdzać ten parametr przy dodawaniu stylów i kiedy jest on ustawiony zmieniać “media” drugiego arkusza - np. w php:

No dobra, mamy podgląd, to przydałoby się jeszcze móc od razu wydrukować co widzimy. Więc w stronę wrzucamy button “Drukuj” (’onclick=”window.print();return false;”‘) z id=”PrintIt”, standardowo go ukrywamy (w pierwszym arkuszu css #PrintIt{display: none;}), a nasz arkusz css, który miał nam czyścić stronę z tego, co niepotrzebne do wydruku, tym razem powinien nam dodać tego buttona, ale tylko na podglądzie, a nie na samym wydruku. Więc wstukujemy do niego:

No i mamy jedną stronę, podstawowy podgląd wydruku, z dodatkowym buttonem do drukowania widocznym tylko na podglądzie, nie na “standardowej” stronie, czy samym wydruku :)

Do niedawna generowanie wykresów było albo potwornie żmudną robotą, albo dawało bardzo mizerne rezultaty. Ale już nie teraz - Google udostępniło nowe API (
Google Charts) do generowania wykresów różnego rodzaju - liniowych, słupkowych, kołowych, rozproszonych… Dla każdego coś dobrego.

Zasada jest wręcz śmiesznie prosta - wykres wstawiamy do HTMLa od razu jako obrazek, w źródle podając zwyczajnie odpowiedni link do Google Charts, w którym zawarta jest cała konfiguracja wykresu i jego dane. Całe narzędzie jest darmowe, oczywiście z pewnymi ograniczeniami:

• limit 50.000 wygenerowań dziennie/witrynę,
• powierzchnia obrazka 300.000 pikseli i…
• jakieś ograniczenie złożoności wykresu wynikające z maksymalnej dopuszczalnej długości linka, ale to nie ograniczenie twórców, tylko technologii.

Wykresy można sobie oczywiście cache’ować, jeżeli dane nie zmieniają się z każdą odsłoną.

Najtrudniejsze to złożyć odpowiedni adres. 
Tutaj są zebrane biblioteki znacznie ułatwiające sprawę (konfigurują wykres i kodują dane do łańcucha znaków). Więc cała sprawa ogranicza się do kilku kroków - zbieramy jakieś dane do wykresu, tworzymy obiekt definiujący wykres, wrzucamy do niego nasze dane plus trochę konfiguracji, wyciągamy gotowy link i wrzucamy w źródło obrazka. Gotowe.
Do php dobra jest chociażby biblioteka do pobrania z
www.malaiac.com/GphpChart/. Jak na razie większość dostępnych bibliotek nie obsługuje w 100% możliwości API, ani też samo API nie obsługuje wszystkich rodzajów wykresów jakie sobie można wyobrazić. Jednak do standardowych, codziennych zastosowań jest to rewelacyjne narzędzie! Polecam przetestować, zmiana adresu obrazka i śledzenie efektów to całkiem fajna zabawa :)

Ostatnio, nadszedł czas na to by zmierzyć się ze stworzeniem, a raczej pocięciem designu tak aby można go wysłać jako e-mail. Temat wydawałoby się banalny, a jednak po jego zgłębieniu okazało się że to tylko pozory. Początkowo pomyślałem, że najprościej będzie posłużyć się tabelkami, po chwili jednak stwierdziłem, że i tym razem pójdę z duchem czasu i postaram się wykonać całość zgodnie z aktualnymi standardami (o! jakże się myliłem).

Otworzyłem więc najlepiej wyglądający newsletter jaki miałem w swojej skrzynce pocztowej zacząłem analizować źródło. Wynikało z niego że wystarczy całość oprzeć na znacznikach <div> z odpowiednio ustawionym atrybutem style. Po wykonaniu całości przyszła pora na testowanie szablonu pod różnymi klientami pocztowymi, całość prezentowała się mniej więcej tak:

• thunderbird - ok
• gmail (webmail) - ok
• wp (webmail) - brak obrazków, załączane jako grafika
• outlook express - ok
• outlook XP - w miarę ok
• outlook 2007 - całość rozjechana

okazało się że najnowsze dziecko M$ nie do końca radzi sobie z divami (czyżby uwstecznienie?). Po długiej fali krytyki oprogramowania z Redmond, dooshek przekonał mnie że po przepisaniu całości na tabelki zgodność powinna wzrosnąć do zadowalającego poziomu i obsłużyć bądź co bądź popularnego outlooka z pakietu office’a.

Przepisaniem całości zajął się nie kto inny jak sam dooshek, który po wydobyciu z odmętów pamięci sposobu tworzenia designów opartych o zagnieżdżone tabele osiągnął zamierzony efekt. Udało się osiągnąć poprawne wyświetlanie maila pod wszystkimi outlookami, jednocześnie nie tracąc jej w klientach realizujących standardy W3C.

Po brawach i wiwatach, jednogłosnie podjęliśmy decyzję o spisaniu wszystkich zasad jakie poznaliśmy do jednego dokumentu i udostępnieniu dla wszystkich zainteresowanych. Wszak problem ten znany jest niejednemu webdeveloperowi ;)

Spisane uwagi w pliku
Zasady tworzenia szablonów mailowych.