Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development

Стварыце дыспетчар кантактаў з дапамогай Backbone.js: Частка 5

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Getting to Know Backbone.js.
Build a Contacts Manager Using Backbone.js: Part 4

Belarusian (беларуская мова) translation by Tatsiana Bochkareva (you can also view the original English article)

Сардэчна запрашаем назад у Стварэнне прагляду кантэнту з падтрымкай Backbone. У першых чатырох частках мы разгледзелі амаль усе асноўныя кампаненты, якія пастаўляюцца з апошняй версіяй Магістральная, у тым ліку мадэлі, кантралёры, прадстаўлення і маршрутызатары.

У гэтай частцы падручніка мы збіраемся падлучыць наша дадатак да вэб-серверу, каб мы маглі захоўваць нашы кантакты ў базе дадзеных. Мы не будзем шукаць LocalStorage; гэта папулярны сродак захавання дадзеных, якія выкарыстоўваюць прыкладання Backbone, але факт у тым, што на гэты конт ужо маецца мноства выдатных навучальных дапаможнікаў.


Прыступім да працы

Для гэтай частцы падручніка нам спатрэбіцца вэб-сервер і база дадзеных. Я выкарыстоўваю Microsoft БВ ў якасці рэдактара, які пастаўляецца з убудаваным вэб-серверам і добра працуе з серверам MSSQL, так што гэта тое, што мы будзем выкарыстоўваць. Па праўдзе кажучы, на самай справе не важна, з якога месца вы пачынаеце.

Ўстаноўка і настройка любы з гэтых тэхналогій (БВ і MSSQL-сервер) выходзіць за рамкі дадзенага кіраўніцтва, але гэта адносна прамалінейныя, і ёсць шмат добрыя кіраўніцтва.

Пасля ўстаноўкі вы хочаце наладзіць новую базу дадзеных, якая ўтрымлівае табліцу для захоўвання дадзеных. Стоўбцы табліцы павінны адлюстроўваць розныя ўласцівасці, якія выкарыстоўваюцца нашымі мадэлямі, таму павінен быць слупок імёнаў, слупок адрасоў і т. в. Табліца можа быць запоўненая прыкладамі дадзеных, якія мы выкарыстоўвалі ва ўсёй серыі.

Адзін слупок, які павінен з'явіцца ў нашай новай табліцы, але які мы не выкарыстоўвалі ў нашых лакальных тэставых дадзеных, з'яўляецца ідэнтыфікатар id, які павінен быць унікальным для кожнага радка табліцы. Для выгоды выкарыстання вы, верагодна, захочаце ўсталяваць аўтаматычнае павелічэнне пры даданні дадзеных у табліцы.


Сінхранізацыя з базай Sync

Для сувязі з серверам Backbone дае нам модуль Sync; гэта адзіны асноўны модуль, які мы яшчэ не выкарыстоўвалі, і таму яго разуменне завершыць наша веданне асноў рамак.

Выклік метаду sync() прыводзіць да таго, што запыт паступае на сервер; па змаўчанні мяркуецца, што альбо jQuery, альбо Zepto выкарыстоўваецца і дэлегуе запыт, які з іх прысутнічае для фактычнага выканання. Ён таксама мяркуе, што інтэрфейс RESTful чакае ў фонавым рэжыме, таму па змаўчанні выкарыстоўвае метады POST, PUT, GET, DELETE HTTP. Як мы бачылі, Backbone можа быць наладжаны на вяртанне да старых метадаў GET і POST з дадатковымі загалоўкамі, якія вызначаюць меркаванае дзеянне.

Акрамя магчымасці прамога выкліку sync(), мадэлі і калекцыі таксама маюць метады, якія могуць выкарыстоўвацца для сувязі з серверам; мадэлі маюць метады destroy(),fetch(), parse() і save(), а калекцыі маюць fetch() і parse(). Метады destroy() fetch() і sync() усё адкладаюць да sync() незалежна ад таго, выкарыстоўваюцца ці яны з мадэлямі або калекцыямі. Метад parse(), які аўтаматычна выклікаецца кожны раз, калі дадзеныя вяртаюцца серверам, па змаўчанні з'яўляецца простым no-op, які проста вяртае адказ з сервера, але можа быць перавызначаны, калі мы хочам папярэдне апрацаваць адказ да яго спажывання.


