Backbone.jsモデルデータを保存する方法は？

Question 1

私はフロントエンドの開発に興味があり、最近、Backbone.jsをアプリに取り入れ始めました。モデルデータをサーバーに永続化したい。

モデルデータを保存するさまざまな方法（json形式を使用）について説明してください。サーバー側でJavaを使用しています。また、主にデータの保存にRESTが使用されているのを見てきました。私はフロントエンド開発に興味があるので、RESTや他の同様のものに気づいていません。

誰かが簡単な例でプロセスを説明してくれたら素晴らしいと思います。

Question 2

基本的に、モデルには、特定のモデルが持つ可能性のあるさまざまな値である属性と呼ばれるプロパティがあります。バックボーンは、JSONオブジェクトを取得するさまざまなメソッドを使用してこれらの値を設定する簡単な方法として、JSONオブジェクトを使用します。例：

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

モデルにデータを入力するには、いくつかの方法があります。たとえば、JSONを渡すか、属性のJSONオブジェクトを受け取るset（）というメソッドを使用して、モデルインスタンスを設定できます。

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

したがって、これにより、モデルを保存し、サーバーに永続化することができます。「REST / RESTfulとは」に関する詳細はたくさんあります。そして、ここでこれらすべてを短い宣伝文で説明するのはちょっと難しいです。特にRESTとバックボーンの保存に関して、頭を悩ませるのはHTTPリクエストのセマンティクスとデータで何をしているのかです。

あなたはおそらく2種類のHTTPリクエストに慣れているでしょう。GETとPOST。RESTful環境では、これらの動詞は、Backboneが想定する特定の用途に対して特別な意味を持ちます。サーバーから特定のリソース（前回保存したドーナツモデル、ブログエントリ、コンピューターの仕様など）を取得する必要があり、そのリソースが存在する場合は、GETリクエストを実行します。逆に、新しいリソースを作成する場合は、POSTを使用します。

Backboneに入る前は、次の2つのHTTPリクエストメソッドに触れたことさえありませんでした。PUTとDELETE。これらの2つの動詞は、バックボーンにとっても特定の意味を持っています。リソースを更新する場合（たとえば、レモンドーナツのフレーバーをリモンドーナツに変更するなど）、PUTリクエストを使用します。そのモデルをサーバーからまとめて削除する場合は、DELETEリクエストを使用します。

これらの基本は非常に重要です。RESTfulアプリでは、使用するリクエスト動詞の種類に基づいて適切なタスクを実行するURI指定がある可能性があるためです。例えば：

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

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

そのURIに対してGETを実行すると、IDが17のドーナツモデルが取得されます。：idは、サーバー側で保存する方法によって異なります。これは、データベーステーブル内のドーナツリソースのIDである可能性があります。

新しいデータを使用してそのURIにPUTを作成すると、それを更新して保存します。そして、そのURIをDELETEすると、システムから削除されます。

POSTを使用すると、リソースをまだ作成していないため、リソースIDが確立されません。たぶん私がリソースを作成したいURIターゲットは単にこれです：

http://localhost:8888/donut

URIにIDフラグメントがありません。これらのURI設計はすべて、あなたとあなたのリソースについての考え方次第です。しかし、RESTfulデザインに関しては、HTTPリクエストに対するアクションの動詞とリソースを名詞として保持し、URIを読みやすく人間に優しいものにしたいというのが私の理解です。

あなたはまだ私と一緒ですか？:-)

それでは、バックボーンについて考えてみましょう。バックボーンはあなたのためにたくさんの仕事をするので素晴らしいです。ドーナツとsecondHelpingを保存するには、次のようにします。

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

バックボーンはスマートです。ドーナツリソースを作成したばかりの場合、サーバーからのIDはありません。Backboneが内部で使用するcIDと呼ばれるものがありますが、公式IDがないため、新しいリソースを作成する必要があることがわかり、POSTリクエストを送信します。サーバーからモデルを取得した場合、すべてが正しければ、おそらくIDがあります。この場合、save（）を実行すると、Backboneはサーバーを更新する必要があると想定し、PUTを送信します。特定のリソースを取得するには、バックボーンメソッド.fetch（）を使用して、GETリクエストを送信します。モデルで.destroy（）を呼び出すと、DELETEが送信されます。

前の例では、URIがどこにあるかをBackboneに明示的に伝えたことはありません。次の例でそれをやってみましょう。

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

バックボーンはサードヘルプを取得しhttp://localhost:8888/donut/15ます。サイトルートに/ドーナツステムを追加するだけです。

