Metodi per salvare i dati del modello Backbone.js?

Question

Sono più interessato allo sviluppo front-end e recentemente ho iniziato a esplorare Backbone.js nella mia app. Voglio mantenere i dati del modello sul server.

Potrebbe spiegarmi il modo diverso di salvare i dati del modello (utilizzando il formato JSON). Sto usando Java sul lato server. Inoltre ho visto principalmente REST utilizzato per salvare i dati. Dato che sono più interessato allo sviluppo di front end, non sono a conoscenza di REST e altre cose simili.

Sarebbe bello se qualcuno potesse spiegarmi il processo con un semplice esempio.

Answer 1

Fondamentalmente, i modelli hanno una proprietà denominata attributi che rappresentano i vari valori che un determinato modello può avere. Backbone utilizza oggetti JSON come un modo semplice per popolare questi valori utilizzando vari metodi che prendono oggetti JSON. Esempio:

Donuts = Backbone.Model.extend({ 
    defaults: { 
     flavor: 'Boston Cream', // Some string 
     price: '0.50' // Dollars 
    } 
}); 

Per popolare il modello ci sono alcuni modi per farlo. Ad esempio, è possibile impostare l'istanza del modello passando un metodo JSON OPPURE utilizzare il metodo 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()); 
// {'flavor':'lemon', 'price':'0.75'} 
console.log(mySecondHelping.toJSON()); 
// {'flavor':'plain', 'price':'0.25'} 

Quindi questo ci porta al salvataggio di modelli e alla loro permanenza su un server. C'è un gran numero di dettagli su "What is REST/RESTful?" Ed è un po 'difficile spiegare tutto questo in un breve scambio qui. In particolare per quanto riguarda il salvataggio di REST e Backbone, la cosa da tenere a mente è la semantica delle richieste HTTP e quello che stai facendo con i tuoi dati.

Probabilmente sei abituato a due tipi di richieste HTTP. OTTIENI E POST. In un ambiente RESTful, questi verbi hanno un significato speciale per usi specifici che Backbone assume. Quando si desidera ottenere una determinata risorsa dal server (ad esempio, modello di donut che ho salvato l'ultima volta, un post di blog, una specifica del computer) e tale risorsa esiste, si esegue una richiesta GET. Al contrario, quando si desidera creare una nuova risorsa si utilizza 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 esempio, modificare il sapore della ciambella al limone nella ciambella del limon, ecc.) Si utilizza una richiesta PUT. Quando si desidera eliminare il modello dal server tutti insieme, si utilizza una richiesta DELETE.

Queste informazioni di base sono molto importanti perché con l'app RESTful, probabilmente si avrà una designazione URI che eseguirà l'attività appropriata in base al tipo di verbo di richiesta che si utilizza. Per esempio:

// The URI pattern 
http://localhost:8888/donut/:id 

// My URI call 
http://localhost:8888/donut/17 

Se faccio un arrivare a quel URI, si otterrebbe modello di ciambella con un ID di 17. Il: id dipende da come si sta salvando che lato server. Questo potrebbe essere solo l'ID della tua risorsa ciambella nella tabella del tuo database.

Se faccio un PUT a quell'URI con nuovi dati, lo aggiornerei, salvandoci sopra. E se CANCELLO a quell'URI, allora lo eliminerebbe dal mio sistema.

Con POST, poiché non è stata ancora creata una risorsa, non avrà un ID risorsa stabilito. Forse il target URI voglio creare risorse è semplicemente questo:

http://localhost:8888/donut 

No ID frammento nella URI. Tutti questi disegni URI dipendono da te e da come pensi alle tue risorse.Ma per quanto riguarda il progetto RESTful, la mia comprensione è che si desidera mantenere i verbi delle proprie azioni sulla richiesta HTTP e le risorse come nomi che rendono gli URI facili da leggere e compatibili con gli umani.

Sei ancora con me? :-)

Quindi torniamo a pensare a Backbone. Backbone è meraviglioso perché fa molto lavoro per te. Per salvare il nostro ciambella e secondHelping, abbiamo semplicemente facciamo:

myDonut.save(); 
mySecondHelping.save(); 

Backbone è intelligente. Se hai appena creato una risorsa ciambella, non avrà un ID dal server. Ha qualcosa chiamato cID che è quello 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 ottenuto il tuo modello dal server, probabilmente avrà un ID se tutto andava bene. In questo caso, quando si salva() Backbone presuppone che si desidera aggiornare il server e invierà un PUT. Per ottenere una risorsa specifica, devi utilizzare il metodo Backbone .fetch() e invia una richiesta GET. Quando chiamate .destroy() su un modello, invierà il DELETE.

Negli esempi precedenti, non ho mai detto esplicitamente a Backbone dove si trova l'URI. Facciamo ciò nel prossimo esempio.

thirdHelping = Backbone.Model.extend({ 
    url: 'donut' 
}); 
thirdHelping.set({id:15}); // Set the id attribute of model to 15 
thirdHelping.fetch(); // Backbone assumes this model exists on server as ID 15 

Backbone otterranno il thirdHelping a http://localhost:8888/donut/15 Sarà sufficiente aggiungere/gambo ciambella al tuo principale del sito.

Se sei ANCORA con me, bene. Credo. A meno che tu non sia confuso. Ma ci 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 devi condividere.