Абмежаванне загрузкі старонкі

Тое, як дадзеныя мадэлі загружаюцца на старонку, будзе залежаць ад выкарыстоўванай сервернай тэхналогіі.

Дакументацыя Backbone для метаду fetch() (калекцыі) паказвае, што гэты метад не павінен выкарыстоўвацца на пачатковай загрузцы старонкі для запыту патрэбных мадэляў з сервера. Далей у раздзеле «Пытанні і адказы» падрабязна апісана, што старонка павінна мець неабходныя модулі, якія ўжо даступныя на старонцы пры загрузцы, каб пазбегнуць першапачатковага запыту AJAX.

Гэта выдатная ідэя, і, хоць мы відавочна не павінны прытрымлівацца рэкамендацый, гэта зробіць наша дадатак трохі больш свежым, і гэта добра.

Тое, як дадзеныя мадэлі загружаюцца на старонку, будзе залежаць ад выкарыстоўванай сервернай тэхналогіі. Мы збіраемся выкарыстоўваць .net ў гэтым прыкладзе, таму адным са спосабаў зрабіць гэта было б дынамічнае стварэнне <script> элемента, які змяшчае патрабаваныя дадзеныя мадэлі, і ўвод яго на старонку. Для гэтага нам трэба пераўтварыць наш index.html файл у index.aspx (нам таксама спатрэбіцца код index.aspx.cs або файл класа). Але гэта стварае новую праблему.


Выкарыстанне мікротрэшчыны Underscore на старонцы ASPX

Мы можам падняць прыклад стылю «Вусы» прама на старонцы дакументацыі Underscore.

Праблема з шаблонамі Underscore заключаецца ў тым, што яны выкарыстоўваюць <%= для ўказанні запаўняльнікаў ў шаблоне, якія замяняюцца фактычнымі дадзенымі пры спажыванні шаблону. Гэта той жа сінтаксіс, што і старонкі ASPX для запуску дынамічнага кода .Net ў тэгах HTML. Шаблоны Underscore, якія мы выкарыстоўвалі ў гэтым прыкладзе, да гэтага часу не дазваляюць правільнай працы ASPX-старонкі, і замест гэтага адлюстроўвае памылку сервера.

На шчасце, існуе некалькі спосабаў вырашэння гэтай праблемы, самым простым спосабам з'яўляецца змяненне сінтаксісу, які выкарыстоўваецца для ўказанні запаўняльнікаў, якія выкарыстоўваюцца ў шаблонах. Underscore прадастаўляе ўласцівасць templateSettings для гэтай самай мэты, дазваляючы нам лёгка пазначыць рэгулярны выраз, якое выкарыстоўваецца для адпаведнасці сымбалям, якія мы хочам выкарыстаць. Мы можам падняць прыклад «Вусы-стыль» прама на старонцы дакументацыі Underscore; на пачатку нашага файла app.js (у самой вонкавай функцыі) мы можам проста дадаць наступны код:

Усё гэта дае новае рэгулярны выраз для метаду interpolate, што дазваляе нам выкарыстоўваць альтэрнатыўны сінтаксіс {{property}} замест <%= property%>. Мы таксама павінны ў гэты момант прайсці праз шаблоны і змяніць усе зыходныя тэгі шаблонаў для выкарыстання новага сінтаксісу.

Хоць гэта не тое, што мы выкарыстоўвалі ў нашых шаблонах да гэтага часу, ёсць таксама дадатковыя сімвалы, якія можа выкарыстаць Underscore. Мы можам ацаніць JavaScript з дапамогай <% і можам пазбегнуць дадзеных, выкарыстоўваючы <%-. Калі мы хочам выкарыстоўваць іх у нашых шаблонах і замянілі interpolate, мы таксама павінны наладзіць ўласцівасці eveluate і escape Underscore.


Загрузка дадзеных мадэлі

