Oceń wpis  oddane głosy: 58 / 7

Jak zapowiadałem, w końcu nadeszła pora na dalszy ciąg niekończącej się opowieści "dlaczego warto". Tym razem pora na obalenie bardzo niekorzystnego mitu związanego z przyciskiem wstecz przeglądarki...

A JEDNAK...

Flash pomimo wszystko nie obsługuje przycisku Wstecz. Tak, to prawda - przyznaję to bez bicia - ale nie do końca - częściowa.

Już w wersji MX (flash 6) Macromedia uwzględniła tą możliwość, że użytkownik będzie niereformowalny i będzie chciał używać przycisku wstecz w przeglądarce. Nie - nie tak miało zabrzmieć... Już od MX Macromedia zakładała, że aplikacje tak się rozrosną, że będzie trzeba jednak stworzyć obsługę przycisku wstecz.

No i jest! W środowisku edytora pojawiła się opcja, która pozwala zamienić nazwę klatki kluczowej na etykietę - anchor przeglądania. Nie wierzysz ? Sprawdź ten plik: [przeskok_klatek.swf] Dlaczego linkuję bezpośrednio do pliku swf ? A po to, by niedowiarkom pokazać, że sam flash MA jednak opcję "przycisku wstecz"!

Niestety, opcja ta jest dobra w przypadku animacji... co mamy zrobić, by otrzymać ze strony www z dynamicznymi elementami pełnoprawną aplikację flaszową ? Musimy się podeprzeć przez skrypty javascript lub też php.

W przypadku, gdy flash nie jest głównym motorem strony, mamy najczęściej do czynienia ze strukturą opartą o php. Dobry programista php wie, jak posługiwać się zmiennymi sesji, zaliczając w to cookies. A co z flaszem ? Tu musimy uciec się do opcji, które zostały ukryte w pluginie.

ZMIENNE TYPU GET

To pierwszy sposób przekazywania do flasha i z flasha informacji "gdzie jesteśmy". Wywołanie wenątrz flasha komendy _getURL(adres?zmienne)_ spowoduje przeładowanie strony z nowymi danymi. Gdy _zmienne_ wysyłamy do pliku php, jako feedback buduje on postać nowej strony, na podstawie przekazanych mu przez flash parametrów. W pewnym momencie program (doceńmy też pracę programistów php) dochodzi do momentu budowy bloku odpowiedzialnego za wyświetlenie pliku swf - czyli naszego flasha. W tym momencie po stronie php można zrobić to samo, co zrobił flash w komendzie _getURL_ - możemy bez problemu dokleić do adresu pliku swf zmienne, które były przez nasz plik swf wcześniej wysłane na serwer. Jaki efekt ? Flash "budzi się z drzemki", którą było przeładowanie nowej zawartości strony i... czyta ze swojego głównego poziomu _zmienne_ - oświecenie, nieprawdaż ? Dokładnie - momencik i już widzimy to, co ma być wyświetlone odpowiednio dla tych zmiennych.

Jest pewien problem... webmasterzy wiedzą o co chodzi: każde doklejenie danych do adresu pliku spowoduje potraktowanie przez przeglądarkę tego samego pliku jako nowego!!! I nie dziwię się temu - bo przykładowo wywołanie _plik.php?a=a_ może spowodować całkiem inną akcję niż _plik.php?a=_ - a kto nas zapewni o tym, że administrator nie przypisał rozszerzenia *.swf do wykonywania ukrytych plików php lub cgi, które w każdym wywołaniu w zależności od zmiennych mogą pokazać co innego ???

No więc... nasza radosna twórczość flaszowa niech ma 100kB... dwadzieścia razy odświeżaliśmy stronę... dwadzieścia różnych zmiennych... 100kB x 20 == 2000kB, czyli prawie 2MB niepotrzebnie przesyłanych danych! Użytkownicy nas zamordują za to... zwłaszcza wymierająca rasa modemowców będzie się mścić...

ZMIENNE "BEZ OGONA"

Co zostaje, aby zmusić flasha, żeby obudził się wyświetlając odpowiedni dla otrzymanych danych stan, ale zarazem nie przesyłając ich doklejonych do adresu ?

Cookies! krzyknie zaraz webmaster... byłoby fajnie w sumie używać cookies, ale jest to zbyt okrężna droga dla flashdeveloperów... Metoda POST! krzyknie pehapowiec myśląc rozsądnie ("jak nie GETem go, to POSTem"). Także jest taka możliwość - ale czyż nie będzie to użycie armaty na muchy ?

W MX - tej chyba najczęściej wspominanej przeze mnie wersji flasha Macromedia dodała do definicji parametrów obiektu magiczne słówko "FLASHVARS". Możemy odtańczyć taniec zwycięstwa :) FlashVars pomaga przy przesyłaniu danych (nawet do 63kB!!!) bezpośrednio w  kodzie strony. Jest to taki sam parametr jak czytana przez plugin informacja o chowaniu elementów menu spod prawego przycisku myszy (grrr... jak ja nie lubię nadużywania tego!!!). Wpisujemy w odpowiednie miejsce "flashvars", a zaraz obok "w drugie odpowiednie miejsce" nasze _zmienne_ i... hurra! Flash znowu "budzi się z drzemki" czytając ze swojego głównego poziomu _zmienne_ - ekstra!

Teraz tak... optymalizujmy dalej... najczęściej przeglądamy zawartość określonego działu... jedyne co się zmienia to numery stron lub inne parametry - np. informacja o tym, że wyświetlamy produkty 51 do 100... A my za każdym razem przesyłamy 100 informacji tam i z  powrotem... o ile w przypadku wysyłania do serwera będzie to jeszcze w części przypadków uzasadnione, to po co jeszcze raz to samo z powrotem przesyłać do flasha, skoro właśnie od niego rozpoczęło się kliknięcie ?

