Construiți un manager de contacte utilizând Backbone.js Partea 5

Bine ați venit înapoi la Construirea unui vizualizator de conținut cu Backbone serie. Pe primele patru părți, ne-am uitat la aproape fiecare componentă majoră care livrează cea mai recentă versiune a Backbone, inclusiv modele, controale, vizualizări și routere.

În această parte a tutorialului, vom închide aplicația noastră până la un server web pentru a putea stoca contactele într-o bază de date. Nu ne vom uita la LocalStorage; acesta este un mijloc popular de persistență a datelor pe care aplicațiile Backbone le utilizează, dar există deja un număr de tutoriale excelente disponibile pe această temă.

Noțiuni de bază

Avem nevoie de un server web și de o bază de date pentru această parte a tutorialului. Folosesc VWD-ul Microsoft ca editor, care se livrează cu un server web încorporat și funcționează bine cu serverul MSSQL, deci asta vom folosi. Într-adevăr, nu contează cu adevărat la ce stiblu te hotărăști.

Instalarea și configurarea oricăreia dintre aceste tehnologii (serverul VWD și MSSQL) depășește domeniul de aplicare al acestui tutorial, dar este relativ direct înainte și există o mulțime de ghiduri bune acolo.

Odată instalat, veți dori să configurați o nouă bază de date care să conțină un tabel pentru stocarea datelor. Coloanele tabelului ar trebui să reflecte diferitele proprietăți pe care modelele le folosesc, astfel încât ar trebui să existe o coloană de nume, o coloană de adrese etc. pot fi populate cu exemplele de date pe care le-am utilizat în întreaga serie până acum.

O coloană care ar trebui să apară în noul nostru tabel, dar pe care nu am utilizat-o în datele noastre de testare locale, este una id, care ar trebui să fie unic pentru fiecare rând din tabel. Pentru a ușura utilizarea, probabil că doriți să setați această valoare la creșterea automată atunci când datele sunt adăugate în tabel.

Backbone Sync

Pentru a comunica cu serverul, Backbone ne oferă Sincronizare modul; acesta este singurul modul major pe care nu l-am folosit încă și astfel înțelegerea va completa cunoștințele noastre despre fundamentele cadrului.

Apelarea sincronizare () metoda duce la o cerere adresată serverului; în mod implicit, presupune că fie jQuery sau Zepto este în uz și deleagă cererea către oricare dintre ei este prezent să efectueze efectiv. Se presupune, de asemenea, că o interfață RESTful așteaptă pe back-end, astfel că implicit folosește metodele POST, PUT, GET, DELETE HTTP. După cum am văzut, Backbone poate fi configurat să se întoarcă la metodele GET și POST de la școala veche, cu anteturi suplimentare care specifică acțiunea dorită.

Pe lângă posibilitatea de a apela sincronizare () direct, modelele și colecțiile au, de asemenea, metode care pot fi utilizate pentru a comunica cu serverul; modelele au distruge(), fetch (), analiza() și Salvați() metode și colecții fetch () și analiza(). distruge() fetch () și sincronizare () toate metodele sunt amânate sincronizare () indiferent dacă sunt folosite cu modele sau colecții. analiza() , numită automat ori de câte ori datele sunt returnate de server, este în mod implicit un simplu no-op care returnează răspunsul de la server, dar poate fi suprascris dacă dorim să procesăm răspunsul înainte de ao consuma.

Încărcarea paginilor pentru pagini

Modul în care datele modelului este introdus în pagină va varia în funcție de tehnologia de back-end utilizată.

Documentația backbone pentru fetch () metoda (a unei colecții) afirmă că această metodă nu ar trebui utilizată la încărcarea inițială a paginii pentru a solicita modelele necesare de la server. Ea continuă să elaboreze în secțiunea Întrebări frecvente că o pagină ar trebui să aibă modulele necesare deja disponibile pentru pagină la încărcare pentru a evita solicitarea inițială AJAX.

Aceasta este o idee minunată și, în timp ce nu trebuie să urmăm în mod explicit sfatul, acest lucru va face ca cererea noastră să fie puțin mai bună și asta nu poate fi decât un lucru bun.

Modul în care datele modelului este introdus în pagină va varia în funcție de tehnologia de back-end utilizată. Vom folosi .net în acest exemplu, astfel încât o modalitate de a face acest lucru ar fi crearea dinamic a

