Share
Sails.js è una struttura Node.js emergente, con un focus sulla libertà e le impostazioni predefinite intelligenti. In questo articolo daremo un'occhiata ad alcune delle caratteristiche dei dati che Sails fornisce immediatamente, per creare facilmente applicazioni complesse.
Il motivo per scegliere Sails è il miglior creatore di Sails, Mike McNeil, "Sails è stato creato per necessità". Molti framework che vedete in giro, sono costruiti quasi per il lato accademico delle cose, questi framework di solito favoriscono le best practice e creano una piattaforma per gli sviluppatori per creare le cose più velocemente, o meglio.
Sails, d'altro canto, è stato creato per la produzione, non sta cercando di fornirti una nuova sintassi o piattaforma, è una solida base, pensata per creare 'client-work' con velocità. Il contrasto può essere sottile, ma ci sono alcune differenze distinte.
Per illustrare a cosa mi riferisco, diamo un'occhiata a Meteor. Meteor è probabilmente la piattaforma JS leader attualmente in circolazione, ma è un ottimo esempio di framework, per il bene di un framework. Ora non è una brutta cosa, sono un grande sostenitore di Meteor, quello che voglio dire è che si sono impegnati a costruire un framework e hanno fatto un buon lavoro, Mike al contrario si è proposto di rendere il lavoro client più veloce . Le vele sono solo un mezzo per raggiungere un fine.
In Meteor, praticamente tutto è astratto e si utilizza JavaScript più l'API Meteor per codificare tutto. Mentre Sails non è pensato per essere una nuova piattaforma, quindi nulla è nascosto.
Si basa su Socket.io e sul popolare framework Express, e puoi accedervi interamente, in modo nativo. Stai iniziando a vedere la differenza?
Inoltre, poiché Sails è orientato per la produzione prima, è costruito con molteplici opzioni per il ridimensionamento e la sicurezza.
C'è molto da parlare, ma in questo articolo vorrei concentrarmi su come Sails gestisce i dati e su come sfruttare alcune delle funzionalità più avanzate di Sails per eseguire azioni davvero interessanti.
Nel caso in cui non hai ancora installato Sails, puoi farlo tramite NPM eseguendo:
sudo npm installa -g vele
Parliamo un po 'di Socket.io ed Express prima di entrare in Sails. Se sei interessato, c'è una buona serie premium su Express di Andrew Burgess, ma qui descriverò le basi pertinenti di entrambe queste librerie:
Socket.io è una libreria pub / sub, che viene eseguita sia sul server che sul client e consente loro di parlare tramite socket Web.
Un breve esempio potrebbe assomigliare a questo:
Accentsconagua
// Code For Server var io = require ("socket.io"); io.sockets.on ("connection", function (sock) sock.emit ("welcomeMessage", hello: "world"); io.listen (80); Questo codice inizia richiedendo il socket.io libreria, ascoltando una connessione, e poi quando un altro socket si connette, invierà un messaggio, indirizzato al messaggio di benvenuto evento e, infine, passando per alcuni JSON.
Successivamente, sul client si scriverebbe qualcosa come:
// Codice per client var sock = io.connect ('http: // localhost'); sock.on ('welcomeMessage', function (json) // Gestisci evento ricevuto); Qui ci connettiamo al server e ascoltiamo per quello messaggio di benvenuto evento che abbiamo appena creato. Come puoi vedere è un server di pubblicazione / sottoscrizione abbastanza semplice, che è bidirezionale (il client potrebbe anche emettere messaggi per il server).
Ora diamo un'occhiata a Express:
La forma più semplice di una rotta Express potrebbe essere qualcosa del tipo:
app.get ('/ users', function (req, res) res.send ("Ciao da '/ users'!");); Questo definisce un percorso semplice, in modo che quando un utente va all'indirizzo del tuo sito e cerca di accedere al / utenti pagina, verrà presentato il messaggio "Ciao da" / utenti "!".
Quindi Express è un framework per gestire le richieste HTTP e Socket.io è una libreria di comunicazioni websocket. Ciò che il team di Sails ha fatto, è mappare internamente tutte le rotte Express verso Socket.io. Ciò significa che è possibile chiamare uno qualsiasi dei percorsi HTTP tramite socket Web.
Ora è fantastico! Ma c'è ancora un pezzo del puzzle mancante e questo è il modello di Sails.
Sails ti permette di generare modelli proprio come in altri framework, la differenza è che Sails può anche generare un'API RESTfull pronta per la produzione per andare con loro. Questo significa che se generi un modello chiamato 'utenti'è possibile eseguire immediatamente query RESTfull'/ utenti'risorsa senza alcuna codifica necessaria.
Se sei nuovo alle API RESTful, è solo un modo per accedere ai dati, dove le operazioni CRUD sono mappate a vari metodi HTTP.
Quindi a OTTENERE richiesta a/ utenti'otterrà tutti gli utenti, a INVIARE la richiesta creerà un nuovo utente, ecc.
Quindi cosa significa tutto questo?
Significa che abbiamo un'API RESTfull completa, mappata a Socket.io tramite Sails, senza scrivere una singola riga di codice!
Ma perché i socket sono migliori per il recupero dei dati, quindi una richiesta Ajax? Bene, oltre ad essere un protocollo più snello, le prese rimangono aperte per la comunicazione bidirezionale, e Sails ne ha approfittato. Non solo Vele ti passerà i dati, ma ti iscriverà automaticamente agli aggiornamenti su quel database, e ogni volta che qualcosa viene aggiunto, rimosso o aggiornato, il tuo cliente riceverà una notifica tramite la presa web, facendoti sapere.
Questo è il motivo per cui Sails è davvero fantastico!
L'argomento successivo che vorrei trattare è l'integrazione Backbone, perché se non si utilizza un framework JavaScript, lo si sta facendo male.
Con questo in mente, Sails e Backbone sono la coppia perfetta. Backbone, come Sails, è estremamente discreto, tutte le sue funzionalità sono disponibili, in grado di essere sovrascritte e facoltative.
Se hai già utilizzato Backbone, potresti sapere che si connette in modo nativo con le API REST, quindi puoi sincronizzare i dati sul front-end con l'applicazione Sails..
Per ora basta parlare, diamo un'occhiata a tutto questo in azione creando un'applicazione di chat di base. Per iniziare, apri una finestra di terminale e digita:
vele nuovo ChatApp cd ChatApp vele generano modello utenti vele generare modello messaggi vele generare controller messaggi vele generare controller principale
Questo creerà una nuova app e genererà alcuni file per noi. Puoi vedere da sopra, ci sono due diverse risorse che puoi generare; modelli e controller. Se hai familiarità con il modello di progettazione MVC, dovresti sapere quali sono, ma in breve, i modelli sono i tuoi dati e i controller mantengono il tuo codice logico. Quindi avremo bisogno di due collezioni, una per gli utenti e una per i messaggi.
Successivamente, per i controller, abbiamo bisogno di uno per gestire i percorsi della pagina, l'ho chiamato 'principale', quindi abbiamo un secondo controller chiamato'messaggi'. Ora ti potresti chiedere perché ho creato un controller con lo stesso nome del nostro messaggi modello? Bene, se ricordi, ho detto che Sails può creare per te una API REST. Quello che succede è che, creando un controller vuoto con lo stesso nome di un modello, Sails saprà tornare indietro e creare un'API REST per la risorsa corrispondente.
Quindi, abbiamo creato un controller per il nostro messaggi modello, ma non è necessario crearne uno per il modello degli utenti, quindi l'ho appena escluso. E questo è tutto ciò che c'è da fare per creare modelli e controller.
Quindi, impostiamo alcuni percorsi.
Le rotte sono sempre un posto sicuro per iniziare, perché di solito hai una buona idea di quali pagine saranno realizzate.
Quindi apri il routes.js file che è nel config cartella, all'inizio potrebbe sembrare un po 'opprimente, ma se rimuovi tutti i commenti e aggiungi i seguenti percorsi, rimarrai con qualcosa del genere:
module.exports.routes = '/': controller: 'main', action: 'index', '/ signup': controller: 'main', action: 'signup', '/ login': controller: 'main', action: 'login', '/ chat': controller: 'main', action: 'chat';
Abbiamo una pagina iniziale, una pagina di chat e quindi due pagine per la gestione delle pagine di accesso e di registrazione. Li ho messi tutti nello stesso controller, ma in Sails, puoi creare tutti i controller che desideri.
Successivamente, diamo un'occhiata al generato messaggi modello che può essere posizionato a "api> modelli> Messages.js"Abbiamo bisogno di aggiungere le colonne necessarie al nostro modello. Ora questo non è assolutamente necessario, ma creerà alcune funzioni di supporto per noi che possiamo usare:
// Messaggi Modello module.exports = attributi: userId: 'INT', nome utente: 'STRING', messaggio: 'STRING';
Per il messaggi modello, iniziamo con il id dell'utente a cui questo messaggio appartiene, a nome utente quindi non dovremo interrogarlo separatamente, e quindi il reale Messaggio.
Ora inseriamo il modello dell'utente:
// Users Model module.exports = attributes: username: 'STRING', password: 'STRING';
E questo è tutto, abbiamo solo il nome utente e parola d'ordine attributi. Il prossimo passo è creare le nostre funzioni di percorso all'interno del MainController.
Quindi apri il MainController, che può essere trovato a "api> controller> MainController.js"Cominciamo creando una funzione per ognuno dei percorsi che abbiamo definito sopra:
var MainController = index: function (req, res) , signup: function (req, res) , login: function (req, res) , chat: function (req, res) ; module.exports = MainController;
Se hai familiarità con Express, allora sarai felice di vedere che queste funzioni sono le funzioni di instradamento Express standard. Ricevono due variabili, req per la richiesta HTTP e res per creare la risposta.
Seguendo il pattern MVC, Sails offre una funzione per il rendering di viste. La home page non ha bisogno di nulla di speciale, quindi rendiamo semplicemente la visualizzazione.
index: function (req, res) res.view (); ,
Le vele sono più orientate alla convenzione rispetto alla configurazione, quindi quando chiami res.view (); Sails cercherà un file di visualizzazione (con a .ejs estensione per impostazione predefinita) utilizzando il seguente modello: 'visualizzazioni> controllerName> methodName.ejs'. Quindi per questa chiamata, cercherà "visualizzazioni> main> index.ejs'. Vale anche la pena notare che queste viste contengono solo parti specifiche della pagina della vista. Se dai un'occhiata a 'visualizzazioni> layout.ejs', vedrai una chiamata nel mezzo per <%- body %>, questo è dove verrà inserito il file di visualizzazione. Di default usa questo 'layout.ejs'file, ma puoi usare altri file di layout semplicemente passando il nome del layout nel file res.view () funzione, sotto la proprietà chiamata 'layout'. Per esempio: 'res.view (layout: "other.ejs");'.
Utilizzerò il file di layout predefinito con una piccola modifica, aggiungerò jQuery, Backbone e Underscore. Quindi nellayout.ejs'file subito prima della chiusura tag, aggiungi le seguenti linee:
Con quello sul posto siamo ora pronti a creare la home page.
Creiamo una nuova cartella all'interno del visualizzazioni cartella denominata principale, e dentro il nostro nuovo principale cartella, creeremo un nuovo file chiamato 'index.ejs'.
All'interno del file creiamo solo un modulo di accesso e registrazione:
Codice Chat
Accesso
Iscriviti
Abbastanza semplice, solo l'essenziale.
Quindi è necessario aggiungere un piccolo JS per ottenere questa comunicazione con il server. Ora questo non sarà specifico per Sails, invieremo una richiesta AJAX tramite jQuery al server Sails.
Questo codice può essere incluso nella pagina stessa o caricato tramite un file JS separato. Per comodità, lo metto in fondo alla stessa pagina:
Questo è tutto solo JS e jQuery standard, stiamo ascoltando l'evento click sul pulsante login, assicurandoci che i campi username e password siano compilati e postando i dati all '/accesso' itinerario. Se l'accesso ha esito positivo, reindirizziamo l'utente alla pagina di chat, altrimenti visualizzeremo l'errore restituito dal server.
Quindi, creiamo la stessa cosa per l'area di registrazione:
$ ("# signupButton"). click (function () var username = $ ("# signupName"). val (); var password = $ ("# signupPassword"). val (); var confirmPassword = $ (" #signupConfirmPassword "). val (); if (username e& password) if (password === confirmPassword) $ .post ('/ signup', username: username, password: password, function () window. location = "/ chat";) .fail (function (res) alert ("Errore:" + res.getResponseHeader ("error"));); else alert ("Le password non corrispondono") ; else alert ("Sono richiesti un nome utente e una password");); Questo codice è quasi identico, tant'è che probabilmente puoi semplicemente astrarre l'intera parte Ajax nella sua funzione, ma per questo tutorial va bene.
Ora dobbiamo tornare al nostro 'MainController'e gestire questi due percorsi, ma prima di farlo, voglio installare un modulo nodo. Avremo bisogno di hash la password, come sono le password in chiaro non una buona cosa, nemmeno per la dimostrazione! Ho trovato un bel modulo chiamato "password-hash" di David Wood che funzionerà bene.
Per installarlo, vai alla radice della tua app Sails, dal tuo terminale e digita: npm installa password-hash.
Una volta installato, apriamo il MainController e implementare le due rotte necessarie. Iniziamo con Iscriviti:
registrazione: function (req, res) var username = req.param ("username"); var password = req.param ("password"); Users.findByUsername (username) .done (function (err, usr) if (err) res.send (500, error: "Errore DB"); else if (usr) res.send (400, errore: "Nome utente già acquisito"); else var hasher = require ("password-hash"); password = hasher.generate (password); Users.create (nome utente: nome utente, password: password). done (funzione (errore, utente) if (errore) res.send (500, errore: "Errore DB"); else req.session.user = utente; res.send (utente); );); È un po 'prolisso, ma tutto quello che stiamo facendo qui è leggere il nome utente e la password dalla richiesta POST e accertarsi che il nome utente non sia già stato preso. Puoi vedere che sto usando anche la password che abbiamo appena installato, è semplicissimo da usare, basta passare la password nel metodo di generazione e lo cancellerà usando un sale casuale.
Vale anche la pena ricordare che, in ogni possibile luogo in cui potremmo incorrere in un errore o problema, stiamo rinviando un codice di errore HTTP e restituendo un messaggio tramite un'intestazione personalizzata denominata 'errore'che, se ricordi, stiamo visualizzando un messaggio di avviso nella pagina dell'indice.
Un altro punto degno di nota, è il fatto che stiamo usando una funzione 'magica' chiamata 'findByUsername', questo è reso possibile perché abbiamo un nome utente colonna all'interno del nostro modello di utenti.
Infine, in basso puoi vedere se tutto è andato bene, stiamo memorizzando l'utente in una variabile di sessione e restituendolo con un codice di stato predefinito di 200, che dirà a jQuery che la richiesta AJAX è andata a buon fine.
Quindi, scriviamo la funzione di login:
login: function (req, res) var username = req.param ("username"); var password = req.param ("password"); Users.findByUsername (username) .done (function (err, usr) if (err) res.send (500, error: "Errore DB"); else if (usr) var hasher = require ( "password-hash"); if (hasher.verify (password, usr.password)) req.session.user = usr; res.send (usr); else res.send (400, error: "errato Password "); else res.send (404, errore:" Utente non trovato ");); Di nuovo, questo è molto simile al precedente Iscriviti funzione, stiamo cercando un utente con lo stesso nome utente che è stato pubblicato dal modulo e se ne trova uno, controlliamo se la password corrisponde all'utilizzo dell'herher verificare metodo. La ragione per cui non possiamo semplicemente cancellare la password e passarla nei modelli trova la funzione è perché hasher usa un salt casuale, quindi se abbiamo cancellato la password di nuovo sarebbe uguale a qualcos'altro.
Il resto del codice è lo stesso; se tutto si verifica, memorizziamo l'utente in una sessione e lo restituiamo, altrimenti restituiamo un messaggio di errore.
Il sistema di accesso è ora completo e siamo finalmente in grado di passare alla creazione della funzione di chat.
Dato che utilizzeremo Backbone per ottenere i messaggi, la funzione di rotta effettiva sarà molto semplice. Ecco la funzione di chat completa:
chat: function (req, res) if (req.session.user) res.view (username: req.session.user.username); else res.redirect ('/'); Iniziamo controllando se l'utente è loggato o meno, se questo esegue il check out, quindi caricherà la vista, passandogli il nome utente che era nella sessione, altrimenti ci limitiamo a reindirizzare alla home page.
Ora creiamo una nuova vista denominata 'chat.ejs'all'interno del principale cartella. Aprilo e creiamo un semplice modulo per inviare nuovi messaggi e a div contenitore per la visualizzazione di tutti loro.
benvenuto <%= username %>
Quindi, per questa visione, abbiamo semplicemente usato un codice HTML piuttosto standard. L'unica cosa che potrebbe richiedere qualche spiegazione è il <%= username %> codice, questo stile di codifica non è specifico di Sails, è in realtà la sintassi di EJS. Questa sintassi è molto simile ai tag brevi di PHP. <% è l'equivalente di in PHP e <%= equivale a . Il primo frammento di EJS consente di integrare il codice JS standard sulla pagina, mentre il secondo stampa il codice all'interno. Qui stiamo solo stampando il nome utente che abbiamo passato dal controller.
Il resto della nostra funzione di chat sarà tutto JavaScript. Per iniziare, diamo un'occhiata a come si scriverà la funzionalità di chat utilizzando Backbone standard, quindi vedremo come sfruttare le socket Web.
In fondo alla pagina, aggiungi il seguente JS:
Poiché Sails crea automaticamente un'API che Backbone comprende in modo nativo, non è necessario scrivere alcun codice server aggiuntivo, non è molto più semplice. Questo è quello di cui stavo parlando quando ho detto che Sails non è stato fatto per essere un 'framework'. Non cerca di farti usare la propria sintassi, è stato fatto per fare le cose e, come puoi vedere, offre.
Per provarlo, apri una finestra di terminale e vai alla cartella dell'app Sails, quindi digita "vele ascensore'per avviarlo. Di default verrà lanciato su http: // localhost: 1337. Ora basta registrarsi e pubblicare alcuni messaggi.
Puoi vedere i tuoi messaggi postati console.log la variabile dei messaggi o guardala all'interno della console del browser. Ora la prossima cosa che dovremmo implementare è una vista in modo che possiamo vedere i messaggi pubblicati nel browser.
_.templateSettings = interpolate: /\\(.+?)\\/g; var MessagesView = Backbone.View.extend (el: '#messagesContainer', initialize: function () this.collection.on ('add', this.render, this); this.render ();, template: _.modello(" Messaggio
"), render: function () this. $ el.html (" "); this.collection.each (function (msg) this. $ el.append (this.template (msg.toJSON ())); , this)); var mView = new MessagesView (collection: messages); Iniziamo definendo una vista, allegandola al div creato in precedenza, quindi aggiungiamo un gestore di eventi alla raccolta per ri-renderizzare il div ogni volta che un nuovo modello viene aggiunto alla collezione.
Puoi vedere in alto, ho dovuto cambiare le impostazioni di default del Underscore usando la sintassi EJS all'interno dei template, per usare invece la sintassi di Mustache. Questo perché la pagina è già un documento EJS, quindi verrà elaborata sul server e non in Underscore.
Nota: Non sono venuto con il Regex per questo, quel merito va agli stessi documenti di Underscore.
Infine, in basso puoi vedere che abbiamo creato una nuova istanza di questa vista, passandogli la variabile di raccolta.
Se tutto è andato bene, ora dovresti vedere i tuoi messaggi nel browser e dovrebbe aggiornarsi ogni volta che crei un nuovo post.
Ora potresti aver notato che non stiamo impostando il ID utente o il nome utente quando inviamo i post, e questo è per motivi di sicurezza.
Non vuoi mettere questo tipo di controllo sul lato client. Se tutto ciò che qualcuno deve fare è modificare una variabile JavaScript per controllare l'account di un altro utente, avrai un grosso problema.
Quindi, come dovresti gestirlo? Bene, con le politiche, ovviamente.
I criteri sono fondamentalmente middleware, che vengono eseguiti prima della richiesta Web effettiva, in cui è possibile interrompere, modificare o persino reindirizzare la richiesta, in base alle esigenze.
Per questa app, creiamo una politica per i nostri messaggi. Le policy vengono applicate ai controller, in modo che possano essere eseguiti anche su pagine normali, ma per questo tutorial limitiamoci a utilizzarne uno per il nostro messaggi Modello.
Crea un file chiamato "MessagesPolicy.js" all'interno del "api> politiche'cartella, e inserisci quanto segue:
module.exports = function (req, res, next) if (req.session.user) var action = req.param ('action'); if (action == "create") req.body.userId = req.session.user.id; req.body.username = req.session.user.username; Il prossimo(); else res.send ("Devi essere connesso", 403); ; Allora, cosa sta succedendo qui? Puoi vedere questa funzione come una normale funzione di rotta, ma la differenza è il terzo parametro, che chiamerà il middleware successivo nello stack. Se sei nuovo all'idea del middleware, puoi pensare ad esso come una bambola nidificante russa. Ogni livello riceve la richiesta, insieme alle variabili di risposta e possono modificarle come meglio credono. Se superano tutti i requisiti, il livello può passare più in là, fino a raggiungere il centro, che è la funzione di percorso.
Quindi eccoci qui, controllando se l'utente è loggato, se l'utente non lo è, viene visualizzato un errore 403 e la richiesta termina qui. In caso contrario, (ovvero l'utente ha effettuato l'accesso) chiamiamo Il prossimo(); per trasmetterlo. Nel mezzo del codice sopra, è dove iniettiamo alcune variabili post. Lo applichiamo a tutte le chiamate sul controller "messaggi" (in pratica l'API), quindi otteniamo l'azione e controlliamo se questa richiesta sta tentando di creare un nuovo messaggio, nel qual caso aggiungiamo i campi post per l'utente id e nome utente.
Quindi, apri il policies.js file che si trova nella cartella config e aggiungere il criterio appena creato. Quindi il tuo file dovrebbe assomigliare a questo:
module.exports.policies = '*': true, 'messages': 'MessagesPolicy';
Con questo inserimento, dovremo eliminare tutti i vecchi record, poiché non hanno queste nuove informazioni. Quindi, chiudi il server di Sails (ctrl-c) e nello stesso tipo di finestra di terminale: rm -r .tmp rimuovere il database temporaneo dandoci una lista pulita.
Successivamente, aggiungiamo il nome utente ai post effettivi, quindi nel "chat.ejs" cambia il modello in:
modello: _.template ("nome utente: Messaggio
"), Riavvia il server Sails (usando ancora vele ascensore) e iscriviti a un altro nuovo utente per testarlo. Se tutto funziona correttamente, dovresti essere in grado di aggiungere messaggi e vedere il tuo nome nel post.
A questo punto abbiamo una configurazione piuttosto buona, recuperiamo il post automaticamente usando Backbone e l'API, in più abbiamo una certa sicurezza di base. Il problema è che non si aggiornerà quando altre persone pubblicano messaggi. Ora puoi risolvere questo problema creando un intervallo JavaScript e il polling per gli aggiornamenti, ma possiamo fare di meglio.
Ho accennato in precedenza che Sails sfrutta le capacità bidirezionali dei websocket per pubblicare aggiornamenti sui dati sottoscritti. Usando questi aggiornamenti, possiamo ascoltare nuove aggiunte alla tabella dei messaggi e aggiornare la collezione di conseguenza.
Quindi nel chat.ejs file, creiamo un nuovo tipo di raccolta; a SailsCollection:
var SailsCollection = Backbone.Collection.extend (sailsCollection: "", socket: null, sync: function (metodo, modello, opzioni) var where = ; if (options.where) where = where: options. dove if (typeof this.sailsCollection === "string" && this.sailsCollection! == "") this.socket = io.connect (); this.socket.on ("connect", _.bind ( function () this.socket.request ("/" + this.sailsCollection, dove, _.bind (function (users) this.set (users);, this)); this.socket.on ("message ", _.bind (function (msg) var m = msg.uri.split (" / "). pop (); if (m ===" create ") this.add (msg.data); altrimenti if (m === "update") this.get (msg.data.id) .set (msg.data); else if (m === "destroy") this.remove (this.get (msg.data.id));, this));, this)); else console.log ("Errore: impossibile recuperare i modelli perché la proprietà 'sailsCollection' non è impostata sulla raccolta"); ); Ora potrebbe essere lungo, ma in realtà è molto semplice, percorriamolo. Iniziamo aggiungendo due nuove proprietà all'oggetto Collection, una per contenere il nome del modello di Sails e una per contenere il socket web. Successivamente, modifichiamo il sincronizzare funzione, se hai familiarità con Backbone, allora saprai che questa è la funzione che si interfaccia con il server quando chiami cose come andare a prendere. Di solito, fa fuoco sulle richieste Ajax, ma lo personalizziamo per le comunicazioni socket.
Ora, non stiamo usando la maggior parte delle funzionalità di sincronizzare funzioni, principalmente perché non abbiamo aggiunto la possibilità per gli utenti di aggiornare o eliminare i messaggi, ma per essere completi, li includerò all'interno della definizione della funzione.
Diamo un'occhiata alla prima parte del sincronizzare funzione:
var dove = ; if (options.where) where = where: options.where
Questo codice prima controlla se c'è ne 'dove'sono state inviate le clausole, questo ti permetterebbe di fare cose come: messages.fetch (where: id: 4); per recuperare solo le righe in cui l'id è uguale a quattro.
Dopodiché, avremo un codice che garantisce che l 'sailsCollection'la proprietà è stata impostata, altrimenti registriamo un messaggio di errore. Successivamente, creiamo un nuovo socket e ci connettiamo al server, ascoltando la connessione con il on ( 'connect') evento.
Una volta connesso, chiediamo l'indice dell 'sailsCollection'specificato per inserire l'elenco corrente di modelli. Quando riceve i dati, usiamo la collezione impostato funzione per impostare inizialmente i modelli.
Bene, ora così lontano, abbiamo l'equivalente dello standard andare a prendere comando. Il prossimo blocco di codice è dove avvengono le notifiche push:
this.socket.on ("message", _.bind (function (msg) var m = msg.uri.split ("/"). pop (); if (m === "create") this. add (msg.data); else if (m === "update") this.get (msg.data.id) .set (msg.data); else if (m === "destroy") this.remove (this.get (msg.data.id));, this)); Ora l'azione che viene eseguita (se stiamo creando, aggiornando o distruggendo un messaggio) può essere trovata all'interno del reale msg, che è quindi all'interno del uri. Per ottenere l'azione, dividiamo l'URI sulle barre ('/') e prendiamo solo l'ultimo segmento usando il pop funzione. Allora proviamo ad abbinarlo alle tre possibili azioni di creare, aggiornare, o distruggere.
Il resto è Backbone standard, aggiungiamo, modificiamo o rimuoviamo il modello specificato. Con la nostra nuova classe quasi completa, tutto ciò che resta da fare è cambiare la corrente MessageCollection. Invece di estendere la collezione Backbone, ha bisogno di estendere la nostra nuova collezione, in questo modo:
var MessageCollection = SailsCollection.extend (sailsCollection: 'messages', model: MessageModel);
Oltre ad estendere la nostra nuova collezione, faremo un'altra modifica in modo che, invece di impostare la proprietà URL, ora impostiamo la proprietà sailsCollection. E questo è tutto ciò che c'è da fare. Apri l'applicazione in due diversi browser (ad esempio Chrome e Safari) e registrati due utenti separati. Dovresti vedere che i messaggi inviati da uno dei due browser vengono immediatamente mostrati sull'altro, nessun polling, nessun problema.
Le vele sono una ventata di aria fresca, all'interno di una confusione di strutture. Controlla il proprio e