Ale przecież... właśnie przeładowaliśmy stronę... i nic po stronie użytkownika nie zostało - zauważą spostrzegawczy czytelnicy. Czy aby tak na pewno ? Okazuje się, że jednak nie :)

FLASHOWE COOKIES

Od pamiętnej wersji MX... :D Flash posiada swoje wewnętrzne "cookies" - nie dochodzę, czy był tu jakiś inny powód niż niemożliwość dogadania się z producentami przeglądarek celem obsługi cookies przeglądarki, czy inny - w każdym razie jest coś a'la cookies, co (niestety) jest "cookies", ale tylko dla pluginu... W każdym razie dla naszych potrzeb jest jak znalazł!

Dzięki SharedObjects - bo tak Macromedia nazwała te "cookies" - mamy możliwość zatrzymania częsci danych po stronie użytkownika - a więc, skoro byliśmy w dziale nr. 5, stronie 3, to po przeładowaniu całej strony, te dane będą dalej znane dla pliku swf! Jedyne, co musimy uzupełnić to nowe zmienne, specyficzne tylko dla tych szczególnych cech kliknięcia...

Co pomimo tego, że SO nie jest zgodne z cookies stawia je wyżej od cookies ? Jest to "przeźroczystość" przeglądarek - obojętnie w jakiej przeglądarce nie otworzymy naszej strony, flash będzie mógł powiedzieć "a tutaj to już byłeś" - co w przypadku sklepów internetowych jest wręcz rzeczą idealną - niezależność flasha od przeglądarek internetowych powoduje, że nie musimy pisać trzech wariantów skryptów obsługi - jedna dla tej, druga dla tamtej, a inna dla jeszcze mNiejzNanej przeglądarki...

PRECZ Z PRZEŁADOWYWANIEM!

Przyzwyczailiśmy się do przeładowywania stron - oj, tak - co też przyzwyczaiło nas od oddzielana jednej treści od drugiej, a przy okazji uzależniło od używania przycisku "wstecz". Wydawało by się, że będzie to twierdzą niezdobytą dla flasha - strony flash ze względu na sposób ładowania najczęściej utrzymane są w tendencji "teraz i już!" - wszystko bez przeładowywania głównego dokumentu...

Choć bycie dżentelmenem w świecie webowym wymaga, by jak najczęściej umieszczać na stronie przyciski nawigacyjne typu "powrót do początku", "pokaż spis" itp. dla wielu osób jest to niewystarczające... I nadal chcą, by ten piii... przycisk "wstecz" był obsługiwany... I będzie obsługiwany.

Drogi programisto, jeżeli umiesz korzystać z wyszukiwarki, umiesz też znaleźć sposób na obsługę przycisku "wstecz" - z pomocą javascript. Tak, wiem - są tacy malkontenci, dla których to jest niewystarczające, bo oni domyślnie wyłączają obsługę skryptów javascript na stronie www - ale czy czasem nie lepiej by Wam było, Drodzy Malkontenci, w epoce kamienia łupanego ?

Drodzy użytkownicy, jeżeli Wasi programiści nie pokazali Wam jeszcze, jak działa przycisk "wstecz" sterowany z flash, to polecam do obejrzenia jedną z najstarszych konstrukcji obsługi tego przycisku prezentowaną na stronie www.robertpenner.com - jednego z guru świata flash...

Jeszcze jedno... dla wielu osób podobno ważne jest to, by spojrzeć, pod jaki adres się cofają... no i jak to się ma do tego, że strony coraz częściej są generowane bez udziału człowieka, za pomocą ciągów alfanumerycznych ?? Czy są w stanie po adresie w formie strona.php?346323bjv523vhjv5hcjgw35k2jg3d5i4u5 odczytać do jakiej treści wrócą ?? Do poprzednio oglądanego działu powinna im pozwolić dojść ta sama strona, a do jeszcze wcześniejszych treści... nauczmy użytkownika używać przycisku "mapa strony" i/lub wmontujmy w stronę mini wyszukiwarkę... Nie wspomunając o tym, że logicznie rozwiązane menu powinno być cały czas widoczne na stronie...

Doleję oliwy do ognia... a co jeśli jednak chcemy komuś pokazać linka do jakiejś konkretnej informacji na stronie ? Ostatnio wspomniany/opisywany na flab.pl wortal bankowy: eurobank.pl jest całkowicie we flaszu. I to też już ma :) (nie pierwszy i nie ostatni zapewne)

CZY BASTION PADŁ ?

Bynajmniej. Flash bez htmla i bez javascript nadaje się zapewne tylko do gier ;) - a i do tego, żeby zapisać wynik potrzebuje skryptów serwera - ale czy html/xhtml obszedł by się bez flash'a, javascript, css-a ? Każda technologia, którą będziemy umieli rozsądnie użyć ubogaca nasz strumień wiedzy, a z czasem uczeń przerasta mistrza - choć dalej jeden bez drugiego nie może istnieć. Tak też jest w tym przypadku. Czy flashdeveloperzy mają być źli z tego powodu ?

Dziękuję kolegom po fachu za przypomnienie, że nie pisze się - ani nie wymawia - jak to jest ogólnie przyjęte: "flesz" - lecz:  F L A S Z.

Marcin

//EDIT: bez javascript i html... nadaje się także do tworzenia prezentacji multimedialnych, plajerów, aplikacji na CD-romach... oczywiście nie w formie pluginu przeglądarki, ale jako tzw. StandAlone Player - czyli samodzielny odtwarzacz typu *.exe.