Fondamentalmente i modelli hanno una proprietà chiamata attributi che sono i vari valori che un certo modello può avere. Backbone utilizza oggetti JSON come un modo semplice per popolare questi valori utilizzando vari metodi che accettano oggetti JSON. Esempio:
Donuts = Backbone.Model.extend({
defaults: {
flavor: 'Boston Cream',
price: '0.50'
}
});
Per popolare il modello ci sono alcuni modi per farlo. Ad esempio, puoi configurare l'istanza del tuo modello passando un metodo JSON OR use chiamato set () che accetta un oggetto JSON di attributi.
myDonut = new Donut({'flavor':'lemon', 'price':'0.75'});
mySecondHelping = new Donut();
mySecondHelping.set({'flavor':'plain', 'price':'0.25'});
console.log(myDonut.toJSON());
console.log(mySecondHelping.toJSON());
Quindi questo ci porta al salvataggio dei modelli e alla loro persistenza su un server. C'è tutta una serie di dettagli riguardanti "Che cos'è REST / RESTful?" Ed è un po 'difficile spiegare tutto questo in un breve riassunto qui. In particolare per quanto riguarda il salvataggio REST e Backbone, la cosa su cui riflettere è la semantica delle richieste HTTP e quello che stai facendo con i tuoi dati.
Probabilmente sei abituato a due tipi di richieste HTTP. GET e POST. In un ambiente RESTful, questi verbi hanno un significato speciale per usi specifici che Backbone assume. Quando vuoi ottenere una certa risorsa dal server, (es. Modello di ciambella che ho salvato l'ultima volta, un post di blog, una specifica del computer) e quella risorsa esiste, fai una richiesta GET. Al contrario, quando vuoi creare una nuova risorsa usi POST.
Prima di entrare in Backbone, non ho mai nemmeno toccato i seguenti due metodi di richiesta HTTP. PUT e DELETE. Questi due verbi hanno anche un significato specifico per Backbone. Quando si desidera aggiornare una risorsa, (ad es. Cambiare il sapore della ciambella al limone in ciambella al limone, ecc.) Si utilizza una richiesta PUT. Quando si desidera eliminare del tutto quel modello dal server, si utilizza una richiesta DELETE.
Queste nozioni di base sono molto importanti perché con la tua app RESTful, probabilmente avrai una designazione URI che eseguirà l'attività appropriata in base al tipo di verbo di richiesta che usi. Per esempio:
http:
http:
Se effettuo un GET su quell'URI, otterrei un modello ad anello con ID 17. L'id: id dipende da come lo stai salvando sul lato server. Questo potrebbe essere solo l'ID della tua risorsa ciambella nella tabella del database.
Se creo un PUT a quell'URI con nuovi dati, lo aggiornerei, salvandoci sopra. E se ELIMINO a quell'URI, lo eliminerebbe dal mio sistema.
Con POST, poiché non hai ancora creato una risorsa, non avrà un ID risorsa stabilito. Forse l'obiettivo URI che voglio creare risorse è semplicemente questo:
http:
Nessun frammento ID nell'URI. Tutti questi progetti URI dipendono da te e dal modo in cui pensi alle tue risorse. Ma per quanto riguarda il design RESTful, la mia comprensione è che vuoi mantenere i verbi delle tue azioni sulla tua richiesta HTTP e le risorse come nomi che rendono gli URI facili da leggere e facili da usare.
Sei ancora con me? :-)
Quindi torniamo a pensare a Backbone. Backbone è meraviglioso perché fa molto lavoro per te. Per salvare la nostra ciambella e il secondo aiuto, facciamo semplicemente questo:
myDonut.save();
mySecondHelping.save();
Backbone è intelligente. Se hai appena creato una risorsa ciambella, non avrà un ID dal server. Ha qualcosa chiamato cID che è ciò che Backbone usa internamente ma poiché non ha un ID ufficiale sa che dovrebbe creare una nuova risorsa e invia una richiesta POST. Se hai ricevuto il tuo modello dal server, probabilmente avrà un ID se tutto andava bene. In questo caso, quando save () Backbone presume che tu voglia aggiornare il server e invierà un PUT. Per ottenere una risorsa specifica, dovresti utilizzare il metodo Backbone .fetch () e invia una richiesta GET. Quando chiami .destroy () su un modello, invierà DELETE.
Negli esempi precedenti, non ho mai detto esplicitamente a Backbone dove si trova l'URI. Facciamolo nel prossimo esempio.
thirdHelping = Backbone.Model.extend({
url: 'donut'
});
thirdHelping.set({id:15});
thirdHelping.fetch();
Backbone OTTERRÀ il terzo aiuto in http://localhost:8888/donut/15esso aggiungerà semplicemente / donut stem alla radice del tuo sito.
Se sei ANCORA con me, bene. Credo. A meno che tu non sia confuso. Ma arrancheremo comunque. La seconda parte di questo è il lato SERVER. Abbiamo parlato di diversi verbi di HTTP e dei significati semantici dietro quei verbi. Significati che tu, Backbone, E il tuo server dovete condividere.
Il tuo server deve capire la differenza tra una richiesta GET, POST, PUT e DELETE. Come hai visto negli esempi sopra, GET, PUT e DELETE potrebbero puntare tutti allo stesso URI http://localhost:8888/donut/07A meno che il tuo server non possa distinguere tra queste richieste HTTP, sarà molto confuso su cosa fare con quella risorsa.
Questo è quando inizi a pensare al codice finale del tuo server RESTful. Ad alcune persone piace Ruby, ad alcune persone .net, mi piace PHP. In particolare mi piace il micro-framework SLIM PHP. SLIM PHP è un micro-framework che ha un set di strumenti molto elegante e semplice per gestire le attività RESTful. È possibile definire percorsi (URI) come negli esempi precedenti e, a seconda che la chiamata sia GET, POST, PUT o DELETE, eseguirà il codice corretto. Esistono altre soluzioni simili a SLIM come Recess, Tonic. Credo che anche framework più grandi come Cake e CodeIgniter facciano cose simili, anche se a me piace il minimal. Ho detto che mi piace Slim? ;-)
Questo è ciò che potrebbe apparire il codice estratto sul server (cioè in particolare per quanto riguarda le rotte).
$app->get('/donut/:id', function($id) use ($app) {
$donut = ...
$response = $app->response();
$response['Content-Type'] = 'application/json';
$response->body(json_encode($donut));
});
Qui è importante notare che Backbone si aspetta un oggetto JSON. Chiedi sempre al tuo server di designare il tipo di contenuto come "application / json" e di codificarlo in formato json, se possibile. Quindi, quando Backbone riceve l'oggetto JSON, sa come popolare il modello che lo ha richiesto.
Con SLIM PHP, le rotte funzionano in modo abbastanza simile a quanto sopra.
$app->post('/donut', function() use ($app) {
});
$app->put('/donut/:id', function($id) use ($app) {
$response = $app->response();
$response->status(200);
});
$app->delete('/donut/:id', function($id) use ($app) {
});
Quindi hai quasi fatto il giro completo! Vai a prendere una soda. Mi piace Diet Mountain Dew. Prendine uno anche per me.
Una volta che il tuo server elabora una richiesta, fa qualcosa con il database e la risorsa, prepara una risposta (che si tratti di un semplice numero di stato http o di una risorsa JSON completa), i dati tornano a Backbone per l'elaborazione finale.
Con i tuoi metodi save (), fetch (), ecc. Puoi aggiungere callback opzionali in caso di successo ed errore. Ecco un esempio di come ho preparato questa particolare torta:
Cake = Backbone.Model.extend({
defaults: {
type: 'plain',
nuts: false
},
url: 'cake'
});
myCake = new Cake();
myCake.toJSON()
myCake.save({type:'coconut', nuts:true}, {
wait:true,
success:function(model, response) {
console.log('Successfully saved!');
},
error: function(model, error) {
console.log(model.toJSON());
console.log('error.responseText');
}
});
Ci sono un paio di cose diverse su questo esempio che. Vedrai che per la mia torta, invece di impostare () gli attributi prima del salvataggio, ho semplicemente passato i nuovi attributi alla mia chiamata di salvataggio. Backbone è piuttosto ninja nel portare i dati JSON dappertutto e gestirli come un campione. Quindi voglio salvare la mia torta con noci di cocco e noci. (Sono 2 dadi?) Comunque, ho passato due oggetti al mio salvataggio. Gli attributi oggetto JSON E alcune opzioni. Il primo, {wait: true} significa non aggiornare il mio modello lato client fino a quando il viaggio lato server non ha esito positivo. La chiamata di successo si verificherà quando il server restituirà correttamente una risposta. Tuttavia, poiché questo esempio genera un errore (uno stato diverso da 200 indicherà a Backbone di utilizzare il callback dell'errore) otteniamo una rappresentazione del modello senza le modifiche. Dovrebbe essere ancora semplice e senza noci. Abbiamo anche accesso all'oggetto errore che il server ha restituito. Abbiamo restituito una stringa ma potrebbe essere un oggetto di errore JSON con più proprietà. Si trova nell'attributo error.responseText. Sì, "non ci piacciono le noci".
Congratulazioni. Hai fatto il tuo primo viaggio di andata e ritorno piuttosto completo dalla configurazione di un modello, salvandolo sul lato server e ritorno. Spero che questa risposta epica ti dia un'IDEA di come tutto questo si riunisce. Ci sono ovviamente molti dettagli che sto superando, ma le idee di base del salvataggio di Backbone, i verbi RESTful, le azioni lato server, la risposta sono qui. Continua a leggere la documentazione di Backbone (che è super facile da leggere rispetto ad altri documenti) ma tieni presente che questo richiede tempo per capire. Più lo fai, più sarai fluente. Imparo qualcosa di nuovo con Backbone ogni giorno e diventa davvero divertente quando inizi a fare salti e vedi crescere la tua fluidità in questo quadro. :-)
Buona programmazione!
EDIT: risorse che possono essere utili:
Altre risposte simili su SO:
Come generare ID modello con Backbone
Su REST:
http://rest.elkstein.org/
http://www.infoq.com/articles/rest-introduction
http://www.recessframework.org/page/towards-restful-php-5-basic- suggerimenti