Il server deve comprendere la differenza tra una richiesta GET, POST, PUT e DELETE. Come avete visto negli esempi sopra, GET, PUT e DELETE potrebbero puntare tutti allo stesso URI http://localhost:8888/donut/07 A meno che il vostro server non possa distinguere tra queste richieste HTTP, sarà molto confuso su cosa fare con quella risorsa.

Questo è quando inizi a pensare al tuo codice finale server RESTful. Ad alcune persone piace Ruby, ad alcune persone piace .net, mi piace PHP. In particolare mi piace il micro-framework PHP SLIM. SLIM PHP è un micro-framework che ha un set di strumenti molto elegante e semplice per gestire le attività RESTful. È possibile definire i 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 quadri più grandi come Cake e CodeIgniter facciano cose simili anche se mi piace il minimo. Ho detto che mi piace Slim? ;-)

Questo è ciò che il codice estratto sul server potrebbe apparire (vale a dire in particolare per quanto riguarda i percorsi.)

$app->get('/donut/:id', function($id) use ($app) { 
    // get donut model with id of $id from database. 
    $donut = ... 

    // Looks something like this maybe: 
    // $donut = array('id'=>7, 'flavor'=>'chocolate', 'price'=>'1.00') 

    $response = $app->response(); 
    $response['Content-Type'] = 'application/json'; 
    $response->body(json_encode($donut)); 
}); 

Qui è importante notare che Backbone si aspetta un oggetto JSON. Se possibile, il tuo server deve sempre designare il tipo di contenuto come "application/json" e codificarlo in formato json. Quindi, quando Backbone riceve l'oggetto JSON, sa come popolare il modello che lo ha richiesto.

Con SLIM PHP, i percorsi funzionano in modo simile a quanto sopra.

$app->post('/donut', function() use ($app) { 
    // Code to create new donut 
    // Returns a full donut resource with ID 
}); 
$app->put('/donut/:id', function($id) use ($app) { 
    // Code to update donut with id, $id 
    $response = $app->response(); 
    $response->status(200); // OK! 
    // But you can send back other status like 400 which can trigger an error callback. 
}); 
$app->delete('/donut/:id', function($id) use ($app) { 
    // Code to delete donut with id, $id 
    // Bye bye resource 
}); 

Quindi hai quasi fatto il viaggio di andata e ritorno! Vai a prendere una bibita. Mi piace la dieta Mountain Dew. Prendi uno anche per me.

Una volta che il 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), quindi i dati tornano a Backbone per l'elaborazione finale.

Con i metodi save(), fetch(), ecc., È possibile aggiungere callback facoltativi in ​​caso di esito positivo ed errore. Ecco un esempio di come ho impostato questa torta particolare:

Cake = Backbone.Model.extend({ 
    defaults: { 
     type: 'plain', 
     nuts: false 
    }, 
    url: 'cake' 
}); 

myCake = new Cake(); 
myCake.toJSON() // Shows us that it is a plain cake without nuts 

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'); 
    } 
}); 

// ASSUME my server is set up to respond with a status(403) 
// ASSUME my server responds with string payload saying 'we don't like nuts' 

Ci sono un paio di cose diverse su questo esempio. Vedrai che per la mia torta, invece di set(), gli attributi prima di salvare, ho semplicemente passato i nuovi attributi alla mia chiamata di salvataggio. Backbone è un bel ninja nel prendere dati JSON dappertutto e gestirli come un campione. Quindi voglio salvare la mia torta con noci di cocco e noci. (Si tratta di 2 dadi?) Comunque, ho passato in due oggetti al mio salvataggio. Gli attributi oggetto JSON E alcune opzioni. Il primo, {wait: true} significa che non aggiorno il mio modello lato client fino a quando il trip del server non ha avuto successo. La chiamata di successo si verificherà quando il server restituisce una risposta. Tuttavia, poiché questo esempio genera un errore (uno stato diverso da 200 indica Backbone per utilizzare il callback di errore) otteniamo una rappresentazione del modello senza le modifiche. Dovrebbe essere ancora semplice e senza noccioline. Abbiamo anche accesso all'oggetto errore che il server ha restituito. Abbiamo rinviato una stringa ma potrebbe essere un oggetto di errore JSON con più proprietà. Questo si trova nell'attributo error.responseText. Sì, "non ci piacciono le noci".

Congratulazioni. Hai effettuato il tuo primo viaggio completo di andata e ritorno dalla configurazione di un modello, salvandolo dal lato server e viceversa. Spero che questa risposta epica ti dia un'idea di come tutto questo si unisce. Ci sono, naturalmente, molti dettagli che sto passando oltre, ma le idee di base di Backbone save, verbi RESTful, azioni lato server, Response sono qui. Continua a leggere la documentazione di Backbone (che è super facile da leggere rispetto ad altri documenti), ma tieni a mente che questo richiede tempo per riprendersi. Più ti attieni, più fluente sarai. Ogni giorno imparo qualcosa di nuovo con Backbone e diventa davvero divertente quando inizi a fare salti e vedi crescere la tua fluidità in questo contesto. :-)

Felice codifica!

EDIT: risorse che possono essere utili:

altre risposte simili su SO: How to generate model IDs with Backbone

a riposo: http://rest.elkstein.org/ http://www.infoq.com/articles/rest-introduction http://www.recessframework.org/page/towards-restful-php-5-basic-tips