- \n
- zautoryzowa\u0107 u\u017cytkownika (to nie *share, \u017ce wszyscy maj\u0105 mie\u0107 dost\u0119p)<\/li>\n
- u\u0142atwi\u0107 wyb\u00f3r i upload<\/li>\n
- przyj\u0105\u0107 pliki na serwerze i da\u0107 zna\u0107, komu trzeba<\/li>\n<\/ul>\n
Co\u015b podobnego ju\u017c dzia\u0142a, jednak to wybitna prowizorka – najprostszy formularz i jedno pole. Ot, filozofia. Ale potrzebne jest co\u015b, co dzia\u0142a troch\u0119 lepiej i nie zra\u017ca interfejsem.
![\";)\"](\"https:\/\/eriz.pcinside.pl\/weblog\/wp-includes\/images\/smilies\/e_wink.png\")
<\/p>\nTeoria fajna?<\/p>\n
<\/p>\n
nieco wi\u0119cej za\u0142o\u017ce\u0144<\/h3>\n
Wszystko fajnie, drugie podej\u015bcie, bo kiedy\u015b nie by\u0142o to a\u017c tak potrzebne, wi\u0119c sobie le\u017ca\u0142o gdzie\u015b na poligonie, w oczekiwaniu na lepsze czasy. A\u017c do tego tygodnia, gdy uda\u0142o mi si\u0119 w ci\u0105gu 5 minut naskroba\u0107 szkic ca\u0142ej logiki (kartka papieru i d\u0142ugopis rz\u0105dz\u0105; trzeba sobie tylko pewne wytyczne stworzy\u0107, \u017ceby by\u0142o \u0142atwo i przyjemnie ;)). Ok, back-end nie jest problemem, schody zacz\u0119\u0142y si\u0119, gdy przysz\u0142o do front-endu.<\/p>\n
Pierwszym b\u0142\u0119dem, kt\u00f3ry zrobi\u0142em po zaprojektowaniu pierwszych prototyp\u00f3w, by\u0142o skupienie na IE. Ech, cz\u0142owiek by\u0142 m\u0142ody i g\u0142upi (teraz tylko g\u0142upi ;)), teraz przysz\u0142a pora na skupienie si\u0119 na w\u0142a\u015bciwej aplikacji.<\/p>\n
Teraz, gdy balast odrzucony, mo\u017cna by\u0142o si\u0119 skupi\u0107 na w\u0142a\u015bciwym problemie i jego rozwi\u0105zaniach:<\/p>\n
- \n
- podstawowy uploader, kt\u00f3ry dzia\u0142a bazuj\u0105c na zwyk\u0142ym formularzu<\/li>\n
- uploader rozszerzony, pozwalaj\u0105cy na wy\u015bwietlenie rozmiaru poszczeg\u00f3lnych plik\u00f3w kolejki i ew. ostrze\u017cenie, gdy delikwent spr\u00f3buje wrzuci\u0107 wi\u0119cej ni\u017c wynosi przydzielony limit<\/li>\n
- uploader „wypasiony” pokazuj\u0105cy post\u0119p uploadu w czasie rzeczywistym<\/li>\n<\/ul>\n
Najwi\u0119kszy problem, to stworzenie ujednoliconego GUI. Ostatnia opcja jednak mog\u0142a wymusi\u0107 na mnie kompromis w postaci dw\u00f3ch osobnych interfejs\u00f3w.<\/p>\n
Pierwsze dwie wersje by\u0142o stosunkowo \u0142atwo zrealizowa\u0107 – zwyk\u0142e elementy formularza, tworzona dynamicznie ukryta ramka (gdy\u017c upload AJAX-owy plik\u00f3w nie istnieje), formularz gdzie\u015b na dnie DOM, z ustawionym celem (target) na t\u0119 ramk\u0119. Najwi\u0119kszy problem stanowi\u0142o tutaj odpowiednie skopiowanie pola z wybranym plikiem, gdy\u017c JS – ze wzgl\u0119d\u00f3w bezpiecze\u0144stwa – nie ma mo\u017cliwo\u015bci manipulacji warto\u015bci\u0105. Ale wystarczy sklonowa\u0107 w\u0119ze\u0142 DOM (cloneNode()<\/em>) do wirtualnego formularza i go pos\u0142a\u0107. Problem z g\u0142owy.<\/p>\n
Wyci\u0105gni\u0119cie rozmiar\u00f3w pliku, b\u0105d\u017a wielu p\u00f3l, r\u00f3wnie\u017c nie jest a\u017c takie problematyczne – przegl\u0105darki dzia\u0142aj\u0105ce na silniku WebKit oraz Gecko, dla ka\u017cdego pola wyboru pliku, ustawiaj\u0105 w\u0142asno\u015b\u0107 file<\/em>, kt\u00f3ra zawiera tablic\u0119 wybranych przez u\u017cytkownika plik\u00f3w, jest tam r\u00f3wnie\u017c podklucz size<\/em>. Nie b\u0119d\u0119 si\u0119 teraz rozwodzi\u0142 nad mo\u017cliwo\u015bci\u0105 wyboru wielu plik\u00f3w naraz, bo nie jest to tematem notki.<\/p>\n
Teraz najtwardszy orzech do zgryzienia, mianiowicie – uploader flashowy.<\/p>\n
Kt\u00f3ry wybra\u0107?<\/h3>\n
W Sieci jest dost\u0119pnych kilka uploader\u00f3w dzia\u0142aj\u0105cych jako animacja flash (statystycznie, najcz\u0119\u015bciej odpalana wtyczka w przegl\u0105darkach; cz\u0119\u015bciej ni\u017c Java, z tego co si\u0119 zorientowa\u0142em). Niestety, PHP bez niestandardowych rozszerze\u0144 nie ma mo\u017cliwo\u015bci raportowania o post\u0119pie uploadu do klienta. Pozostaj\u0105 albo inne j\u0119zyki (widzia\u0142em gdzie\u015b back-end w Perlu do tego celu), albo prosta aplikacja kliencka, kt\u00f3ra b\u0119dzie zawiera\u0142a odpowiednie metody ci\u0105gn\u0105ce za w\u0142a\u015bciwe sznurki w skrypcie.
<\/p>\nZ tej racji, \u017ce uploader jest projektem wewn\u0119trznym, poszukiwa\u0142em jakiego\u015b darmowego narz\u0119dzia z API pozwalaj\u0105cym na zaadaptowanie do w\u0142asnej aplikacji. Poszpera\u0142em na Sieci, w miar\u0119 godne uwagi okaza\u0142y si\u0119 dwa SWFUploader<\/a> i Uploadify<\/a>. Reszta, to by\u0142y<\/p>\n
- \n
- rozwi\u0105zania wyspecjalizowane (np. g\u0142\u00f3wnie upload zdj\u0119\u0107)<\/li>\n
- p\u0142atne<\/li>\n
- pozwalaj\u0105ce na wys\u0142anie pliku wy\u0142\u0105cznie we w\u0142asnym interfejsie<\/li>\n
- nie pozwalaj\u0105ce na jak\u0105kolwiek kontrol\u0119 procesu wysy\u0142ki\/wybierania plik\u00f3w z poziomu skryptu<\/li>\n<\/ul>\n
Chcia\u0142em ujednolici\u0107 GUI ca\u0142ej aplikacji, wi\u0119c potrzebowa\u0142em:<\/p>\n
- \n
- API pozwalaj\u0105cego na pobranie informacji o dodanym pliku<\/li>\n
- Mo\u017cliwo\u015bci utworzenia i zarz\u0105dzania w\u0142asn\u0105 kolejk\u0105<\/li>\n
- Wyzwalacza powiadamiaj\u0105cego m\u00f3j skrypt o post\u0119pie wysy\u0142ki<\/li>\n<\/ul>\n
SWFUpload wzi\u0105\u0142em na tapet\u0119 jako pierwszy, ze wzgl\u0119du na przyzwoit\u0105 dokumentacj\u0119 oraz popularno\u015b\u0107. Niestety, je\u015bli chodzi\u0142o o w\u0142asn\u0105 kolejk\u0119, to pojawi\u0142y si\u0119 problemy (albo po prostu nie znalaz\u0142em odpowiedniego opisu\/metod w API). Za to Uploadify okaza\u0142o si\u0119 pod tym wzgl\u0119dem do\u015b\u0107 sympatyczne. Wystarczy\u0142o – w\u0142a\u015bciwie – uruchomi\u0107 istniej\u0105ce przyk\u0142ady, poprzeci\u0105ga\u0107 troch\u0119 po stronie kursorem, \u017ceby zauwa\u017cy\u0107, \u017ce ca\u0142a kolejka by\u0142a zbudowana z element\u00f3w HTML-owych.<\/p>\n
Zapowiada\u0142o si\u0119 \u0142atwo i przyjemnie. W\u0142a\u015bnie, zapowiada\u0142o<\/em>, bo zgodnie z prawami Murphy’ego: Je\u017celi co\u015b mo\u017ce si\u0119 nie uda\u0107 — nie uda si\u0119 na pewno.<\/em><\/p>\n
Po trzech dniach po\u015bwi\u0119conych na rozwalanie k\u0142\u00f3d pod nogami, siekiera jednak dopi\u0119\u0142a swego.<\/p>\n
Uploadify?<\/h3>\n
Starcie#1 – przyk\u0142ady<\/H4><\/p>\n
Pierwsz\u0105 k\u0142od\u0105 by\u0142y wspomniane przeze mnie przyk\u0142ady. Je\u015bli odpalimy je samodzielnie, wszystko jest fajnie. Naprawd\u0119 fajnie. Dzia\u0142a, buczy, czasem te\u017c i skwierczy.<\/p>\n
Jednak po \u015bci\u0105gni\u0119ciu najnowszej wersji uploadera i podpi\u0119ciu pod demo – co\u015b nie dzia\u0142a. Ooops?<\/em> Ta, okaza\u0142o si\u0119, \u017ce w starszej wersji jest inna konwencja nazewnictwa metod. Ot, po co w dokumentacji to pisa\u0107? No fakt, jest PDF, jest changelog na stronie. Ale tylko w tym ostatnim by\u0142a wzmianka, \u017ce zmieniono nazwy metod API. Tylko w za\u0142\u0105czonym archiwum z przyk\u0142adami ju\u017c nie ma tego napisanego, \u017ce dzia\u0142a to tylko ze starszym. S\u0142odko. Dopiero gdy Firebug wrzeszczy, \u017ce co\u015b jest nie tak, to cz\u0142owiek dochodzi do wniosku, \u017ce nie ma metod w obiekcie. Ok, kr\u00f3tkie poszukiwania i wiadomo, co jest nie tak. Szkoda, \u017ce ni w z\u0105b nie jest o tym wspomniane w paczce. O ile w wi\u0119kszo\u015bci bibliotek jest do\u0142\u0105czony changelog, to w tej nie by\u0142o.<\/p>\n
Mo\u017ce nie jest to a\u017c takie ci\u0119\u017ckie do przetrawienia, ale potrafi niepotrzebnie wprawi\u0107 w zak\u0142opotanie. Ot taka rada dla innych, gdyby kto\u015b zacz\u0105\u0142 przygod\u0119 z Uploadify od tego tekstu.
<\/p>\nStarcie#2 – instalacja<\/H4><\/p>\n
Za to do\u015b\u0107 dziwn\u0105 jest filozofia pod\u0142\u0105czania Uploadify pod nasze skrypty. Mianowicie, wyszukujemy przez standardow\u0105 funkcj\u0119 jQuery element z odpowiednim selektorem, wywo\u0142ujemy na niej metod\u0119 uploadify<\/em> z po\u017c\u0105danymi opcjami. I tu zaczynaj\u0105 si\u0119 schody – element musi <\/strong> posiada\u0107 atrybut ID<\/em>, inaczej b\u0119dzie si\u0119 sypa\u0107. No bez przesady, przecie\u017c da\u0142o si\u0119 to zrealizowa\u0107 w prosty i elegancki spos\u00f3b, jak jest pisana reszta plugin\u00f3w – byleby by\u0142 to obiekt widziany przez metod\u0119 pieni\u0119\u017cn\u0105 ($<\/em> ;)). Fakt, Uploadify musi w jaki\u015b spos\u00f3b si\u0119 odwo\u0142ywa\u0107 do animacji. Ale mo\u017cna by\u0142o to za\u0142atwi\u0107 wewn\u0119trznymi wywo\u0142aniami mi\u0119dzy obiektami, a nie w taki brudny spos\u00f3b…<\/p>\n
Je\u015bli chodzi o podczepianie uploadera jest jeszcze inna dziwna sprawa. Mianowicie, gdy ju\u017c wywo\u0142amy metod\u0119 konstrukcji Uploadify, to:<\/p>\n
- \n
- Obiekt macierzysty, dla kt\u00f3rego zosta\u0142a wywo\u0142ana, jest ukrywany<\/li>\n
- Wstawiana jest animacja poprzez stworzenie OBJECT<\/em>\/EMBED<\/em> o identyfikatorze pierwotnyIDUploader<\/em><\/li>\n
- A w\u0142a\u015bciwe zdarzenia s\u0105 podrzucane do pierwszego, ukrytego obiektu.<\/li>\n<\/ul>\n
Co komu szkodzi\u0142o podmieni\u0107 wybrany obiekt na animacj\u0119 flash b\u0105d\u017a dodane jej jako dziecko w DOM…? A tak, to trzeba kombinowa\u0107 z CSS, pozycjonowaniem ca\u0142o\u015bci, do tego \u015bmietnik w DOM…<\/p>\n
A i jeszcze jedna rzecz – nauczony tym, \u017ce w dokumentacji prawie nic nie ma (opr\u00f3cz opisu opcji konfiguracyjnych), w \u017cyciu nie pomy\u015bla\u0142em o tym, \u017ceby wysy\u0142a\u0107 zdarzenia do obiektu macierzystego, kt\u00f3ry zosta\u0142 ukryty. Wtf…?<\/p>\n
Starcie#3 – spos\u00f3b obs\u0142ugi zdarze\u0144<\/H4><\/p>\n
Ca\u0142e jQuery posiada nie\u017ale zorganizowany system obs\u0142ugi zdarze\u0144 – nie do\u015b\u0107, \u017ce mo\u017cna \u0142atwo i szybko obs\u0142u\u017cy\u0107 standardowe, to dopisanie w\u0142asnych nie jest \u017cadnym problemem. Tak samo z konwencj\u0105 nazewnictwa – wsz\u0119dzie porzucono przedrostki on<\/em> i skupiono si\u0119 na samych zdarzeniach. Za to tw\u00f3rca Uploadify poszed\u0142 troch\u0119 dziwn\u0105 drog\u0105 – zdarzenia wyzwalane przez jQuery przeznaczy\u0142 raczej na cele wewn\u0119trzne biblioteki (bo tak s\u0105 przez animacj\u0119 flash wyzwalane), a u\u017cytkownikowi pozostawi\u0142 metody definiowane przy konstrukcji uploadera, np. onComplete, onProgress<\/em>. Ok, ale wewn\u0105trz przecie\u017c i tak si\u0119 wykonuj\u0105 uploadifyComplete, uploadifyProgress<\/em>.<\/p>\n
I \u017ceby wygodnie z tego korzysta\u0107, nale\u017ca\u0142oby najpierw zdj\u0105\u0107 obs\u0142ug\u0119 wszystkich tych zdarze\u0144 ze standardowej biblioteki API. Na usprawiedliwienie decyzji autor\u00f3w – w Uploadify jest zintegrowana jaka\u015b prowizoryczna kolejka. Fakt, dzia\u0142a, ale – moim zdaniem – programi\u015bci i tak samodzielnie zaimplementuj\u0105 w\u0142asn\u0105, a fakt wrzucenia tego do ca\u0142o\u015bci przez autor\u00f3w do jednego wora tylko niepotrzebnie zwi\u0119kszy\u0142 rozmiar pliku wynikowego. Z drugiej strony, pozwala to na \u0142atwe dorzucenie uploadu przez pocz\u0105tkuj\u0105cych, zapewnienie funkcjonalno\u015bci Out of The Box<\/em>.<\/p>\n
Jednak wcale bym si\u0119 nie obrazi\u0142, gdyby by\u0142o to ujednolicone, i np. w przyk\u0142adach mo\u017cna by by\u0142o eleganck\u0105 kolejk\u0119 zaimplementowa\u0107 jako ustawienia przy konstrukcji. I wtedy nie by\u0142oby nadmiarowego kodu, a ka\u017cdy mia\u0142by skrojone na miar\u0119 – czyste, fajne API.<\/p>\n
Starcie#4 – fochy wtyczki Flash<\/H4><\/p>\n
Przyznam, \u017ce ju\u017c dawno mia\u0142em tak\u0105 chochlicz\u0105 zagadk\u0119, kt\u00f3ra sprawi\u0142a, \u017ce sp\u0119dzi\u0142em mn\u00f3stwo czasu na testowaniu r\u00f3\u017cnych kombinacji uniemo\u017cliwiaj\u0105cych dzia\u0142anie skryptu. Mia\u0142em zagwozdk\u0119, dlaczego przy wybraniu paru plik\u00f3w, Uploadify w og\u00f3le nie wyzwala\u0142o zdarzenia onComplete,<\/em> pomimo \u017ce pierwszy plik by\u0142 wysy\u0142any na serwer. Za to onProgress<\/em> by\u0142o – 100% post\u0119pu w wysy\u0142ce.<\/p>\n
Winowajca…? Nadawanie display: none<\/em> dla warstwy zawieraj\u0105cej uploader. Na forach Uploadify wyczyta\u0142em, \u017ce je\u017celi taka sytuacja ma miejsce, to wtyczka Adobe zamra\u017ca dzia\u0142anie animacji. Zreszt\u0105 – nie wiedzie\u0107 czemu – czasem wynikaj\u0105 dziwne problemy, kt\u00f3re – pomimo ksi\u0105\u017ckowego zapisu kodu – bior\u0105 si\u0119 znik\u0105d. Zatem – na czas uploadu trzeba zadba\u0107, aby w naszym kreatorze obiekt z uploaderem by\u0142 ca\u0142y czas widoczny, dla kodu. Co nie znaczy, \u017ce nie mo\u017cemy go schowa\u0107 ujemnym z-index<\/em>em, czy zerow\u0105 przezroczysto\u015bci\u0105 (gdy zastosujemy tylko to ostatnie, to w Operze tak \u015brednio przechodzi…).<\/p>\n
Starcie#5 – JS + Flash + Firebug = WTF?<\/H4><\/p>\n
Przyznam, \u017ce mnie to troch\u0119 zaskoczy\u0142o – w ka\u017cdym zdarzeniu wyzwalanym przez Uploadify, u\u017cycie funkcji, kt\u00f3re zatrzymuj\u0105 dzia\u0142anie GUI (np. alert()<\/em>), powoduje zamro\u017cenie dzia\u0142ania Firefoksa. Nie wiem, czym jest to spowodowane (gdy\u017c ten sam kod na np. Chromium dzia\u0142a bez problem\u00f3w), ale pomaga stary dobry kod. Zamiast alert:<\/em><\/p>\n
\nsetTimeout(function(){
\n\talert('asd');
\n}, 1);
\n<\/code><\/p>\nJest to jedna z rzeczy, kt\u00f3ra stanowi dla mnie zagadk\u0119. I chyba ni\u0105 pozostanie. Huh…<\/p>\n
Czysty kod<\/h2>\n
Ok, 3 strony A4 rozwa\u017ca\u0144 teoretycznych, teraz przejd\u017amy do implementacji w praktyce. Moim zdaniem, do\u015b\u0107 czytelnej, w kt\u00f3rej panuje porz\u0105dek i \u0142atwo jest to dostosowa\u0107.
![\":)\"](\"https:\/\/eriz.pcinside.pl\/weblog\/wp-includes\/images\/smilies\/e_smile.png\")
<\/p>\nZacznijmy od szkieletu.<\/p>\n
HTML<\/H4><\/p>\n
\n
\n - A w\u0142a\u015bciwe zdarzenia s\u0105 podrzucane do pierwszego, ukrytego obiektu.<\/li>\n<\/ul>\n