Цяпер мы можам падумаць пра дастаўку дадзеных мадэлі, якія захоўваюцца ў базе дадзеных, на нашу старонку, калі старонка першапачаткова адлюстроўваецца. Мы можам лёгка зрабіць гэта, дадаючы просты спосаб да файла класа для нашай старонкі ASPX, якая счытвае запісы з базы дадзеных і стварае спіс аб'ектаў, дзе кожны аб'ект уяўляе сабой адзін кантакт. Затым мы можам сериализовать спіс у масіў JavaScript і ўвесці яго на старонку. Пакуль масіў мае той жа фармат, што і фіктыўны масіў, які мы выкарыстоўвалі ў першых чатырох частках гэтага кіраўніцтва, нам не давядзецца мяняць наш інтэрфейсны код.

У якасці запаўняльніка для масіва мы можам проста дадаць новы <script> у на старонкі непасрэдна перад спасылкай на app.js, якая выклікае метад у кодзе:

Фактычная логіка ў кодзе, якая выконвае Серыялізацыя чытання і запісы базы дадзеных, можа моцна адрознівацца ў залежнасці ад рэалізацыі і некалькі выходзіць за рамкі гэтага кіраўніцтва - нас больш цікавіць атрыманне гэтай пачатковай карыснай нагрузкі на старонцы, чым пра тое, як мы гэта атрымліваем. Не саромейцеся праверыць файл класа ў суправаджальнай загрузцы кода, магчыма, самы хуткі і просты, але далёка не лепшы спосаб зрабіць гэта.

На гэтым этапе мы павінны мець магчымасць выдаліць масіў кантактаў, які утрымліваў нашы фіктыўныя дадзеныя з app.js, запускаць старонку (праз ўбудаваны вэб-сервер WVD або IIS) і бачыць сапраўды такую ​​ж старонку з амаль аднолькавай функцыянальнасцю, як мы бачылі ў канцы часткі 4. Yay!


Сінхранізацыя нашага прыкладання з серверам

У гэтым прыкладзе я выкарыстаў ASMX-файл .net 4.0 для апрацоўкі запытаў ад знешняга інтэрфейсу. Каб фокус мог бачыць адпраўленыя на яго дадзеныя, мы павінны наладзіць ўласцівасці emulateHTTP і emulateJSON Backbone. Дадайце наступныя радкі кода непасрэдна пасля таго, як мы змянілі сінтаксіс шаблону Underscore: Дадайце наступныя радкі кода непасрэдна пасля таго, як мы змянілі сінтаксіс шаблону Underscore:

Ці ці не вам трэба будзе наладзіць гэтыя ўласцівасці пры стварэнні прыкладання аснову для рэальнага, цалкам залежыць ад тэхналогія back-end, якую вы выбіраеце для працы з.

Такім чынам, наша дадатак можа змяняць дадзеныя некалькімі спосабамі; ён можа змяніць атрыбуты кантакту, які ўжо існуе, ён можа дадаць зусім новы кантакт, ці ён можа выдаліць кантакт, які ўжо існуе.

Лагічна рабіць усе гэтыя рэчы на ​​інтэрфейсе, але цяпер, калі задзейнічаны сервер, паводзіны старонкі ўжо змянілася. Хоць гэтая старонка будзе адлюстроўвацца так жа, як і раней, калі мы паспрабуем выдаліць кантакт, Backbone выдае памылку, скардзячыся, што URL-адрас не вызначаны. Прычына гэтага заключаецца ў тым, што мы выкарыстоўвалі метад destroy() у метадзе deleteContact() нашага класа ContactView.

Давайце паглядзім, як аднавіць функцыянальнасць выдалення. Першае, што мы павінны зрабіць, гэта вызначыць атрыбут url для нашых мадэляў. Дадайце ўласцівасць у клас Contact, які вызначае асобную мадэль:

Мы паказваем функцыю як значэнне ўласцівасці url, якая вяртае URL-адрас, які павінен выкарыстоўвацца для запыту. У гэтым прыкладзе мы можам выкарыстоўваць файл вэб-службы asmx для апрацоўкі запытаў. Мы таксама дадаем імя нашага вэб-метаду (ManageContact) і дадаем id мадэлі ў якасці параметру радкі запыту.

Цяпер, калі мы выдалім адзін з кантактаў пры запуску старонкі, у вэб-службу будзе адпраўлены запыт POST. У запыт дадаецца загаловак X-HTTP-Method-Override, які паказвае, што метад HTTP быў DELETE. Мы можам выкарыстоўваць гэта ў нашай логіцы вэб-сэрвісаў, каб вызначыць, якія дзеянні неабходна зрабіць у базе дадзеных.

