Comment enregistrer les données du modèle Backbone.js?

Je suis plus dans le développement frontal et j'ai récemment commencé à explorer Backbone.js dans mon application. Je souhaite conserver les données du modèle sur le serveur.

Pourriez-vous s'il vous plaît m'expliquer les différentes manières d'enregistrer 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 enregistrer des données. Comme je suis plus dans le développement frontal, je ne suis pas au courant de REST et d'autres choses similaires.

Ce serait formidable si quelqu'un pouvait m'expliquer le processus avec un exemple simple.

Fondamentalement, les modèles ont une propriété appelée attributs qui sont les différentes valeurs qu'un certain modèle peut avoir. Backbone utilise des objets JSON comme un moyen simple de renseigner ces valeurs à l'aide de diverses méthodes qui prennent des objets JSON. Exemple:

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

Pour remplir le modèle, il existe plusieurs façons de le faire. Par exemple, vous pouvez configurer votre instance de modèle en passant un JSON OU utiliser une méthode 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 à enregistrer les modèles et à les conserver sur un serveur. Il y a toute une série de détails concernant "Qu'est-ce que REST / RESTful?" Et c'est un peu difficile d'expliquer tout cela dans un court texte de présentation ici. En ce qui concerne spécifiquement la sauvegarde REST et Backbone, la chose à retenir 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. OBTENIR et POSTER. Dans un environnement RESTful, ces verbes ont une signification particulière pour des utilisations spécifiques que Backbone assume. Lorsque vous voulez 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 faites une requête GET. Inversement, lorsque vous souhaitez créer une nouvelle ressource, vous utilisez POST.

Avant d'entrer dans Backbone, je n'ai 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 limon, etc.), vous utilisez une requête PUT. Lorsque vous souhaitez supprimer ce modèle du serveur tous 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 vers cet URI, il obtiendra un modèle de beignet avec un ID de 17. Le: id dépend de la façon dont vous l'enregistrez côté serveur. Cela peut simplement être l'ID de votre ressource en anneau dans votre table de base de données.

Si je fais un PUT sur cet URI avec de nouvelles données, je le mettrais à jour, en économisant. Et si je SUPPRIME cet URI, il le purgerait de mon système.

Avec POST, puisque vous n'avez pas encore créé de ressource, elle n'aura pas d'ID de ressource établi. Peut-être que la cible URI que je souhaite créer des ressources est simplement la suivante:

http://localhost:8888/donut

Aucun fragment d'ID dans l'URI. Toutes ces conceptions d'URI dépendent de vous et de la façon dont vous pensez de vos ressources. Mais en ce qui concerne la conception RESTful, je crois comprendre que vous souhaitez conserver les verbes de vos actions pour votre requête HTTP et les ressources en tant que noms qui rendent les URI faciles à lire et conviviaux.

es-tu encore avec moi? :-)

Revenons donc à la réflexion sur Backbone. Backbone est merveilleux car il fait beaucoup de travail pour vous. Pour enregistrer notre donut 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 appelé un cID qui est ce que Backbone utilise en interne, mais comme il n'a pas d'identifiant officiel, il sait qu'il doit créer une nouvelle ressource et il envoie une requête POST. Si vous avez obtenu votre modèle sur le serveur, il aura probablement un identifiant si tout allait bien. Dans ce cas, lorsque vous enregistrez () Backbone suppose que vous souhaitez mettre à jour le serveur et il enverra un PUT. Pour obtenir une ressource spécifique, vous utiliserez la méthode Backbone .fetch () et elle envoie une requête GET. Lorsque vous appelez .destroy () sur un modèle, il enverra le DELETE.

Dans les exemples précédents, je n'ai jamais dit explicitement à Backbone où se trouve 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 obtiendra la troisième aide à http://localhost:8888/donut/15Il ajoutera simplement / donut stem à la racine de votre site.

Si vous êtes toujours avec moi, tant mieux. Je pense. Sauf si vous êtes confus. Mais nous allons avancer de toute façon. 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, Backbone ET votre serveur devez partager.

Votre serveur doit comprendre la différence entre une requête GET, POST, PUT et DELETE. Comme vous l'avez vu dans les exemples ci-dessus, GET, PUT et DELETE pourraient 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 quant à ce qu'il faut faire avec cette ressource.

C'est à ce moment que vous commencez à penser à votre code de fin de serveur RESTful. Certaines personnes aiment Ruby, certaines personnes aiment .net, j'aime PHP. En particulier, j'aime le micro-framework PHP SLIM. SLIM PHP est un micro-framework qui dispose d'un ensemble d'outils très élégant et simple pour gérer les activités RESTful. Vous pouvez 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 bon code. Il existe d'autres solutions similaires à SLIM comme Recess, Tonic. Je crois que les plus gros frameworks comme Cake et CodeIgniter font également des choses similaires bien que j'aime le minimum. Ai-je dit que j'aimais Slim? ;-)

Voici à quoi pourrait ressembler l'extrait de code sur le serveur (c'est-à-dire spécifiquement concernant 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));
});

Ici, il est important de noter 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 remplir le modèle qui l'a demandé.

Avec SLIM PHP, les routes fonctionnent de manière assez similaire à ce qui précède.

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

Vous avez donc presque fait le tour complet! Va chercher un soda. J'aime Diet Mountain Dew. Obtenez-en un pour moi aussi.

Une fois que votre serveur traite 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), les données reviennent à Backbone pour le traitement final.

Avec vos méthodes save (), fetch (), etc. - vous pouvez ajouter des rappels facultatifs en cas de succès et d'erreur. Voici un exemple de la façon dont j'ai mis en place ce gâteau particulier:

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 partout et les gérer comme un champion. Je veux donc conserver mon gâteau avec des noix de coco et des noix. (Est-ce que c'est 2 noix?) Bref, j'ai passé deux objets à ma sauvegarde. L'objet JSON des attributs ET quelques options. Le premier, {wait: true} signifie ne pas mettre à jour mon modèle côté client tant que le voyage côté serveur n'a pas réussi. Le rappel de succès se produit lorsque le serveur renvoie une réponse avec succès. Cependant, comme cet exemple entraîne une erreur (un statut autre que 200 indiquera à 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 peut s'agir d'un objet d'erreur JSON avec plus de propriétés. Il se trouve dans l'attribut error.responseText. Ouais, 'nous n'aimons pas les noix.'

Toutes nos félicitations. Vous avez fait votre premier aller-retour assez complet depuis la configuration d'un modèle, son enregistrement côté serveur et inversement. J'espère que cette réponse épique vous donnera une idée de la façon dont tout cela se déroule. Il y a bien sûr beaucoup de détails que je suis en train de parcourir, mais les idées de base de sauvegarde de Backbone, de verbes RESTful, d'actions côté serveur, de réponse sont ici. Continuez à parcourir la documentation de Backbone (qui est très facile à lire par rapport à d'autres documents), mais gardez simplement à l'esprit que cela prend du temps à comprendre. Plus vous persévérez, plus vous maîtriserez. J'apprends quelque chose de nouveau avec Backbone chaque jour et cela devient vraiment amusant lorsque vous commencez à faire des sauts et que vous voyez votre maîtrise de ce cadre grandir. :-)

Bon codage!

EDIT: Ressources qui peuvent être utiles:

Autres réponses similaires sur SO: Comment générer des ID de modèle avec Backbone

Sur REST: http://rest.elkstein.org/ http://www.infoq.com/articles/rest-introduction http://www.recessframework.org/page/towards-restful-php-5-basic- conseils