Това е третата публикация, в която разказвам как направих клиент за Foursquare използвайки само уеб технологии. В първите две разказах как работи GeoLocation API в съвременните браузъри и как не се справих в разбирането на oAuth. В тази публикация ще се опитам да ви разкажа как приложих на практика представената от Радослав Станков концепция Event Driven JavaScript Architecture.
На OpenFest 2010 Радо изнесе доста интересна лекция, в която чрез примери показа как вместо да викаме функции, можем да накараме различните части от JavaScript приложението да си говорят чрез различни дефинирани от нас събития. И най-хубавото е, че това става чрез любимата ми библиотека jQuery и HTML5 data атрибути. И така след първия прототип се отдадох на преправяне на приложението. Малко доразвих идеята на Радо, като разделих събитията на групи според естеството им, а за групиране използвах префикс.
Започнах от функциите, които получават данни от 4sq. Щом се получават данни, имената на събитията следва да са data:нещоси. Така имах две събития: data:venues когато получа списъка с близки обекти, и data:user когато извлека данните на текущея потребител. За всяко от тях написах функция, която да показва данните в страницата, манипулирайки DOM. За да укажа какви събития предизвикват контролите (демек разните бутони / линкове), използвах атрибути data-action със стойности action:нещоси според нуждата. Но вместо да прикрепям отделна функция, което да обслужва onclick събитието на всеки бутон, делегирах функция за всички елементи с атрибут data-action чрез подходящ селектор. Допълнителните данни, които са необходими, също поставих в data атрибути. Нещо не се получи да си предам само данните, така че за да не се боря с event обекта, си предадох направо DOM елемента, който генерира събитието. По-натам ще оправим този не толкова сексапилен код. Явно все пак предаването на данните от data- атрибутите се е получило.
В случай, че се случи някаква грешка, възможните събития са error:http и error:other. В първия случай трябва да обслужа специално случая, когато прокси-скрипта върне статус 401 – това значи, че потребителя не се е аутентикирал, и се налага да го пренасоча към 4sq. Във всички останали случаи просто показвам съобщението за грешка.
След като свърших с преправянето, JavaScript кодът имаше две обособени и в голяма степен независими части. Първата е един обект, в който е затворена всичката функционалност, свързана с Foursquare. Другата част остана по-разхвърляна – в нея се извършва манипулирането на DOM и се обработват действията на потребителя. Самия код можете да разгледате тук – това е работещата версия, която търпи промени от време на време. Доволен съм от резултата – мога безпрепятствено да променям всяка от двете части на приложението – мога да реструктурирам обекта, отговарящ за връзката със сървъра, без да пипам частта, отговорна за интерфейса, както мога да променя изцяло интерфейса, без да се налага да правя промени в кода за връзка със сървъра.
Етикети: five corners, javascript
Харесва ми как се получва. Серията става много добра :)
В момента също пробвам да си обособя някаква методология за работа с data-action (https://gist.github.com/1014327 / https://github.com/RStankov/playground/blob/master/js/data_actions/spec/javascripts/data_spec.js ) ще видим до къде ще я докарам.
Особенно ми хареса това че използваш събития error:http и error:other, защото напоследък вървя и аз в подобна посока, що се отнася до ajax response. И гледам придавам повече информация във status-а на request, а не да чета response-а и да се опитвам да отгатвам от него. Даже на скоро пробвах да вкарам във rails-ujs библиотеката едно такова чудо за работа с ajax https://gist.github.com/1016335
Благодаря, благодаря!
Още като те слушах на OpenFest ми хрумна, че освен action:нещо, събитията мога да са и други неща. И те нещата си дойдоха естествено. Покрай разни подобрения в интерфейса, които обмислям, се замислих и за събития message:info, message:warning и такива.
Аз винаги съм смятал, че първо информацията за състоянието трябва да се съдържа в HTTP и след това ако е необходимо, в самото тяло на заявката или отговора. Не че винаги съм го спазвал, де ;-) За това и много харесах презентацията на Ники Бачийски на уебтеха за 5те неща, които всеки уеб девелопер трябва да може.
От презентацията на Ники Бачийски, само 1 нещо бих сменил, вместо да се пише сървър на C, да е поне на Java или даже на Node.js Инче за всичко е прав.
Ами всъщност езика не е толкова важен. C за да е написан от нулата, на Java или Perl с някоя библиотека ще е твърде лесно. :-)
Метод с евенти обвързани с дом-а няма ли да бави при по-големи приложения?
Предполагам, че е възможно да има видим за потребителя ефект, но не мога да го потвърдя с наблюдения. От друга страна дори и да слагаш
onclick="return doSomething();"като атрибут на елементите, пак ползваш събития в DOM. Трябва да се внимава веригата от събития между действието на потребителя и реакцията в интерфейса (било то и показването на анимация „чекай малко“) да не е твърде дълга.