Façons de sauvegarder les données de modèle Backbone.js?
Je suis plus dans le développement frontal et ai récemment commencé à explorer Backbone.js dans mon application. Je veux conserver les données du modèle sur le serveur.
Pourriez-vous s'il vous plaît m'expliquer les différentes façons de sauvegarder les données du modèle (en utilisant le format json). J'utilise Java côté serveur. De plus, j'ai principalement vu REST utilisé pour sauvegarder des données. Comme je suis plus en développement, je ne suis pas au courant de REST et d'autres choses similaires.
Ce serait formidable si quelqu'un pouvait m'expliquer le processus à l'aide d'un exemple simple.
Fondamentalement, les modèles ont une propriété appelée attributs qui sont les différentes valeurs qu'un modèle peut avoir. Backbone utilise les objets JSON comme moyen simple de renseigner ces valeurs à l'aide de diverses méthodes utilisant des objets JSON. Exemple:
Donuts = Backbone.Model.extend({
defaults: {
flavor: 'Boston Cream', // Some string
price: '0.50' // Dollars
}
});
Pour renseigner le modèle, il existe plusieurs façons de le faire. Par exemple, vous pouvez configurer votre instance de modèle en transmettant une méthode JSON OR) appelée set (), qui prend un objet JSON d'attributs.
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'}
Cela nous amène donc à sauvegarder des modèles et à les conserver sur un serveur. Il y a une foule de détails concernant "Qu'est-ce que REST/RESTful?" Et il est un peu difficile d'expliquer tout cela dans un bref texte de présentation ici. En particulier en ce qui concerne REST et l’économie de Backbone, ce qu’il faut retenir, c’est la sémantique des requêtes HTTP et ce que vous faites avec vos données.
Vous êtes probablement habitué à deux types de requêtes HTTP. GET et POST. Dans un environnement RESTful, ces verbes ont une signification particulière pour des utilisations spécifiques supposées par Backbone. Lorsque vous souhaitez obtenir une certaine ressource du serveur (par exemple, le modèle de donut que j'ai enregistré la dernière fois, une entrée de blog, une spécification d'ordinateur) et que cette ressource existe, vous effectuez une requête GET. Inversement, lorsque vous souhaitez créer une nouvelle ressource, vous utilisez POST.
Avant d’entrer dans Backbone, je n’avais même jamais touché aux deux méthodes de requête HTTP suivantes. PUT et DELETE. Ces deux verbes ont également une signification spécifique pour Backbone. Lorsque vous souhaitez mettre à jour une ressource (par exemple, changer la saveur du beignet au citron en beignet au citron, etc.), vous utilisez une requête PUT. Lorsque vous souhaitez supprimer ce modèle du serveur dans son ensemble, vous utilisez une demande DELETE.
Ces bases sont très importantes car avec votre application RESTful, vous aurez probablement une désignation d'URI qui effectuera la tâche appropriée en fonction du type de verbe de requête que vous utilisez. Par exemple:
// The URI pattern
http://localhost:8888/donut/:id
// My URI call
http://localhost:8888/donut/17
Si je fais un GET à cet URI, il obtiendra un modèle de donut avec un ID de 17. L'identifiant: dépend de la façon dont vous enregistrez le côté serveur. Cela pourrait simplement être l'ID de votre ressource en anneau dans votre table de base de données.
Si je fais un PUT à cet URI avec de nouvelles données, je le mettrais à jour, ce qui serait économisé. Et si je supprime cet URI, il le purgera de mon système.
Avec POST, étant donné que vous n’avez pas encore créé de ressource, elle n’a pas d’ID de ressource établi. Peut-être que la cible de l'URI pour laquelle je veux créer des ressources est simplement la suivante:
http://localhost:8888/donut
Aucun fragment d'identification dans l'URI. Toutes ces conceptions d'URI dépendent de vous et de la façon dont vous envisagez vos ressources. Mais en ce qui concerne la conception RESTful, je crois comprendre que vous souhaitez conserver les verbes de vos actions dans votre requête HTTP et les ressources sous la forme de noms qui rendent les adresses URI faciles à lire et conviviales.
Es-tu encore avec moi? :-)
Revenons donc à la réflexion sur Backbone. Backbone est merveilleux car il fait beaucoup de travail pour vous. Pour sauver notre beigne et secondHelping, nous faisons simplement ceci:
myDonut.save();
mySecondHelping.save();
Backbone est intelligent. Si vous venez de créer une ressource en anneau, elle n’aura pas d’ID du serveur. Il a quelque chose qui s'appelle un cID qui est ce que Backbone utilise en interne mais comme il n’a pas d’identifiant officiel, il sait qu’il devrait créer une nouvelle ressource et envoie une demande POST. Si vous avez votre modèle depuis le serveur, il aura probablement un identifiant si tout était correct. Dans ce cas, lorsque vous enregistrez () Backbone suppose que vous souhaitez mettre à jour le serveur et envoie un PUT. Pour obtenir une ressource spécifique, vous devez utilisez la méthode Backbone .fetch () et il envoie une demande GET. Lorsque vous appelez .destroy () sur un modèle, il envoie le message DELETE.
Dans les exemples précédents, je n’ai jamais dit explicitement à Backbone où se trouvait l’URI. Faisons cela dans l'exemple suivant.
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 aura le troisièmeAide à http://localhost:8888/donut/15 Il va simplement ajouter/tige de beigne à la racine de votre site.
Si vous êtes toujours avec moi, tant mieux. Je pense. Sauf si vous êtes confus. Mais nous marcherons quand même. La deuxième partie de ceci est le côté serveur. Nous avons parlé de différents verbes de HTTP et des significations sémantiques derrière ces verbes. Significations que vous, réseau principal, et votre serveur devez partager.
Votre serveur doit comprendre la différence entre une demande GET, POST, PUT et DELETE. Comme vous l'avez vu dans les exemples ci-dessus, GET, PUT et DELETE peuvent tous pointer vers le même URI http://localhost:8888/donut/07 À moins que votre serveur ne puisse différencier ces requêtes HTTP, il sera très confus de savoir quoi faire avec cette ressource.
C'est à ce moment que vous commencez à penser au code de fin de votre serveur RESTful. Certaines personnes aiment Ruby, certaines personnes aiment .net, j'aime PHP. J'aime particulièrement SLIM PHP micro-framework. SLIM PHP est un micro-framework qui dispose d'un ensemble d'outils très élégant et simple permettant de gérer des activités RESTful. Vous peut définir des routes (URI) comme dans les exemples ci-dessus et selon que l'appel est GET, POST, PUT ou DELETE, il exécutera le code correct. Il existe d'autres solutions similaires à SLIM comme Recess, Tonic. Je crois que des cadres plus grands comme Cake et CodeIgniter font aussi des choses similaires bien que j'aime peu. Ai-je dit que j'aimais Slim? ;-)
C’est ce à quoi pourrait ressembler un extrait de code sur le serveur (c’est-à-dire spécifiquement en ce qui concerne les routes).
$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));
});
Il est important de noter ici que Backbone attend un objet JSON. Demandez toujours à votre serveur de désigner le type de contenu comme "application/json" et de l'encoder au format json si vous le pouvez. Ensuite, lorsque Backbone reçoit l'objet JSON, il sait comment renseigner le modèle qui l'a demandé.
Avec SLIM PHP, les itinéraires fonctionnent de manière assez similaire à celle décrite ci-dessus.
$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
});
Donc, vous avez presque fait le tour complet! Va chercher un soda. J'aime Diet Mountain Dew. Obtenez un pour moi aussi.
Une fois que votre serveur a traité une demande, fait quelque chose avec la base de données et la ressource, prépare une réponse (qu'il s'agisse d'un simple numéro d'état http ou d'une ressource JSON complète), puis les données sont renvoyées dans le Backbone pour le traitement final.
Avec vos méthodes save (), fetch (), etc., vous pouvez ajouter des rappels facultatifs en cas de succès ou d'erreur. Voici un exemple de la façon dont j'ai préparé ce gâteau:
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'
Il y a deux choses différentes à propos de cet exemple. Vous verrez que pour mon gâteau, au lieu de définir () les attributs avant la sauvegarde, j'ai simplement passé les nouveaux attributs à mon appel de sauvegarde. Backbone est assez ninja pour prendre des données JSON un peu partout et les manipuler comme un champion. Donc, je veux sauver mon gâteau avec des noix de coco et des noix. (Est-ce que c'est 2 noix?) Quoi qu'il en soit, j'ai passé deux objets à ma sauvegarde. Les attributs objet JSON ET quelques options. Le premier, {wait: true} signifie que vous ne mettez pas à jour mon modèle côté client tant que le déclenchement côté serveur est réussi. Le rappel réussi aura lieu lorsque le serveur retournera une réponse. Cependant, étant donné que cet exemple entraîne une erreur (un statut autre que 200 indique à Backbone d’utiliser le rappel d’erreur), nous obtenons une représentation du modèle sans les modifications. Il devrait toujours être simple et sans noix. Nous avons également accès à l'objet d'erreur que le serveur a renvoyé. Nous avons renvoyé une chaîne, mais il pourrait s'agir d'un objet d'erreur JSON avec davantage de propriétés. Cela se trouve dans l'attribut error.responseText. Ouais, on n'aime pas les noix.
Toutes nos félicitations. Vous avez effectué votre premier voyage aller-retour complet en configurant un modèle, en l’enregistrant côté serveur, et vice-versa. J'espère que cette réponse épique vous donne un IDEA de comment tout cela se réunit. Il y a bien sûr beaucoup de détails que je croise, mais les idées de base de Backbone save, les verbes RESTful Les actions côté serveur, les réponses sont là, continuez à parcourir la documentation de Backbone (qui est très facile à lire comparé à d’autres documents), mais gardez bien à l’esprit que cela prend du temps à comprendre. J'apprends chaque jour quelque chose de nouveau avec Backbone et cela devient vraiment amusant lorsque vous commencez à faire des bonds et à voir votre aisance grandir dans ce cadre. :-)
Bon codage!
EDIT: Ressources pouvant être utiles:
Autres réponses similaires sur SO: Comment générer des ID de modèle avec le backbone
Sur REST: http://rest.elkstein.org/http://www.infoq.com/articles/rest-introductionhttp: // www.recessframework.org/page/towards-restful-php-5-basic-tips