Share
Sails.js er et oppadgående Node.js-rammeverk med fokus på frihet og smarte standardinnstillinger. I denne artikkelen tar vi en titt på noen av datafunksjonene. Seilene gir ut av boksen, slik at du enkelt kan lage komplekse apper.
Grunnen til å velge seil er best satt av seilskaperen Mike McNeil, "Seilene ble skapt av nødvendighet". Mange rammer du ser rundt, er bygget nesten for den akademiske siden av ting, disse rammene pleier å fremme beste praksis, og skape en plattform for utviklere å skape ting raskere eller bedre.
Seil derimot, ble opprettet for produksjon, det prøver ikke å gi deg en ny syntaks eller plattform, det er en solid base, beregnet for å skape "klient-arbeid" med fart. Kontrasten kan være subtil, men det er noen forskjellige forskjeller.
For å illustrere det jeg refererer til, la oss ta en titt på Meteor. Meteor er trolig den ledende JS-plattformen rundt i dag, men det er et godt eksempel på et rammeverk, for rammens skyld. Nå er dette ikke dårlig, jeg er en stor tilhenger av Meteor, det jeg mener er, de satte seg for å bygge et rammeverk og de gjorde en god jobb på det, satte Mike derimot seg for å gjøre klientarbeidet raskere . Seil er bare et middel for å få en slutt.
I Meteor er stort sett alt abstradert vekk, og du bruker JavaScript pluss Meteor API for å kode alt. Mens seil ikke er ment å være en ny plattform, så ingenting er skjult.
Den hviler på toppen av Socket.io og den populære Express-rammen, og du har tilgang til dem i sin helhet, nativt. Begynner du å se forskjellen?
Siden Sails er tilpasset produksjon først, er det bygget med flere muligheter for skalering og sikkerhet.
Det er mye å snakke om, men i denne artikkelen vil jeg fokusere på hvordan Sails håndterer data, og hvordan du kan utnytte noen av seilens mer avanserte funksjoner for å utføre noen virkelig kule handlinger.
Bare i tilfelle du ikke har seiler meldt ennå, kan du gjøre det via NPM ved å kjøre:
sudo npm installere -g seiler
La oss nå snakke litt om Socket.io og Express før vi kommer inn i Sails. Det er en god premiumserie på Express av Andrew Burgess hvis du er interessert, men jeg løper gjennom de grunnleggende omgangene til begge disse bibliotekene her:
Socket.io er et pub / sub-bibliotek, som kjøres både på serveren og på klienten, og det tillater dem å snakke via nettkontakter.
Et kort eksempel kan se slik ut:
Accentsconagua
// Kode for server var io = krever ("socket.io"); io.sockets.on ("forbindelse", funksjon (sokk) sock.emit ("welcomeMessage", hei: "world"); io.listen (80); Denne koden starter ved å kreve socket.io bibliotek, lytte etter en tilkobling, og så når en annen kontakt kobles, sender den den en melding, adressert til velkomstmelding arrangement, og til slutt passerer noen JSON.
Deretter på klienten ville du skrive noe som:
// Kode for klient var sokk = io.connect ('http: // localhost'); sock.on ('welcomeMessage', funksjon (json) // Handle Event Received); Her kobler vi til serveren og lytter etter det velkomstmelding hendelse vi nettopp har opprettet. Som du kan se er det en ganske enkel publiserings- / abonnementserver, som er toveis (klienten kan også sende meldinger til serveren).
La oss nå ta en titt på Express:
Den enkleste form for en Express-rute kan være noe som:
app.get ('/ users', funksjon (req, res) res.send ("Hello from '/ users'!");); Dette definerer en enkel rute, slik at når en bruker går til nettstedets adresse og prøver å få tilgang til / brukere siden, vil de bli presentert med meldingen "Hei fra" / brukere "!".
Så Express er et rammeverk for håndtering av HTTP-forespørsler og Socket.io er et websocket kommunikasjonsbibliotek. Det som seilteamet har gjort, er imidlertid kart alle ekspressruter til Socket.io internt. Hva dette betyr er, kan du ringe noen av HTTP-ruter gjennom webkontakter.
Nå er det ganske kult! Men det er fortsatt et stykke av puslespillet mangler, og det er Sails Blueprints.
Seil lar deg generere modeller akkurat som i andre rammer, forskjellen er, Sails kan også generere en produksjonsklar RESTfull API for å gå med dem. Dette betyr at hvis du genererer en modell som heter 'brukere'du kan umiddelbart kjøre RESTfull spørringer på'/ brukere'ressurs uten koding nødvendig.
Hvis du er ny til RESTful APIer, er det bare en måte å få tilgang til data, hvor CRUD-operasjoner er kartlagt til forskjellige HTTP-metoder.
Så a FÅ be om å '/ brukere'får alle brukerne, a POST forespørsel vil opprette en ny bruker osv.
Så hva betyr alt dette?
Det betyr at vi har en full RESTfull API, kartlagt til Socket.io via Sails, uten å skrive en enkelt linje med kode!
Men hvorfor er stikkontakter bedre å hente data og deretter en Ajax-forespørsel? Vel, foruten å være en slankere protokoll, forblir stikkontakter åpen for toveis kommunikasjon, og seil har benyttet seg av dette. Ikke bare vil Sails sende deg dataene, men det vil automatisk abonnere deg på oppdateringer i databasen, og når noe blir lagt til, fjernet eller oppdatert, mottar klienten din et varsel via nettkontakten, slik at du får beskjed om det.
Det er derfor Sails er så fantastisk!
Det neste emnet jeg vil dekke er Backbone-integrasjon, fordi hvis du ikke bruker et JavaScript-rammeverk, gjør du det feil.
Med dette i bakhodet er Sails and Backbone det perfekte paret. Ryggraden, som seil, er ekstremt diskret, alle funksjonene er tilgjengelige, kan overstyres og valgfritt.
Hvis du har brukt Ryggrad før du kanskje vet at den er koblet til REST APIer, så kan du synkronisere dataene på forsiden med seilprogrammet ditt..
Men nok snakk for nå, la oss ta en titt på alt dette i aksjon ved å lage et grunnleggende chatprogram. For å komme i gang, åpne et terminalvindu og skriv inn:
seiler nye ChatApp cd ChatApp seiler generere modell brukere seiler generere modellmeldinger seiler generere kontroller meldinger seiler generere controller hoved
Dette vil opprette en ny app og generere noen filer for oss. Du kan se ovenfra, det er to forskjellige ressurser du kan generere; modeller og kontroller. Hvis du er kjent med MVC-designmønsteret, bør du vite hva dette er, men kort sagt, modeller er dine data og kontrollører holder din logikkode. Så vi trenger to samlinger, en for å holde brukerne og en for meldingene.
Deretter, for kontrollerne, trenger vi en til å håndtere sidelinjer, jeg ringte det 'hoved-', så har vi en andre kontroller kalt'meldinger'. Nå kan du kanskje lure på hvorfor jeg opprettet en kontroller med samme navn som vår meldinger modell? Vel, hvis du husker, sa jeg at seil kan skape en REST API for deg. Hva skjer, ved å opprette en tom kontroller med samme navn som en modell, vil Sails vite å falle tilbake og bygge en REST API for den tilsvarende ressursen.
Så, vi har opprettet en kontroller for vår meldinger modell, men det er ikke nødvendig å lage en til brukermodellen, så jeg har nettopp forlatt det. Og det er alt det er å skape modeller og kontrollører.
Neste, la oss sette opp noen ruter.
Ruter er alltid et trygt sted å begynne, fordi du vanligvis har en god ide om hvilke sider som skal gjøres.
Så åpne opp routes.js fil som er i config mappe, kan det se litt overveldende først, men hvis du fjerner alle kommentarene og legger til i følgende ruter, blir du igjen med noe slikt:
module.exports.routes = '/': controller: 'main', handling: 'index', '/ signup': kontroller: 'main', action: 'signup', '/ login' controller: 'main', handling: 'login', '/ chat': controller: 'main', handling: 'chat';
Vi har en startside, en chat side, og deretter to sider for å håndtere både påloggings- og registreringssidene. Jeg legger dem alle i samme kontroller, men i Sails, kan du opprette så mange kontroller som du vil.
Neste, la oss ta en titt på den genererte meldinger modell som kan plasseres på "api> modeller> Messages.js"Vi må legge til de nødvendige kolonnene i modellen vår. Nå er dette ikke helt nødvendig, men det vil skape noen hjelpefunksjoner for oss som vi kan bruke:
// Meldinger Model module.exports = attributter: userId: 'INT', brukernavn: 'STRING', melding: 'STRING';
For meldinger modell, starter vi med id av brukeren som denne meldingen tilhører, a brukernavn så vi trenger ikke å spørre dette separat, og deretter selve budskap.
La oss nå fylle ut brukerens modell:
// Brukere Modell module.exports = attributter: brukernavn: 'STRING', passord: 'STRING';
Og det er det, vi har bare brukernavn og passord egenskaper. Det neste trinnet er å skape våre rutefunksjoner inne i MainController.
Så åpne opp MainController, som kan bli funnet på "api> controllers> MainController.js". La oss begynne med å skape en funksjon for hver av ruterne vi definerte ovenfor:
Var MainController = indeks: funksjon (req, res) , tilmelding: funksjon (req, res) , logg inn: funksjon (req, res) , chat: funksjon (req, res) ; module.exports = MainController;
Hvis du er kjent med Express, vil du gjerne se at disse funksjonene er standard Express rutefunksjoner. De får to variabler, req for HTTP-forespørselen og res å skape svaret.
Etter MVC-mønsteret tilbyr Sails en funksjon for gjengivelse av visninger. Hjemmesiden trenger ikke noe spesielt, så la oss bare gjengi visningen.
indeks: funksjon (req, res) res.view (); ,
Seil lener seg mer mot konvensjon over konfigurasjon, så når du ringer res.view (); Seil vil se etter en visningsfil (med en .ejs utvidelse som standard) ved å bruke følgende mønster: 'visninger> controllerName> methodName.ejs'. Så for denne samtalen, vil den søke etter 'visninger> main> index.ejs'. Det er også verdt å merke seg, disse visningene inneholder bare visningsspesifikke deler av siden. Hvis du tar en titt på 'visninger> layout.ejs', vil du se et anrop i midten for <%- body %>, Dette er hvor visningsfilen din vil bli satt inn. Som standard bruker den denne 'layout.ejs'fil, men du kan bruke andre layoutfiler bare ved å sende layoutnavnet til res.view () funksjon, under eiendommen kalt 'layout'. For eksempel: 'res.view (layout: "other.ejs");'.
Jeg skal bruke standard layoutfilen med en liten justering, jeg skal legge til jQuery, Backbone og Underscore. Så i "layout.ejs'fil rett før avslutningen tag, legg til følgende linjer:
Med det på plass er vi nå klare til å lage hjemmesiden.
La oss lage en ny mappe inne i visninger mappen heter hoved-, og innsiden av vår nye hoved- mappe, oppretter vi en ny fil kalt 'index.ejs'.
Inne i filen, la oss bare opprette en påloggings- og påmeldingsskjema:
Kode Chat
Logg Inn
Melde deg på
Ganske enkelt, bare essensielle.
Deretter må vi legge til litt JS for å få dette til å kommunisere med serveren. Nå vil dette ikke være Sailspesifikke, vi skal bare sende en AJAX-forespørsel via jQuery til Seil-serveren.
Denne koden kan enten inkluderes på selve siden eller lastes inn via en egen JS-fil. For enkelhets skyld skal jeg bare legge den nederst på samme side:
Dette er bare standard JS og jQuery, vi lytter etter klikkhendelsen på påloggingsknappen, og sørger for at brukernavn og passordfelt er fylt ut, og legger inn dataene til "/Logg Inn'rute. Hvis innloggingen er vellykket, viderekobler vi brukeren til chat siden, ellers vil vi vise feilen returnert av serveren.
Neste, la oss lage det samme for påmeldingsområdet:
val (); var passord = $ ("# signupPassword") .val (); var confirmPassword = $ ("# signupButton") #signupConfirmPassword ") .val (); hvis (brukernavn og & passord) if (passord === bekrefte passord) $ .post ('/ signup', brukernavn: brukernavn, passord: passord, funksjon () vindu plassering = "/ chat";) .fail (funksjon (res) alert ("Feil:" + res.getResponseHeader ("error");; else alert ("Passord stemmer ikke overens") ; else alert ("Et brukernavn og passord kreves");); Denne koden er nesten identisk, så mye, at du nok bare kan trekke hele Ajax-delen ut i sin egen funksjon, men for denne opplæringen er det greit.
Nå må vi gå tilbake til vår "MainController'og håndtere disse to rutene, men før vi gjør det, vil jeg installere en Node-modul. Vi kommer til å trenge å hash passordet, som vanlig tekst passord er ikke En god ting, ikke engang for demonstrasjon! Jeg fant en fin modul kalt 'password-hash' av David Wood som vil fungere pent.
For å installere det, bare gå til roten til Seil-appen din, fra din terminal og type: npm installer passord-hash.
Når det er installert, la oss åpne MainController og implementer de to nødvendige ruter. La oss begynne med melde deg på:
påmelding: funksjon (req, res) var brukernavn = req.param ("brukernavn"); var passord = req.param ("passord"); Users.findByUsername (brukernavn) .done (funksjon (feil, usr) hvis (err) res.send (500, error: "DB Error"); annet hvis (usr) res.send (400, error: "Brukernavn allerede tatt"); else var hasher = krever ("password-hash"); passord = hasher.generate (passord); Users.create (brukernavn: brukernavn, passord: passord). ferdig (funksjon (feil, bruker) hvis (feil) res.send (500, error: "DB Error"); else req.session.user = bruker; res.send (bruker); );); Det er litt ordentlig, men alt vi gjør her, leser brukernavnet og passordet fra POST-forespørselen og sørger for at brukernavnet ikke allerede er tatt. Du kan se at jeg også bruker passord-hasheren vi nettopp har installert, den er super enkel å bruke, bare passordet går inn i generasjonsmetoden, og det vil ha det ved å bruke et tilfeldig salt.
Det er også verdt å nevne at vi på alle mulige steder der det kan oppstå en feil eller et problem, sender tilbake en HTTP-feilkode og returnerer en melding via en egendefinert overskrift med navnet 'feil'som, hvis du husker, viser vi i en varselmelding på indekssiden.
Et annet bemerkelsesverdig poeng er at vi bruker en "magisk" -funksjon kalt 'findByUsername', dette er gjort mulig fordi vi har a brukernavn kolonne inne i brukermodellen vår.
Til slutt, nederst kan du se om alt gikk bra, vi lagrer brukeren i en sesjonsvariabel og returnerer den med en standard statuskode på 200, noe som forteller jQuery at AJAX-forespørselen var vellykket.
Deretter skriver vi innloggingsfunksjonen:
logg inn: funksjon (req, res) var brukernavn = req.param ("brukernavn"); var passord = req.param ("passord"); Users.findByUsername (brukernavn) .done (funksjon (feil, usr) hvis (err) res.send (500, error: "DB Error"; annet hvis (usr) var hasher = "password-hash"), hvis (hasher.verify (passord, usr.password)) req.session.user = usr; res.send (usr); else res.send (400, error: "Wrong Passord "); annet res.send (404, error:" Bruker ikke funnet ");); Igjen, dette er veldig lik den forrige melde deg på funksjon, søker vi etter en bruker med samme brukernavn som ble lagt ut fra skjemaet, og hvis det finner en, kontrollerer vi om passordet samsvarer med bruk av hasherens bekrefte metode. Grunnen til at vi ikke bare kan hash passordet igjen og sende det inn i modellene finne funksjonen er fordi hasher bruker et tilfeldig salt, så hvis vi har fått passordet igjen, ville det være lik noe annet.
Resten av koden er den samme; Hvis alt sjekker ut, lagrer vi brukeren i en økt og returnerer den, ellers sender vi en feilmelding tilbake.
Innloggingssystemet er nå fullført, og vi kan endelig fortsette å bygge chat-funksjonen.
Siden vi bruker Backbone for å få meldingene, vil den faktiske rutefunksjonen være veldig enkel. Her er komplett chat-funksjon:
chat: funksjon (req, res) if (req.session.user) res.view (brukernavn: req.session.user.username); ellers res.redirect ('/'); Vi starter med å sjekke om brukeren er logget inn eller ikke, hvis dette sjekker ut, vil det laste inn visningen, passere det brukernavnet som var i sesjonen, ellers omdirigerer vi bare til hjemmesiden.
La oss nå lage en ny visning kalt 'chat.ejs'innsiden av hoved- mappe. Åpne den opp og la oss lage en enkel skjema for å legge inn nye meldinger og a div beholder for å vise dem alle.
Velkommen <%= username %>
Så for denne visningen brukte vi bare noen ganske standard HTML. Det eneste som kan kreve noen forklaring er <%= username %> kode, denne typen koding er ikke spesifikk for seil, det er faktisk syntaksen for EJS. Denne syntaksen ligner veldig på PHPs korte tagger. <% er ekvivalent av i PHP og <%= er det samme som . Den første delen av EJS lar deg integrere standard JS-kode på siden, mens den andre skriver ut koden i. Her skriver vi bare ut brukernavnet vi passerte inn fra kontrolleren.
Resten av vår chat-funksjon vil være alt JavaScript. For å komme i gang, la oss se på hvordan du vil skrive chat-funksjonaliteten ved hjelp av standard Ryggrad, og så ser vi hvordan du kan dra nytte av nettkontakter.
Nederst på siden legger du til følgende JS:
Siden Sails automatisk oppretter en API som Backbone forstår innfødt, ingen ekstra serverkode må skrives, det blir ikke mye enklere enn det. Dette er hva jeg snakket om da jeg sa at seil ikke ble laget for å være et "rammeverk". Det prøver ikke å få deg til å bruke sin egen syntaks, det ble laget for å få ting gjort og som du kan se, leverer det.
For å teste det ut, åpne et terminalvindu og navigere til din Seil-appmappe, og skriv deretter 'seil løft'for å starte opp. Som standard vil det lanseres til http: // localhost: 1337. Nå bare registrer deg og legg inn noen meldinger.
For å se de meldte meldingene du kan console.log meldingene varierer, eller se på det inne i nettleserens konsoll. Nå er den neste tingen vi bør implementere en visning slik at vi kan se de meldte meldingene i nettleseren.
_.templateSettings = interpolate: /\\(.+?)\\/g; var MessagesView = Backbone.View.extend (el: '#messagesContainer', initialiser: funksjon () this.collection.on ('add', this.render, dette); this.render ();, mal: _.mal(" budskap
"), gjengi: funksjon () this. $ el.html (" "); this.collection.each (funksjon (msg) this. $ el.append (this.template (msg.toJSON ())); , dette); var mView = ny MessagesView (samling: meldinger); Vi starter med å definere en visning, og vedlegg den til diven som vi opprettet tidligere, så legger vi til en hendelsehandler på samlingen for å gjengi div hver gang en ny modell blir lagt til samlingen.
Du kan se øverst, jeg måtte endre standard Underscore-innstillingene fra å bruke EJS-syntaksen inne i maler, i stedet bruk Mustache's syntaks. Dette skyldes at siden allerede er et EJS-dokument, så det ville bli behandlet ut på serveren og ikke i Underscore.
Merk: Jeg kom ikke med Regex for dette, den kreditten går til Underscore docs selv.
Til slutt, nederst kan du se at vi opprettet en ny forekomst av denne visningen, og bestiller den innsamlingsvariabelen.
Hvis alt gikk bra, bør du nå se meldingene dine i nettleseren, og den skal oppdateres når du oppretter et nytt innlegg.
Nå har du kanskje lagt merke til at vi ikke setter inn bruker-ID eller brukernavn når vi sender innleggene, og dette er for sikkerhetsformål.
Du vil ikke sette denne typen kontroll på klientsiden. Hvis alle noen må gjøre, er å endre en JavaScript-variabel for å kontrollere en annen brukers konto, har du et stort problem.
Så, hvordan skal du håndtere dette? Vel, med politikk selvsagt.
Retningslinjer er i utgangspunktet mellomvare, som kjører før den faktiske webforespørselen, hvor du kan stoppe, endre eller til og med omdirigere forespørselen etter behov.
For denne appen, la oss opprette en policy for våre meldinger. Retningslinjer brukes til kontroller, så de kan til og med kjøre på vanlige sider, men for denne opplæringen la vi bare holde fast med en for vår meldinger Modell.
Opprett en fil med navnet 'MessagesPolicy.js' i 'api> retningslinjer'mappe og skriv inn følgende:
module.exports = funksjon (req, res, neste) if (req.session.user) var action = req.param ('action'); hvis (handling == "opprett") req.body.userId = req.session.user.id; req.body.username = req.session.user.username; neste (); else res.send ("Du må logges inn", 403); ; Så hva skjer her? Du kan se denne funksjonen ligner en normal rutefunksjon, men forskjellen er den tredje parameteren, som vil kalle neste mellomvare i stabelen. Hvis du er ny på ideen om mellomvare, kan du tenke på det som en russisk nestende dukke. Hvert lag får forespørselen, sammen med responsvariablene, og de kan endre dem slik de passer. Hvis de passerer alle kravene, kan laget passere det videre inntil det kommer til sentrum, som er rutefunksjonen.
Så her er vi og sjekker om brukeren er logget inn, hvis brukeren ikke er det, viser vi en 403-feil og forespørselen slutter her. Ellers (dvs. brukeren er logget inn) vi ringer neste (); å sende den videre. Midt i koden ovenfor er det hvor vi injiserer noen innleggsvariabler. Vi bruker dette til alle samtaler på kontrollpanelet "meldinger" (i utgangspunktet API), så vi får handlingen og kontroller om denne forespørselen prøver å opprette en ny melding, i så fall legger vi inn postfeltene for brukerens id og brukernavn.
Deretter åpner du policies.js fil som er i config-mappen, og legg til i retningslinjene som vi nettopp har opprettet. Så filen din skal se slik ut:
module.exports.policies = '*': true, 'messages': 'MessagesPolicy';
Når dette settes inn, må vi slette alle de gamle postene, da de ikke har disse nye brikkene. Så lukk seil serveren (ctrl-c) og i samme terminal vindu type: rm -r .tmp å fjerne den midlertidige databasen som gir oss en ren skifer.
Deretter la vi legge til brukernavnet til de aktuelle innleggene, så i "chat.ejs" endres malen til:
mal: _.template ("brukernavn: budskap
"), Start Sails-serveren på nytt (igjen ved bruk av seil løft) og registrer en annen ny bruker for å teste den ut. Hvis alt fungerer som det skal, kan du legge til meldinger og se navnet ditt i innlegget.
På dette tidspunktet har vi et ganske bra oppsett, vi henter innlegget automatisk ved hjelp av Backbone og API, pluss vi har noen grunnleggende sikkerhet på plass. Problemet er, det vil ikke oppdatere når andre sender meldinger. Nå kan du løse dette ved å opprette et JavaScript-intervall og avstemning for oppdateringer, men vi kan gjøre det bedre.
Jeg nevnte tidligere at Sails utnytter websockets bidireksjonelle evner til å legge inn oppdateringer på de abonnerte dataene. Ved hjelp av disse oppdateringene kan vi lytte etter nye tillegg til meldingsbordet og oppdatere samlingen tilsvarende.
Så i chat.ejs fil, la oss lage en ny type samling; en seilkolleksjon:
var SailsCollection = Backbone.Collection.extend (sailsCollection: "", socket: null, synkronisering: funksjon (metode, modell, alternativer) var hvor = ; hvis (options.where) where = where: options. hvor hvis (typeof this.sailsCollection === "streng" && this.sailsCollection! == "") this.socket = io.connect (); this.socket.on ("connect", _.bind funksjon () this.socket.request ("/" + this.sailsCollection, hvor, _.bind (funksjon (brukere) this.set (users);, this)); this.socket.on ("message ", _.bind (funksjon (msg) var m = msg.uri.split (" / "). pop (); hvis (m ===" opprett ") this.add (msg.data); ellers hvis (m === "oppdater") this.get (msg.data.id) .set (msg.data); annet hvis (m === "ødelegge") this.remove (this.get (msg.data.id));, dette));, dette)); else console.log ("Feil: Kan ikke hente modeller fordi egenskapsegler" ikke er satt på samlingen "); ); Nå kan det være lenge, men det er faktisk veldig enkelt, la oss gå gjennom det. Vi starter med å legge til to nye egenskaper til samlingsobjektet, en for å holde navnet på seilmodellen 'og en for å holde nettkontakten. Deretter endrer vi synkron funksjon, hvis du er kjent med Backbone, så vet du at dette er funksjonen som grensesnittet til serveren når du ringer ting som for eksempel hente. Vanligvis brenner den av Ajax-forespørsler, men vi skal tilpasse den til sokkelkommunikasjon.
Nå bruker vi ikke mesteparten av funksjonaliteten som synkron funksjontilbud, hovedsakelig fordi vi ikke har lagt til muligheten for at brukerne kan oppdatere eller slette meldinger, men bare for å være komplette, vil jeg inkludere dem innenfor funksjonsdefinisjonen.
La oss ta en titt på den første delen av synkron funksjon:
var hvor = ; hvis (options.where) where = where: options.where
Denne koden kontrollerer først om noen "hvor'klausuler ble sendt gjennom, dette ville la deg gjøre ting som: messages.fetch (hvor: id: 4); å bare hente rader der id er fire.
Deretter har vi noen kode som sikrer at "sailsCollection'Egenskapen er satt, ellers logger vi en feilmelding. Etterpå lager vi en ny kontakt og kobler til serveren, lytter etter forbindelsen med på ( 'kobler') begivenhet.
Når du er tilkoblet, ber vi om indeksen for "sailsCollection'spesifisert for å trekke inn den nåværende listen over modeller. Når den mottar dataene, bruker vi samlingen sett funksjonen til å innstille modellene.
Ok, nå så langt, har vi tilsvarende standarden hente kommando. Den neste koden er hvor push-varslingene skje:
this.socket.on ("message", _.bind (funksjon (msg) var m = msg.uri.split ("/"). pop (); hvis (m === "create") dette. legg til (msg.data); annet hvis (m === "oppdatering") this.get (msg.data.id) .set (msg.data); annet hvis (m === "ødelegge") this.remove (this.get (msg.data.id));, dette)); Nå er handlingen som blir utført (enten vi lager, oppdaterer eller ødelegger en melding) funnet i selve msg, som er så inne i uri. For å få handlingen, deler vi URI på fremoverstreker ('/') og tar bare det siste segmentet ved hjelp av pop funksjon. Vi forsøker da å samsvare med de tre mulige handlinger av skape, Oppdater, eller ødelegge.
Resten er standard Ryggrad, vi legger til, redigerer eller fjerner den angitte modellen. Med vår nye klasse nesten fullført, er alt som er igjen å gjøre, å endre dagens MessageCollection. I stedet for å utvide Backbone-samlingen, må den utvide vår nye samling, slik som:
var MessageCollection = SailsCollection.extend (sailsCollection: 'messages', modell: MessageModel);
I tillegg til å utvide vår nye samling, gjør vi en annen endring, slik at vi i stedet for å angi nettadressegenskapen, angir egenskapen seilCollection. Og det er alt der er til det. Åpne applikasjonen i to forskjellige nettlesere (for eksempel Chrome og Safari) og registrer to separate brukere. Du bør se at meldte meldinger fra en av nettleserne blir umiddelbart vist på den andre, ingen polling, ingen problemer.
Seil er et pust av frisk luft, i en rot av rammer. Den kontrollerer sitt ego ved døren, og gjør hva det kan for å hjelpe utvikleren i stedet for merkevaren. Jeg har snakket med seilens devs, og jeg kan fortelle deg at det er enda mer awesomeness i verkene, og det vil være interessant å se hvor dette rammen går.
Så konklusjonen har du lært hvordan du konfigurerer, bruker og sikrer dataene dine fra Seil, samt hvordan du grensesnitter det med det populære Backbone-biblioteket.
Som alltid, hvis du har kommentarer, er du velkommen til å legge dem under, eller bli med på Nettuts + IRC-kanalen ("#nettuts" på freenode). Takk for at du leser.
