web-dev-qa-db-ja.com

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

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

モデルデータを保存するさまざまな方法を説明してください（json形式を使用）。私はJava=サーバー側で使用しています。また、主にREST=データの保存に使用されています。 REST=および他の同様のもの。

誰かに簡単な例を使ってプロセスを説明していただければ幸いです。

javascriptjsonbackbone.jsjavascript-framework
86
testndtv

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

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

モデルを作成するには、いくつかの方法があります。例えば、JSON OR set（）というメソッドを使用して属性のJSONオブジェクトを取得する）を渡すことで、モデルインスタンスをセットアップできます。

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とBackboneの保存に関しては、頭を包み込むのはHTTPリクエストのセマンティクスとデータを使って何をするかです。

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

Backboneに入る前は、次の2つのHTTP要求メソッドに触れたことがありませんでした。 PUTおよびDELETE。これら2つの動詞は、Backboneに対して特定の意味も持ちます。リソースを更新する場合（たとえば、レモンドーナツのフレーバーをリモンドーナツに変更するなど）、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を削除すると、システムから削除されます。

POSTを使用すると、まだリソースを作成していないため、リソースIDが確立されていません。リソースを作成したいURIターゲットは、単に次のようになります。

http://localhost:8888/donut

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

まだ私と一緒ですか？ :-)

それでは、Backboneについて考えてみましょう。 Backboneは、多くの作業を行うので素晴らしいです。ドーナツとsecondHelpingを保存するには、次のようにします。

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

バックボーンはスマートです。ドーナツリソースを作成したばかりの場合、サーバーからのIDはありません。 Backboneが内部的に使用するcIDと呼ばれるものがありますが、公式のIDがないため、新しいリソースを作成する必要があることがわかっており、POSTリクエストを送信します。サーバーからのモデルは、すべてが正しければIDを持っている可能性がありますこの場合、save（）バックボーンがサーバーを更新することを想定し、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

Backboneは、http://localhost:8888/donut/15サイトのルートに/ donut stemを追加するだけです。

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

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

これは、RESTfulサーバーの終了コードについて考え始めるときです。 Rubyが好きな人、.netが好きな人、PHPが好きです。特にSLIM PHP micro-framework。SLIM PHPは、RESTfulアクティビティを処理するための非常にエレガントでシンプルなツールセットを備えたマイクロフレームワークです。上記の例のようにルート（URI）を定義でき、呼び出しがGET、POST、PUT、またはDELETEのいずれであるかに応じて、適切なコードを実行します。 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オブジェクトを期待していることです。常にサーバーでcontent-typeを '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
});

あなたはほぼ一周しました！ソーダを取りに行きます。ダイエットマウンテンデューが好きです。私も入手してください。

サーバーがリクエストを処理し、データベースとリソースで何らかの処理を行い、応答（単純な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'

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

おめでとうございます。モデルのセットアップからサーバー側への保存、そしてモデルの保存まで、最初のかなりのラウンドトリップを行いました。この回答の叙事詩があなたにIDEAがこれをすべてまとめる方法を提供することを願っています。もちろん、私が過去に巡回している詳細はたくさんありますが、Backbone save、RESTful verbsの基本的なアイデアは、サーバー側のアクション、レスポンスはここにあります。他のドキュメントと比べて読みやすいバックボーンのドキュメントを読み続けますが、頭を包むのに時間がかかることに注意してください。 Backboneを使って毎日新しいことを学び、飛躍を始めてこのフレームワークの流encyさを見ていくと、とても楽しくなります:-)

ハッピーコーディング！

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

SOに関する他の同様の回答： BackboneでモデルIDを生成する方法

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

271
jmk2142