2013-02-20 44 views
0

我有以下的模型(簡化了這個問題):如何在不存在請求的ID時避免空記錄? (恩伯)

App.Manager = DS.Model.extend({ 
    name: DS.attr('string'), 

    teamMembers: DS.hasMany('App.Employee') 
}); 

當這個模型被加載(與App.Manager.find(1)說),它是從我的服務器回來了teamMembers陣列:

[10, 11, 12] 

我的觀點需要來自這些團隊成員的數據,所以Ember會按照預期自動加載findMany()請求。我遇到的問題是#11員工不存在。服務器響應只有員工findMany()要求10 & 12:

{ 
    "employees": [ 
    { 
     "id": 10, 
     "name": "John Doe" 
    }, 

    { 
     "id": 12, 
     "name": "Jane Doe" 
    } 
} 

但是,灰燼,數據似乎仍然保持周圍空(並完成)承諾爲員工11即使該員工的數據是從來沒有回。所以現在當我的視圖呈現時,我得到一個有3行的表(每個員工一個表),其中一行是完全空白的(因爲記錄是空的)。

檢查記錄的狀態:

{ 
    isLoaded: true, 
    isDirty: false, 
    isSaving: false, 
    isDeleted: false, 
    isError: false, 
    isNew:  false, 
    isValid: true 
} 

所以,我不知道如何保持這個空記錄了我的觀點,而不檢查,如果每次我需要的屬性是空的。有沒有辦法讓服務器響應,告訴燼不履行這個承諾?有沒有一種方法可以配置ember來識別數據何時未被返回?


編輯:我意識到,理想情況下,服務器不會爲不存在的僱員返回一個ID。但事實是,有時候數據不可靠,或維護不善。如果員工11回來的數據不準確,那麼我會同意問題出在數據和/或服務上,而不是Ember。但是,在這種情況下,員工11沒有返回不準確的數據,它根本沒有返回沒有數據。在這種情況下,在我看來,至少應該像ember那樣設置一個標誌(即isValid:false)來指示記錄是空的/無效的/未找到的,如果不是完全平坦地銷燬對空記錄的引用。

編輯2:這裏有一個Issue on Github

+0

這不是你的後端而不是Ember本身的問題嗎?當然,在一個理想的世界中,Ember將排除非返回的實體。當11不存在時,爲什麼後端將'[10,11,12]'回傳?當然你的後端不應該包含11,除非在後端有一些緩存。 – Wildhoney 2013-02-20 22:31:24

+0

@Wildhoney你是對的。最終,服務器不應該首先發回11。我還沒有弄清楚爲什麼它會發回一個不存在的id,但我覺得ember應該足夠聰明來處理這個優雅。 – KOGI 2013-02-21 02:44:37

回答

1

很難說灰燼數據是否應該儘量提供一些魔術的這個場景。通過將ID包含在關係中,您已經有效地告訴了它存在的ember-data。

REST適配器(來自服務器的請求數據)與序列化程序(將響應數據轉換爲模型)分開,因此很難知道是否實際返回了所有請求的數據。如果你不介意緊緊地將你的適配器連接到你的序列化程序,你可能能夠驗證服務器給你你所期望的一切。

解決方法:

驗證屬性添加到您的員工的模型作爲一種僞狀態的使用。這應該默認爲false或null,並且API返回的每條記錄都必須覆蓋它。漂亮hackish。幸運的是,這個相同的概念可以使用現有的財產,如員工的姓名。

if (App.Employee.find(11).get('name') != null) { dance('thriller'); }

如果你認爲上面的概念,作爲一個標準的驗證要求,您可以選擇實現它是這樣無論是在模型或串行。

+0

似乎剩下的適配器應該能夠知道,因爲它知道它請求了哪些記錄,並且在序列化器完成之後,適配器知道我們現在有哪些記錄。在我從我的盤子裏清除了更多東西之後,我將不得不做一些實驗。 – KOGI 2013-02-22 15:57:15

+0

另外,當Ember-data解析關係時,它所做的只是一個自動化的'findMany([id,id,id])'。如果您手動執行與無效ID相同的'findMany()'調用,則會遇到同樣的問題。也許應該有辦法讓服務器在返回有效結果的同時指出問題? '{「employees」:[{「id」:10,「name」:「Jon Doe」},{「id」:11,「isError」:true},{「id」:12,「name」 Jane Doe「}]}'。就在那邊的袖口,我不知道...... – KOGI 2013-02-22 17:38:32

相關問題