如何使用Backbone.js生成模型ID

Question

我正在設置骨幹網同步機制，並且對於爲模型生成標識的位置有點困惑。

當我創建一個新模型時，骨幹網應該生成並設置id，還是我應該實現一個id生成方法，或者有某種機制將數據「放入」服務器，生成id並返回帶有id的模型？

Answer 1

或者是有某種機制在哪裏「PUT」數據到服務器，該服務器產生的ID，並返回一個模式與ID？

的種類。當你調用你的模型的save方法時，backbone做一個POST XHR，你的應用服務器應該用JSON響應包含一個id。 你可以在這裏看到一個例子：http://addyosmani.com/blog/building-backbone-js-apps-with-ruby-sinatra-mongodb-and-haml/

從鏈接引用：

post '/api/:thing' do 
    # parse the post body of the content being posted, convert to a string, insert into 
    # the collection #thing and return the ObjectId as a string for reference 
    oid = DB.collection(params[:thing]).insert(JSON.parse(request.body.read.tos)) 
    "{\"id\": \"#{oid.to_s}\"}" 
end 

如果你不知道紅寶石記住什麼是最後計算的表達式自動由該方法返回。

Answer 2

我從你的問題中瞭解到，你希望有一個存在於服務器上的模型的集合。爲了將這些模型添加到集合中，您必須在集合上添加調用「fetch（）」。

該URL將是「/用戶」或類似的，這將不得不返回一個對象的數組與用戶數據在那裏。然後將數組中的每個項傳遞給UserCollection.add（）。那麼，實際上它會一次通過，但你明白了。

在此之後您的收藏被填充。模型上的URL用於更新和保存單個模型。該集合的URL也將用於創建模型。骨幹的同步是RESTful，就像Ruby on Rails一樣。實際上，你可以瞭解更多有關它的Ruby的文檔上on Rails的：

http://guides.rubyonrails.org/routing.html

你通常會做的是什麼對你的模型比你的控制器不同的URL。在填充你的集合之後，你需要爲每個模型添加id，因爲它們來自服務器。

現在，當您添加基於用戶輸入的新模型，你會做這樣的事情：

var HomeModel = Backbone.Model.extend({ 
    defaults: { 
     lead: "not logged in", 
    }, 

    url: 'test.php', 

    initialize: function(){ 
     _.bindAll(this, 'handleSave', 'handleError'); 
     // Save already knows if this.isNew. 
     this.save(undefined, {success: this.handleSave, error: this.handleError}); 
    }, 

    handleSave: function(model, response){ 
     this.model.reset(model); 
    }, 

    handleError: function(){ 

    }, 
}); 

var HomeView = Backbone.View.extend({ 
    initialize: function() { 
     _.bindAll(this, 'render'); 
     this.model = new HomeModel(); 
     this.model.bind("change", this.render); 
    }, 

    el: 'div', 

    render: function() {  
     // Do things to render... 
    } 
}); 

var homeView = new HomeView(); 

的例子是從別人的問題，我回答，我只是添加相關的東西。

一般的想法是在模型創建時保存模型，如果你需要它，你可以將代碼移動到模型的函數中，然後根據事件或其他事件調用它。

Answer 3

我正在提供第二個答案，以簡化您需要學習的代碼，以獲得您正在思考的主要觀點 - 從模型到服務器的實際一輪以及ID如何發揮作用。

假設你定義了一個模型 - 讓我們一起去侏羅紀公園。

// Define your model 
var Dinosaur = Backbone.Model.extend({ 
    defaults: { 
     cavemanEater: undefined // Has one property, nom nom or not. 
    }, 
    urlRoot: 'dino'    // This urlRoot is where model can be saved or retrieved 
}); 

var tRex = new Dinosaur({'cavemanEater':true}); 

您現在已經實例化了一種吃肉的恐龍。怒吼。

console.log(tRex); 

您應該注意的是，在tRex的屬性中，您的模型沒有ID。相反，您會看到一個cID，您可以將其視爲Backbone自動分配給您的模型的臨時ID。當模型沒有ID時，它被認爲是新的。持久化模型（無論是數據庫還是本地存儲）的概念允許您在創建模型並執行諸如保存（PUT）或銷燬（DELETE）之後返回到該資源。如果您無法再直接指向它，將很難找到該資源！爲了找到這個資源，你的模型需要一個id，它目前沒有。

因此，正如上面的答案已經解釋說，它是您的數據庫（或本地存儲，或其他解決方案）的工作，以提供骨幹資源ID。大部分時間來自資源ID本身，也就是某個表中模型的主鍵ID。

用我的設置，我使用PHP和MySQL。我會有一張名爲「恐龍」的表格，每一行都是我的恐龍模型的一貫表現形式。所以我會有一個id列（獨特的自動遞增int）和cavemanEater（布爾）。

數據通信流發生像這樣。

1. 您創建一個模型。
2. 該模型是新的，所以它只有一個cID - 沒有正確的ID。
3. 您保存模型。
4. 您的模型的json表示形式是SENT到您的服務器（POST）
5. 您的服務器將其保存到表中併爲其提供資源ID。
6. 你的服務器發送數據的JSON表示{ID：UNIQUEID}
7. 骨幹收到此JSON表示ID爲
8. 骨幹自動的與ID更新您的模型。

下面是註釋代碼的樣子。

客戶：

tRex.save(); 
// {'cavemanEater':true} is sent to my server 
// It uses the urlRoot 'dino' as the URL to send. e.g. http://www.example.com/dino 

SERVER：

// Is setup to accept POST requests on this specific ROUTE '/dino' 
// Server parses the json into something it can work with, e.g. an associative array 
// Server saves the data to the database. Our data has a new primary id of 1. 
// Data is now persisted, and we use this state to get the new id of this dino. 

$dinoArray = array('id'=>1, 'cavemanEater'=>true); 
$dinoJSON = json_encode($dinoArray); 

// Server does something to send $dinoJSON back. 

客戶：

// If successful, receives this json with id and updates your model. 

現在你Trex公司有一個id = 1，或者我應該說...

tRex.toJSON(); 
// RETURNS {'id':'1', 'cavemanEater':'true'} 

恭喜。如果你這樣做tRex.isNew()它將返回false。

骨幹很聰明。它知道POST新模型和PUT模型已經有一個資源ID。

下一次你這樣做：

tRex.save(); 

骨幹將使PUT請求發送到以下網址。

http://www.example.com/dino/1

由該方式的默認行爲。但是你會注意到，URL與保存不同。在服務器上，您需要一個接受/ dino /：id的路由，而不是/ dino

默認情況下，它將爲模型使用/ urlRoot /：id路由模式，除非您調整它。

不幸的是，恐龍已經滅絕。

tRex.destroy(); 

這會調用...你能猜到嗎？是的。刪除請求到/ dino/1。

您的服務器必須區分對不同路由的不同請求，以使Backbone正常工作。有幾種服務器端技術可以做到這一點。

有人提到Sinatra如果你使用Ruby。就像我說的，我使用PHP並使用SLIM PHP框架。它受到Sinatra的啓發，所以它很相似，我喜歡它。作者寫了一些乾淨的代碼。儘管這些RESTful服務器實現的工作方式超出了本討論的範圍。

我認爲這是沒有身份證的新骨幹數據的基本全程旅行，通過互聯網到您的服務器生成它，然後發回資源ID，讓您的模型永遠快樂地生活。 （或destroy()不是...）

我不知道這對你來說太初學，但希望它能幫助遇到這個問題的其他人。 Backbone與編程非常有趣。

其他類似的答案： Ways to save Backbone JS model data