Затым мы можам абнавіць метад saveEdits() класа ContactView, каб ён паведамляў вэб-службу пры рэдагаванні кантакту; змяніўшы радок кода, якая выкарыстоўвае метад set(), каб яна выглядала наступным чынам:

Усё, што мы робім, гэта звязаць метад save() з метадам set(). Метад save() дэлегуе метад sync(), які робіць запыт POST на сервер. Як і раней, id мадэлі адпраўляецца як радок запыту, а метад X-HTTP-Method-Override выкарыстоўваецца для ўказанні меркаванага метаду PUT. Аднак на гэты раз загаловак Content-Type усталяваны ў application/x-www-form-urlencoded (калі мы не наладзілі ўласцівасць emulateJSON, гэта будзе application/json), і дадзеныя мадэлі адпраўляюцца як дадзеныя формы, якія мы можам выкарыстоўваць для неабходных зменаў.

Усё, што засталося зрабіць у інтэрфейсе, - гэта абнавіць метад addContact() класа DirectoryView. Раней у гэтым метадзе мы мелі аператар if, які правяраў тып дадаванага мадэлі, каб убачыць, ці трэба абнаўляць меню выбару. Цяпер мы павінны змяніць гэта зацвярджэнне if так, каб яно выглядала наступным чынам:

Мы зрэзалі аператар if, каб выдаліць ўмова else, зрабіўшы код трохі больш акуратным. Мы таксама выдалілі метад add() і дадалі метад create() на сваё месца. Метад create() фактычна дадасць новую мадэль у калекцыю аўтаматычна, калі мы ўручную не створым новы асобнік класа нашай мадэлі, і ён таксама зробіць запыт на сервер, яшчэ раз делегируя sync().

На гэты раз загаловак X-HTTP-Method-Override не трэба ўсталёўваць, таму што POST - гэта той метад, які мы будзем выкарыстоўваць, так як запыт быў дададзены да інтэрфейсу RESTful. Як і ў метадзе save(), дадзеныя мадэлі, перададзеныя метадзе create(), дастаўляюцца на сервер у выглядзе дадзеных формы.

Як і код сервера, які выкарыстоўваецца ў пачатку гэтай частцы падручніка для загрузкі зыходных дадзеных мадэлі ў наша дадатак, код, які выкарыстоўваецца для апрацоўкі запытаў, створаных Backbone, выходзіць за рамкі ўрока. Мы зацікаўлены толькі ў пярэднім канцы тут. Як і раней, вэб-сэрвіс, які выкарыстоўваецца для гэтай дэманстрацыі, уключаны ў архіў кода і цалкам каментуецца, таму азнаёмцеся з ім, калі вы зацікаўленыя. Я таксама уключыў рэзервовую копію базы дадзеных, якую вы можаце аднавіць, каб атрымаць доступ да дэма-дадзеных.


Падвядзем вынікі

У гэтай частцы ўроку мы разгледзелі некаторыя з метадаў, якія мы можам выкарыстоўваць, якія дэлегуюць метад sync() Backbone для сувязі з фонавым кантэнтам, які можа захоўваць змены, выкананыя з дапамогай інтэрфэйснае прыкладання.

Мы бачылі, як Backbone па змаўчанні робіць запыты RESTful паказаным URL-адрасе і як мы можам яго наладзіць, каб працаваць з састарэлымі серверамі, якія не працуюць з прынцыпамі REST. Мы таксама разгледзелі некаторыя з метадаў, якія дэлегуюць sync() для сувязі з серверам. У прыватнасці, мы разгледзелі метады remove(), save() і create() і паглядзелі, што адпраўлена на сервер і як.

Мы таксама разгледзелі, як лёгка змяніць сімвалы, якія выкарыстоўваюцца Underscore, каб интерполировать дадзеныя ў шаблон. Зараз гэта завяршае ўрок Contact Manager; у той час як ёсць шмат іншых магчымасцяў, якія мы маглі б дадаць у дадатак, мы цяпер разгледзелі асновы таго, што трэба для стварэння поўнафункцыянальнага прыкладання, выкарыстоўваючы выдатны Backbone.js. Дзякуй за прачытанне матэрыялу.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.