Logica reală în codul din spatele căreia se efectuează citirea și lista de serializare a bazei de date ar putea varia în mod sălbatic în funcție de implementare și este într-o oarecare măsură dincolo de scopul acestui tutorial - suntem mai interesați să obținem acea încărcătură utilă inițială pe pagină decât noi despre modul în care reușim. Nu ezitați să verificați fișierul de clasă în codul de însoțire descărcat pentru probabil cel mai rapid și mai ușor, dar în nici un caz cel mai bun mod de a face acest lucru.

 În acest moment, ar trebui să putem elimina matricea de contacte din care s-au păstrat datele fictive app.js, rulați pagina (prin intermediul serverului Web WVD încorporat sau IIS) și vedeți exact aceeași pagină, cu aproape aceeași funcționalitate, după cum am văzut la sfârșitul părții 4. Yay!
 
 Sincronizarea aplicației noastre cu serverul
 În acest exemplu, am folosit un fișier .net 4.0 ASMX pentru a face față cererilor de la front-end. Pentru ca back-end-ul să vadă datele trimise, trebuie să configuram emulateHTTP și emulateJSON Proprietățile backbone. Adăugați următoarele linii de cod direct după ce am schimbat sintaxa șablonului de subversiune:
 Backbone.emulateHTTP = true; Backbone.emulateJSON = true;
 Indiferent dacă veți avea nevoie să configurați aceste proprietăți atunci când construiți o aplicație Backbone pentru real depinde în întregime de tehnologia back-end cu care alegeți să lucrați.
 Deci, aplicația noastră ar putea modifica datele în mai multe moduri; ar putea schimba atributele unui contact care există deja, ar putea adăuga un contact complet nou sau ar putea șterge un contact care există deja.
 Logica pentru a face toate aceste lucruri pe front-end există deja, dar acum că este implicat un server, comportamentul paginii sa schimbat deja. Cu toate că pagina va reda așa cum a făcut înainte, dacă încercăm să ștergem un contact, Backbone va arunca o eroare în care se plânge că nu a fost definită o adresă URL. Motivul pentru aceasta este pentru că am folosit distruge() metodă în deleteContact () metoda noastră ContactView clasă.
 Să ne uităm la modul de restaurare a funcționalității de ștergere. Primul lucru pe care ar trebui să-l facem atunci este definirea a URL-ul atribut pentru modelele noastre. Adăugați proprietatea la a lua legatura clasă care definește un model individual:
 url: funcția () return "/ContactManager.asmx/ManageContact?id=" + this.get ("id"); 
 Specificăm o funcție ca valoare a URL-ul proprietate, care returnează adresa URL care ar trebui utilizată pentru a face cererile. În acest exemplu, putem folosi un fișier de servicii web asmx pentru a face față cererilor. De asemenea, adăugăm numele metodei noastre web (ManageContact) și adăugați id a modelului ca parametru de șir de interogare.
 Acum, dacă ștergem unul dintre contacte atunci când rulam pagina, o cerere POST se face către serviciul web. Un X-HTTP Metoda neînlocuire antetul este adăugat la cerere care specifică faptul că metoda HTTP intenționată a fost ȘTERGE. Putem folosi acest lucru în logica noastră de servicii web pentru a determina ce acțiune trebuie făcută în baza de date.
 Apoi putem actualiza saveEdits () metodă a ContactView astfel încât să notifice serviciul web când se editează un contact; modificați linia de cod care utilizează a stabilit() astfel încât să apară astfel:
 this.model.set (formData) comenzii .save ();
 Tot ce facem este lantul Salvați() la metoda a stabilit() metodă. Salvați() metodă delegată la sincronizare () care face o cerere POST către server. Ca și înainte id din model este trimis ca un șir de interogare și un X-HTTP Metoda neînlocuire este utilizat pentru a specifica metoda PUT dorită. De data aceasta, însă Tipul de conținut antetul este setat la application / x-www-form-urlencoded (dacă nu am configurat emulateJSON proprietate ar fi application / json), iar datele modelului sunt trimise ca date de formular, pe care le putem folosi pentru a face orice schimbări sunt necesare.
 Tot ce este lăsat să faceți la front-end este să actualizați adaugă contact() metodă a DirectoryView clasă. Anterior, în această metodă, am avut o instrucțiune if care verifică tipul modelului adăugat pentru a vedea dacă meniul selectat trebuie să fie actualizat. Acum ar trebui să schimbăm această afirmație astfel încât să apară după cum urmează:
 dacă (_.indexOf (this.getTypes (), formData.type) === -1) this. $ el.find ("# filter"). .append (this.createSelect ());  this.collection.create (formData);
 Am tăiat-o dacă declarație în jos pentru a elimina altfel condiție, ceea ce face codul un pic mai tidier. De asemenea, am eliminat adăuga() și a adăugat crea() în locul său. crea() metoda va adăuga în mod real noul model colecției în mod automat fără a crea manual o nouă instanță a clasei modelului nostru și va cere, de asemenea, serverului, să delege din nou sincronizare ().
 De data aceasta X-HTTP Metoda neînlocuire antetul nu trebuie să fie setat, deoarece POST este metoda pe care am folosi-o dacă cererea a fost făcută oricum unei interfețe RESTful. Ca și în cazul Salvați() metoda, datele de model transmise către crea() metoda este furnizată serverului ca date de formular.
 Ca și în cazul codului de pe server folosit la începutul acestei părți a tutorialului pentru a bootstra datele din modelul inițial în aplicația noastră, codul utilizat pentru a procesa și a trata solicitările făcute de Backbone depășește domeniul de aplicare al tutorialului. Suntem interesați doar de front-end aici. Ca si inainte, serviciul Web folosit pentru aceasta demonstratie este inclus in arhiva codului si este complet comentat, deci verificati-l daca sunteti interesat. Am inclus, de asemenea, o copie de rezervă a bazei de date, pe care ar trebui să o puteți restabili pentru a putea merge cu datele demo.
 
 rezumat
 În această parte a tutorialului, ne-am uitat la câteva dintre metodele pe care le putem folosi care le delegă pe Backbone's sincronizare () pentru a comunica cu un back-end care poate persista modificările făcute utilizând front-end-ul aplicației.
 Am văzut cum implicit Backbone face cererile RESTful către o adresă URL specificată și cum o putem configura pentru a putea lucra cu serverele vechi care nu funcționează pe principiile REST. De asemenea, ne-am uitat la unele dintre metodele pe care le delegăm sincronizare () pentru a comunica cu serverul. Mai exact, am acoperit elimina(), Salvați() și crea() și a analizat ceea ce este trimis către server și cum.
 De asemenea, am analizat cât de ușor este de a schimba simbolurile pe care Underscore le utilizează pentru a interpola datele într-un șablon. Acest lucru încheie acum tutorialul Contact Manager; în timp ce există multe alte caracteristici pe care le-am putea adăuga la aplicație, am acoperit acum elementele de bază ale a ceea ce este nevoie pentru a construi o aplicație complet funcțională utilizând excelentul Backbone.js. Vă mulțumim pentru lectură.



		
			
	   
	




Cod