あなたがまだ私と一緒にいるなら、いいです。おもう。あなたが混乱していない限り。しかし、とにかく私たちは踏みにじります。この2番目の部分は、サーバー側です。HTTPのさまざまな動詞と、それらの動詞の背後にある意味の意味について説明しました。あなた、バックボーン、そしてあなたのサーバーが共有しなければならない意味。

サーバーは、GET、POST、PUT、およびDELETEリクエストの違いを理解する必要があります。上記の例で見たように、GET、PUT、およびDELETEはすべて同じURIを指す可能性がありhttp://localhost:8888/donut/07ます。サーバーがこれらのHTTP要求を区別できない限り、そのリソースをどう処理するかについて非常に混乱します。

これは、RESTfulサーバーのエンドコードについて考え始めるときです。Rubyが好きな人もいれば、.netが好きな人もいますが、私はPHPが好きです。特に私はSLIMPHPマイクロフレームワークが好きです。SLIM PHPは、RESTfulアクティビティを処理するための非常にエレガントでシンプルなツールセットを備えたマイクロフレームワークです。上記の例のようにルート（URI）を定義でき、呼び出しがGET、POST、PUT、またはDELETEのいずれであるかに応じて、適切なコードが実行されます。Recess、TonicのようなSLIMに似た他のソリューションがあります。CakeやCodeIgniterのような大きなフレームワークも、最小限が好きですが、同様のことを行うと思います。私はスリムが好きだと言いましたか？;-)

これは、サーバー上の抜粋コードがどのように見えるかです（つまり、特にルートに関して）。

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

ここで、BackboneはJSONオブジェクトを想定していることに注意することが重要です。常にサーバーにコンテンツタイプを「application / json」として指定させ、可能であればjson形式でエンコードしてください。次に、BackboneがJSONオブジェクトを受信すると、それを要求したモデルにデータを入力する方法を認識します。

SLIM PHPを使用すると、ルートは上記とほぼ同じように動作します。

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

これで、ほぼ完全な往復が完了しました。ソーダを取りに行きます。私はダイエットマウンテンデューが好きです。私にも1つ入手してください。

サーバーがリクエストを処理し、データベースとリソースで何かを実行し、応答を準備すると（単純なhttpステータス番号か完全なJSONリソースか）、データは最終処理のためにバックボーンに返されます。

save（）、fetch（）などのメソッドを使用すると、成功とエラー時にオプションのコールバックを追加できます。この特定のケーキを設定する方法の例を次に示します。

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'

この例には、いくつかの異なる点があります。私のケーキでは、保存する前に属性をset（）する代わりに、新しい属性を保存呼び出しに渡しただけであることがわかります。バックボーンは、JSONデータをあちこちで取得し、それをチャンピオンのように扱うのが得意です。だから私はココナッツとナッツでケーキを保存したいと思います。（それは2つのナットですか？）とにかく、私は2つのオブジェクトを保存に渡しました。属性JSONオブジェクトといくつかのオプション。最初の{wait：true}は、サーバー側のトリップが成功するまでクライアント側のモデルを更新しないことを意味します。サーバーが正常に応答を返すと、成功のコールバックが発生します。ただし、この例ではエラーが発生するため（200以外のステータスは、エラーコールバックを使用するようにバックボーンに示します）、変更なしでモデルの表現を取得します。それはまだプレーンでナッツがないはずです。サーバーが送り返したエラーオブジェクトにもアクセスできます。文字列を送り返しましたが、より多くのプロパティを持つJSONエラーオブジェクトである可能性があります。これはerror.responseText属性にあります。ええ、「私たちはナッツが好きではありません。」

おめでとう。モデルを設定し、サーバー側に保存してから、最初のかなり完全な往復を行いました。この答えの叙事詩が、これらすべてがどのように組み合わされるかについてのアイデアをあなたに与えることを願っています。もちろん、私が過去に巡回している詳細はたくさんありますが、バックボーン保存、RESTful動詞、サーバー側アクション、応答の基本的な考え方はここにあります。バックボーンのドキュメント（他のドキュメントに比べて非常に読みやすい）を読み続けてください。ただし、これには頭を包むのに時間がかかることを覚えておいてください。あなたがそれを維持すればするほど、あなたはより流暢になります。私はBackboneで毎日新しいことを学びます。飛躍し始め、このフレームワークの流暢さが増すのを見ると、とても楽しくなります。:-)

ハッピーコーディング！

編集：役に立つかもしれないリソース：

SOに関する他の同様の回答：バックボーンを使用してモデルIDを生成する方法

RESTの場合：http ： //rest.elkstein.org/ http://www.infoq.com/articles/rest-introduction http://www.recessframework.org/page/towards-restful-php-5-basic-チップ